Image and container security

Why container security matters

Containers share the host's kernel, so a container running as root with too many permissions is only a few steps away from controlling the whole server. Images also carry hundreds of packages you did not write, and any of them may have a known vulnerability, often called a CVE (Common Vulnerabilities and Exposures, a public ID for a security bug). Security work therefore has two parts: build a clean image, and run it with the least privilege it needs.

Build a clean image

• Minimal base image: slim, alpine or distroless. Fewer packages means fewer vulnerabilities and fewer tools for an attacker. A distroless image has no shell at all.
• Pin versions: FROM python:3.12-slim, never just python. For full reproducibility, pin the digest too: FROM python:3.12-slim@sha256:<digest>. A digest identifies the exact image content and cannot be moved like a tag.
• Multi-stage builds, so compilers and dev dependencies never reach the final image.
• Rebuild and redeploy regularly (for example weekly, from CI) so security patches in the base image reach production. Pinning without updating means you keep old vulnerabilities forever; tools like Dependabot or Renovate can open pull requests to bump pinned versions.

Run as a non-root user

By default, the process in a container runs as root (user ID 0). If an attacker breaks into your app, they are root inside the container, which makes escaping to the host much easier. Create a user in the Dockerfile and switch to it. Many official images already include one: the node images have a user called node.

RUN groupadd --system app && useradd --system --gid app --uid 10001 app
COPY --chown=app:app . /app
USER app

No secrets in images

Everything in an image can be read by anyone who can pull it: files in any layer, ENV values and build ARGs (docker history shows them). So secrets such as a private npm token or an API key must never go into ENV, ARG, or a copied file. For secrets needed DURING the build, use BuildKit build secrets, which are mounted only for one RUN step and never saved in a layer.

# syntax=docker/dockerfile:1
FROM node:24-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci --omit=dev

For secrets needed at RUN time, pass them when the container starts: through the platform's secret store (Docker Swarm or Compose secrets, Kubernetes Secrets, AWS Secrets Manager and similar), mounted as files under /run/secrets. Environment variables are common and acceptable for many teams, but remember that they show up in docker inspect.

Run with least privilege

docker run -d --name shop-api \
  --read-only --tmpfs /tmp \
  --cap-drop ALL --cap-add NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  --user 10001 --memory 512m --pids-limit 200 \
  -p 8080:3000 ghcr.io/acme/shop-api:2.1.0

Scan images

docker scout cves ghcr.io/acme/shop-api:2.1.0    # Docker Scout: list known CVEs
trivy image ghcr.io/acme/shop-api:2.1.0           # Trivy, a popular open-source scanner

A scanner compares the packages in your image with databases of known vulnerabilities. Not every finding is urgent: check whether a fix exists and whether the affected package is actually used. Often the fix is simply rebuilding on a newer base image.

Sign images

How does a server know an image really came from your CI and was not swapped in the registry? By signing it. Cosign, from the Sigstore project, signs an image (by digest) and stores the signature in the registry; at deploy time, cosign verify or a Kubernetes admission policy checks the signature before the image is allowed to run.

Common mistakes

• Deleting a secret file in a later RUN: it still exists in the earlier layer. Use build secrets.
• Pinning versions once and never updating them. Pin AND update on a schedule.
• Ignoring scanner output because there are many findings. Start by fixing critical issues with available fixes, and switch to a smaller base image to cut the noise.
• Running --privileged "to make it work". Find the one capability or device the app really needs instead.