Container Image Security Hardening: Dockerfile Best Practices

Every production Dockerfile should implement these controls. They address the most common container escape and privilege escalation patterns.

1. Use a specific, pinned base image tag

# Bad: pulls whatever 'latest' is at build time
FROM ubuntu:latest

# Good: pinned to a specific digest (immutable)
FROM ubuntu:22.04@sha256:a6d2b38300ce017add71440577d5b0a90460d0e57fd7aec21dd0d1b0761bbfb2

Pinning by digest (not tag) guarantees the exact image layer is used at every build. Tags are mutable -- an upstream maintainer can update ubuntu:22.04 without changing the tag.

2. Run as a non-root user

# Create a dedicated app user and group
RUN groupadd -r appgroup && useradd -r -g appgroup -s /sbin/nologin appuser

# Switch to non-root before the ENTRYPOINT
USER appuser
ENTRYPOINT ["/app/server"]

Running as root inside the container means that any container escape puts the attacker as root on the host (if the runtime is misconfigured) or allows the attacker to write to sensitive paths inside the container. There is almost never a legitimate reason for an application to run as root.

3. Use a multi-stage build to minimize the final image

# Stage 1: Build
FROM golang:1.22 AS builder
WORKDIR /build
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o server .

# Stage 2: Minimal runtime
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /build/server /server
ENTRYPOINT ["/server"]

Multi-stage builds produce a final image that contains only the compiled binary (and any runtime dependencies), not the build toolchain. The distroless image used here has no shell, no package manager, and no OS utilities -- an attacker who achieves code execution inside this container has almost nothing to work with.

4. Do not copy secrets or credentials into the image

# Bad: credentials in image layers
COPY .env /app/.env
ENV DATABASE_PASSWORD=secret123

# Good: pass credentials at runtime via environment variables or secrets management
# Docker: --env-file or --secret flag
# Kubernetes: Secrets mounted as volumes or environment variables from secretKeyRef

Every layer in a Docker image is stored in the registry and accessible to anyone with pull access. Credentials embedded in any layer (even if RUN rm .env is called in a subsequent layer) remain in the layer history and can be extracted with docker history.

5. Set a read-only filesystem

In Kubernetes pod spec:

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

A read-only filesystem prevents an attacker who achieves code execution from writing backdoors, modifying binaries, or creating reverse shell scripts inside the container. If your application needs to write to disk, mount a specific writable volume only for that path.

6. Drop all Linux capabilities

Containers inherit a default set of Linux capabilities. Drop them all and add back only what is needed:

# Most web applications need zero capabilities
securityContext:
  capabilities:
    drop: ["ALL"]
    add: []  # add back specific caps only if required: NET_BIND_SERVICE for port <1024

The base image choice has a larger impact on vulnerability count than almost any other single decision.

Base image comparison:

Google Distroless images (gcr.io/distroless):

Distroless images contain only the language runtime and its dependencies. No shell, no utilities, no package manager. Options:

• distroless/static-debian12 -- for fully static binaries (Go with CGO_ENABLED=0, Rust)
• distroless/base-debian12 -- for binaries that need glibc
• distroless/java21-debian12 -- for Java applications
• distroless/python3-debian12 -- for Python applications

Each has a :nonroot variant that sets the default user to a non-root UID.

Alpine Linux trade-offs:

Alpine uses musl libc instead of glibc. Some applications compiled against glibc will not run correctly on Alpine without recompilation. Alpine's package repository has a smaller CVE surface than Debian/Ubuntu, but the musl vs. glibc difference can introduce subtle bugs in applications that assume glibc behavior.

When to use scratch:

The scratch base is a completely empty image -- only your binary. It works only for statically compiled binaries (Go with CGO_ENABLED=0, Rust). No TLS certificates are included, so you must copy the CA bundle explicitly:

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /build/server /server
ENTRYPOINT ["/server"]

Image scanning identifies known CVEs in the OS packages and application dependencies within your container image.

Trivy (Aqua Security):

Trivy is the most widely used open-source container scanner. It scans:

