Docker Container Security: A Practical Checklist for Production Images

Containers are not mini virtual machines. A container shares the host kernel, so every hardening decision in the image and at runtime maps directly to the blast radius of a breakout. This guide turns the CIS Docker Benchmark controls and Docker's own security documentation into a checklist an engineering team can apply to every image before it ships.

1. Choose a Minimal, Supported Base Image

Pull the lastest tag at build time and pin it by digest in production. In practice the rules are:

• Prefer a minimal base (Alpine, distroless, or slim) over a full distribution image; every package in the image is attack surface.
• Rebuild on refreshed bases at least weekly — base image CVEs are the most common way a "secure" image slowly becomes exploitable.
• Multi-stage builds so compilers, package managers, and build-time secrets never land in the runtime image.

2. Run as Non-Root and Drop Capabilities

The CIS Benchmark is blunt about two controls:

• Run the container as a non-root user. A UID-mapped container process that escapes to the host lands with far more privilege when the process stream is root.
• Drop Linux capabilities (--cap-drop=ALL) and add back only the ones the process needs. Privileged mode (--privileged) should be treated as an explicit security exception — it disables most of the isolation the runtime provides.

Add --read-only and copy-on-write mounts for writable paths, and --no-new-privileges so child processes cannot gain privilege through setuid binaries.

3. Pin by Digest, Sign, and Verify at Deploy

• Use image@sha256:<digest> references in production manifests so an attacker who compromises a registry tag cannot move the deployed artifact.
• Sign images (Cosign/Sigstore or registry-native signing) and verify signatures in the admission path — the Docker image signing workflow and the Sigstore docs both cover the mechanics.
• Maintain a registry scan in CI so a newly disclosed CVE in a base image blocks promotion before it reaches production.

4. Scan Images — and Stay Interested in New CVEs

Image scanning tools catch known CVEs; they do not catch your own misconfigurations (root user, writable filesystem, secrets in layers). Pair scanning with IaC-style checks: a Dockerfile lint and a runtime-config checklist in code review. If a scanner reports High CVE detail but the application layer is clean, the base image is the most likely moving part — rebuild and repin.

5. Control Secrets and Logs

• Never bake secrets into image layers. Use runtime secret mounts (Docker secrets, Kubernetes Secret volumes, or a vault integration) and purge build secrets with multi-stage builds.
• Logs and crash dumps inside containers are routinely shipped to log aggregators; a debug log that includes an authorization header is a credential leak with a searchable index.

Your First 30 Days

A realistic rollout runs in four passes. Week one: set the non-root user and --cap-drop=ALL on the three most critical services and watch for regressions. Week two: pin images by digest in production manifests and enable registry scanning in CI with a blocking gate on Critical CVEs. Week three: add signature verification at the admission path and remove any secret baked into a published image. Week four: schedule the review of every privileged container as an explicit security exception, with an owner and a retirement date. The CI checks above become the default template for every new service as you ship them.

How Eresus Assesses Container Risk

Our reviews treat containers as trust boundaries between the application and the host kernel. The assessment covers registry and supply-chain hygiene, runtime isolation, privilege and capability configuration, and the path from a compromised container to host-level impact — then translates every finding into business impact with proof of privilege obtained.

Sources

• CIS Docker Benchmark
• Docker security documentation
• OWASP Container Security Top 10