Docker Best Practices & Security

VerifiedSafe

Covers Dockerfile best practices including security hardening (non-root user, secret management), multi-stage builds for image optimization, and cache-friendly instruction ordering. Helps developers write efficient, secure Dockerfiles and avoid common pitfalls.

Sby Skills Guide Bot
DevOpsIntermediate
1606/2/2026
Claude CodeCursorWindsurfCopilotCodex
#docker#best-practices#security#multi-stage-builds#image-optimization

Recommended for

Our review

This skill provides rules and best practices for creating secure, optimized, and maintainable Dockerfiles.

Strengths

  • Focuses on security (non-root, no secrets, vulnerability scanning)
  • Includes build optimizations like multi-stage builds
  • Covers essential Dockerfile instructions with clear guidance
  • Provides a concrete example of a good Dockerfile

Limitations

  • Does not cover orchestration (Kubernetes, Docker Compose)
  • May not apply to all contexts (e.g., legacy applications)
  • Some rules are generic and may need adaptation
When to use it

Use this skill when creating or reviewing Dockerfiles for production applications.

When not to use it

Avoid using it if you are new to Docker without understanding basic concepts.

Security analysis

Safe
Quality score88/100

The skill provides Docker best practices and security hardening advice. It does not contain any instructions to execute destructive commands or exfiltrate data. All recommendations are defensive and promote safe configurations.

No concerns found

Examples

Review Dockerfile for security and best practices
Review the following Dockerfile for security issues, image size optimization, and best practices. Suggest improvements:

FROM node:latest
RUN apt-get update && apt-get install -y curl
EXPOSE 3000
CMD ["node", "app.js"]
Generate an optimized multi-stage Dockerfile
Generate a multi-stage Dockerfile for a Node.js application that uses npm. The final image should be minimal, run as non-root, include health check, and define proper labels. Use alpine as base.
Explain Dockerfile instructions
Explain the difference between ENTRYPOINT and CMD in Dockerfiles and provide an example of how to use them together correctly.

name: docker description: Dockerfile best practices, security hardening, multi-stage builds, and image optimization

Docker Code Review Rules

Security (Critical)

  • Run as non-root user (USER directive)
  • Don't store secrets in image (use runtime injection)
  • Don't use --privileged without justification
  • Scan images for vulnerabilities
  • Set readonly root filesystem where possible
  • Review any use of build-time variables (e.g., ARG, ENV, LABEL values) that can be influenced by external inputs (such as --build-arg values or CI/CD environment variables sourced from untrusted users) to ensure they are not used in a way that enables build-time injection
  • Never use HTML comments (<!-- -->) in Dockerfiles

Base Images

  • Pin base image to specific version (not latest)
  • Use official images from trusted sources
  • Prefer minimal images (alpine, slim, distroless)
  • Regularly update base images for security patches

Build Optimization

  • Use multi-stage builds to reduce final image size
  • Order instructions by change frequency (cache optimization)
  • Combine RUN commands to reduce layers
  • Use .dockerignore to exclude unnecessary files, sensitive data, and build artifacts like node_modules

Instructions (Essential)

  • Use COPY instead of ADD (unless extracting archives)
  • Set WORKDIR before COPY/RUN
  • Use explicit EXPOSE for documentation
  • Set meaningful LABEL metadata

Additional Instructions

  • Explicitly set SHELL if bash/sh features are needed
  • Set environment variables with ENV for configuration (not secrets)
  • Clean up package manager caches after install (e.g., apt-get clean)
  • Understand ENTRYPOINT vs CMD: use ENTRYPOINT for main command, CMD for default args
  • Document container usage with OCI labels (org.opencontainers.image.*)

Health Checks

  • Include HEALTHCHECK instruction
  • Health check should verify app is actually working
  • Set appropriate interval and timeout

Example Good Dockerfile Pattern

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Runtime stage
FROM node:20-alpine

# Add OCI labels for documentation
LABEL org.opencontainers.image.title="My App"
LABEL org.opencontainers.image.description="Production web application"
LABEL org.opencontainers.image.version="1.0.0"

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app

# Copy dependencies and app files
COPY --from=builder /app/node_modules ./node_modules
COPY . .

# Set environment variables (not secrets)
ENV NODE_ENV=production

USER appuser
EXPOSE 3000
HEALTHCHECK CMD wget -q --spider http://localhost:3000/health || exit 1

# Use ENTRYPOINT for main command, CMD for default args
ENTRYPOINT ["node"]
CMD ["server.js"]
Related skills