• OS packages (Alpine apk, Debian dpkg, RHEL rpm)
• Application dependencies (npm, pip, Maven, Gradle, Go modules, Cargo)
• Kubernetes manifests and Helm charts
• Infrastructure as code (Terraform, CloudFormation)
• Secret detection (exposed credentials, API keys)

# Scan a local image
trivy image myapp:latest

# Scan with SARIF output for IDE/PR integration
trivy image --format sarif --output results.sarif myapp:latest

# Fail CI on critical CVEs
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# Scan a Dockerfile before building
trivy config ./Dockerfile

# Generate SBOM
trivy image --format spdx-json --output sbom.spdx.json myapp:latest

Grype (Anchore):

Grype is an alternative scanner with strong CI/CD integration:

# Scan an image
grype myapp:latest

# Fail on high/critical
grype myapp:latest --fail-on high

# Scan a directory (for application dependencies without building)
grype dir:./src

Shifting scanning left:

Managing false positives: Not every CVE in a scan is exploitable in your environment. Trivy supports a .trivyignore file for documenting accepted risks:

# .trivyignore
CVE-2023-12345  # Not exploitable: this path is not exposed to untrusted input

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your container image. It enables rapid response to new CVEs by answering "which of our images are affected?"

SBOM standards:

• SPDX (Software Package Data Exchange) -- Linux Foundation standard, JSON/XML/TV formats
• CycloneDX -- OWASP standard, JSON/XML, tooling-friendly
• Syft -- Anchore's SBOM generator, supports both SPDX and CycloneDX output

Generating SBOMs with Syft:

# Generate CycloneDX SBOM from an image
syft myapp:latest -o cyclonedx-json > sbom-cyclonedx.json

# Generate SPDX SBOM
syft myapp:latest -o spdx-json > sbom-spdx.json

# Scan an SBOM for vulnerabilities with Grype
grype sbom:./sbom-cyclonedx.json

Image signing with Cosign (Sigstore):

Cosign signs container images using keyless signing (OIDC-based) or key-based signing. Unsigned images should be rejected at the Kubernetes admission controller level.

# Install cosign
brew install cosign  # macOS

# Sign an image (keyless via OIDC)
cosign sign myregistry.io/myapp:v1.2.3

# Verify a signature
cosign verify myregistry.io/myapp:v1.2.3   --certificate-identity=https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main   --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Enforcing image policies in Kubernetes:

Use Kyverno or OPA/Gatekeeper to enforce image signing, registry allowlists, and scan results:

# Kyverno policy: require signed images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  rules:
    - name: check-image-signature
      match:
        resources:
          kinds: ["Pod"]
      verifyImages:
        - image: "myregistry.io/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/*"
                    issuer: "https://token.actions.githubusercontent.com"

Your container registry is the distribution point for every image in your environment. Its security posture directly affects every workload you run.

Registry access controls:

• Enable image signing verification at the registry level (ECR's enhanced scanning, GCR's Binary Authorization)
• Implement pull-through cache with scanning for public registries -- never pull untrusted images directly from Docker Hub in production
• Restrict push permissions to CI/CD service accounts only; developers should not push directly to production registries
• Enable audit logging for all push and pull events

Image retention and tag hygiene:

# Delete images older than 90 days in AWS ECR
aws ecr list-images --repository-name myapp --filter tagStatus=UNTAGGED   --query 'imageIds[*]' --output json |   aws ecr batch-delete-image --repository-name myapp --image-ids file:///dev/stdin

Establish a retention policy: keep the 10 most recent tagged versions, delete all untagged images older than 7 days.

Private registry for base images:

Instead of pulling from Docker Hub directly (subject to rate limits and potentially malicious image substitution), mirror approved base images into your private registry and update them on a schedule:

# Mirror ubuntu:22.04 to your private registry
docker pull ubuntu:22.04
docker tag ubuntu:22.04 myregistry.io/base/ubuntu:22.04
docker push myregistry.io/base/ubuntu:22.04

Enforce via Kubernetes admission controller: reject any pod spec that references docker.io/* or *:latest.

Base image update automation:

Use Renovate or Dependabot to automatically create pull requests when new base image versions are released. Configure Trivy scanning in CI to ensure the PR does not introduce new critical CVEs before merging.