Image security and scanning

By the end of this lesson you will know exactly which four decisions harden an image, why a green CI scan is not a security guarantee, and what a production pipeline must do that a build pipeline cannot.

Attack surface is what you ship

Every byte in your image is something an attacker can use once they are inside the container. A full node:18 or python:3.12 base is a complete Debian or Ubuntu userland: a shell, apt, curl, bash, dozens of system libraries, a package manager — hundreds of packages, each a row in a CVE database. You did not ask for any of it; it came with the convenience of FROM node:18. The first and largest lever in image security is therefore not a scanner or a policy — it is carrying less.

Three moves shrink the surface. Slim variants (node:22-slim) strip the base OS down to roughly what the runtime needs. Distroless images (gcr.io/distroless/*) go further: only your app plus its direct runtime libraries — no shell, no package manager, no apt. Multi-stage builds ensure the compilers, dev dependencies, and apt caches used to build the artifact never reach the final stage at all. The payoff is direct: fewer installed packages means fewer CVEs to triage, a smaller image to pull and store, and far less for an attacker who lands a shell — because on distroless there is no shell to land in.

# syntax=docker/dockerfile:1
FROM node:22 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Distroless final stage: app + runtime libs only, no shell, no apt
FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Distroless ships a nonroot user; do not run as root
USER nonroot
CMD ["dist/server.js"]

The three base choices trade attack surface against convenience:

Run as non-root, and pin what you run

By default a container process runs as root inside its namespace. That root is somewhat constrained, but it is still the wrong default: if an attacker breaks into the process — through an app bug, a dependency RCE, a misconfigured mount — they inherit root, and root plus a kernel bug or a careless --privileged flag or a writable host bind mount is a path to escalation off the container. Docker’s own guidance is blunt: if a service can run without privileges, use USER to change to a non-root user. Add an explicit unprivileged user and switch to it before CMD. Pair it with a read-only root filesystem (--read-only, with a tmpfs for the few paths that genuinely need writes) so a compromised process cannot drop a binary or rewrite your app on disk.

# Create and switch to an unprivileged user before CMD
RUN addgroup --system app && adduser --system --ingroup app app
USER app
# At run time, lock the root filesystem read-only:
#   docker run --read-only --tmpfs /tmp myimage

The second discipline is pinning by digest, not tag. A tag like node:22 is a moving pointer — the publisher can, and does, repoint it to a new image whenever they rebuild. That means FROM node:22 is not reproducible: two builds a week apart can pull two different base images, and :latest is the worst of all, silently sliding under you. A digest (node:22@sha256:...) is the immutable content hash of one exact image; pin to it and every build, every machine, every CI run gets byte-identical bytes — and you have a fixed target to scan and to audit. The cost is that you must deliberately bump the digest to get upstream patches, which is exactly why scanning over time (below) matters.

Scanning: at build, and forever after

A scanner (Docker Scout, Trivy, Grype) builds a software bill of materials — the SBOM, a complete inventory of every OS package and language dependency in the image, with versions — and matches that inventory against a continuously updated vulnerability database to pinpoint CVEs in your layers and packages. Wire it into CI as a gate: fail the build on new critical/high findings so a vulnerable image never ships. The SBOM is also your provenance and audit record — when the next big CVE drops, you answer “are we affected?” by querying SBOMs, not by guessing.

# Inventory + vulnerability summary (Docker Scout)
docker scout quickview my-app:1.4.0
docker scout cves my-app:1.4.0

# Generate an SBOM for audit / provenance
docker scout sbom my-app:1.4.0

# Equivalent with Trivy, gating CI on critical/high
trivy image --severity CRITICAL,HIGH --exit-code 1 my-app:1.4.0

The senior failure mode is treating the build-time scan as the whole job. A green scan is a snapshot, not a guarantee. New CVEs are disclosed daily against packages that are already inside your shipped image; an image clean at build can be critical a month later with zero code changes — exactly the hook. So scanning must run on a schedule against deployed images, not only in the build that produced them, and the alert must route to whoever can ship the patched digest. Rescan registry images nightly; treat “no one re-scanned” as the real vulnerability.