Docker security best practices in 2026 span the full container lifecycle: Dockerfiles, base images, build systems, secrets, SBOMs, registries, runtime settings, Docker Compose, Kubernetes, and CI/CD. A secure Docker program does not only ask “does the image have CVEs?” It asks whether the image is trusted, minimal, non-root, scanned, reproducible, and deployed with least privilege.

This guide targets Docker application teams, platform engineers, and AppSec teams building a practical container security checklist.

Docker security checklist for 2026

  • Use trusted minimal base images.
  • Pin image versions or digests for production.
  • Rebuild images frequently for patched base layers.
  • Use multi-stage builds to reduce final image contents.
  • Run as a non-root user.
  • Drop unnecessary Linux capabilities.
  • Avoid privileged containers and host namespace sharing.
  • Keep secrets out of Dockerfiles, build args, image layers, and logs.
  • Use .dockerignore to prevent accidental context leakage.
  • Scan images, OS packages, language dependencies, and secrets.
  • Generate SBOMs and track image provenance.
  • Use read-only filesystems where possible.
  • Harden Docker Compose for local and production-like environments.
  • Scan containers and deployment manifests in CI/CD.

Corgea container scanning helps prioritize high-impact image risk, while Corgea dependency scanning and Corgea secrets scanning catch package and credential risk before images ship.

1. Use trusted minimal base images

Every base image brings packages, defaults, and maintenance expectations. Prefer official, maintained, minimal images and rebuild when upstream patches land.

# Better than a full general-purpose OS image for many Node.js services.
FROM node:22-bookworm-slim AS runtime

Minimal does not mean unpatched. Distroless and slim images reduce attack surface, but teams still need rebuild automation and vulnerability visibility.

2. Pin versions or digests in production

Mutable tags are convenient but risky. latest can change underneath you, and even version tags can be moved in some registries.

For high-assurance production releases, pin by digest:

FROM node:22-bookworm-slim@sha256:REPLACE_WITH_APPROVED_DIGEST

The trade-off is operational: pinned digests need update automation. Use reviewed pull requests to update base images so security patches do not stall.

3. Use multi-stage builds

Multi-stage builds keep compilers, package manager caches, and dev dependencies out of runtime images.

FROM node:22-bookworm-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-bookworm-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=build /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]

This pattern reduces image size and removes tooling attackers can abuse after compromise.

4. Run containers as non-root

Running as root inside a container increases blast radius. Create or use a non-root user and ensure app directories have the right ownership.

FROM python:3.12-slim

WORKDIR /app
RUN useradd --create-home --shell /usr/sbin/nologin appuser
COPY --chown=appuser:appuser . .
USER appuser

CMD ["python", "app.py"]

Also set runtime controls in orchestrators. In Kubernetes, pair Dockerfile USER with pod securityContext settings. See the Kubernetes security checklist for manifest examples.

5. Keep secrets out of Docker images

Docker image layers are durable. If a secret is copied into an image and later deleted, it may still exist in a previous layer.

Avoid:

ARG NPM_TOKEN
RUN npm config set //registry.npmjs.org/:_authToken=$NPM_TOKEN

Use BuildKit secrets for build-time access:

# syntax=docker/dockerfile:1.7
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci

And build with:

docker build --secret id=npmrc,src="$HOME/.npmrc" .

For runtime secrets, use your orchestrator or secret manager. Scan repositories and images with Corgea secrets scanning before credentials spread.

6. Use .dockerignore

The build context often contains more than teams realize: .git, tests, local .env, screenshots, private keys, coverage, and generated artifacts.

.git
.env
*.pem
node_modules
coverage
dist
Dockerfile*
docker-compose*.yml

Keep the context small. It improves build performance and reduces accidental leakage.

7. Scan Docker images and language dependencies

Docker image security best practices should include multiple layers of scanning:

  • OS packages in the base image;
  • language dependencies such as npm, PyPI, Maven, NuGet, Composer, and RubyGems;
  • secrets in layers and build context;
  • malware or suspicious files;
  • configuration weaknesses in Dockerfiles and Compose files.

Corgea container scanning focuses teams on image findings worth fixing, and Corgea dependency scanning helps prioritize vulnerable packages by usage.

8. Generate SBOMs and track provenance

An SBOM gives teams an inventory of what is inside an image. Provenance helps answer where the image came from, how it was built, and which source revision produced it.

Practical steps:

  • generate SBOMs during CI;
  • attach SBOMs to release artifacts;
  • sign images or attest build provenance where supported;
  • use a registry policy that blocks untrusted images;
  • keep inventory searchable for incident response.

Corgea SBOM and license enforcement helps teams connect container inventory to broader supply chain governance.

9. Drop runtime privileges

Container runtime hardening should be explicit:

docker run \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 \
  --memory 512m \
  my-app:2026.05.22

Avoid:

  • --privileged;
  • host PID, IPC, or network modes;
  • mounting the Docker socket into containers;
  • broad hostPath mounts;
  • unlimited memory or process counts.

If a container needs extra privileges, document why and isolate it.

10. Harden Docker Compose

Docker Compose is common in development and sometimes production-like environments. Treat Compose files as security-sensitive configuration.

services:
  api:
    image: registry.example.com/api@sha256:REPLACE_WITH_DIGEST
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    user: "10001:10001"
    environment:
      NODE_ENV: production
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Compose controls should mirror production assumptions: no privileged containers, no broad host mounts, no plaintext secrets committed to Git, and no unnecessary published ports.

11. Scan containers in CI/CD

Add container security checks before images reach the registry:

  • lint Dockerfiles for unsafe patterns;
  • scan base image and language dependencies;
  • scan secrets before build and after image creation;
  • generate SBOMs;
  • sign or attest release images;
  • block critical reachable risk based on policy;
  • scan Kubernetes or Terraform deployment manifests.

For broader pipeline hardening, read how to integrate static analysis into CI/CD.

12. Connect container risk to application risk

A critical image CVE matters more when the vulnerable package is used by a reachable service. Pair container scanning with:

This helps teams avoid noisy container backlogs and focus on fixes that reduce real exposure.

Try Corgea scanning for Docker images and containers

Want Docker security best practices enforced across your build and release workflow?

Try Corgea today or book a custom demo for your Docker and container pipeline.

If you are comparing container and AppSec coverage, read Corgea vs Snyk, Corgea vs Checkmarx, and Corgea vs GitHub Advanced Security. Teams evaluating custom static rules can also review Corgea vs Semgrep.

FAQ

What are the most important Docker security best practices?

The most important Docker security best practices are using trusted minimal base images, pinning versions or digests, running as non-root, keeping secrets out of images, scanning images and dependencies, generating SBOMs, dropping unnecessary runtime privileges, and scanning in CI/CD.

Should Docker containers run as root?

No. Production containers should run as a non-root user whenever possible. Running as non-root reduces the impact of application compromise and makes container escape paths harder to exploit.

How do you keep secrets out of Docker images?

Do not copy .env files or credentials into images, use BuildKit secrets for build-time access, pass runtime secrets through an orchestrator or secret manager, and scan Dockerfiles and images for leaked credentials.

Can Corgea scan Docker images and containers?

Yes. Corgea container scanning helps prioritize image risk, while Corgea dependency, secrets, IaC, and AI SAST coverage connect container issues to the broader application security workflow.