Hardened Base Images

The cheapest vulnerability to fix is one for a package you never installed. Every previous lesson made a container harder to attack; this one removes the things there was no reason to ship.

The ladder, and what each step costs

Each step down removes packages, and packages are what scanners find. Going from a distro base to distroless typically moves a CVE report from a hundred-odd findings to single digits — not because anything was patched, but because the software is not there.

Distroless in practice

# syntax=docker/dockerfile:1

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
USER nonroot
CMD ["dist/server.js"]

Three things differ from a normal image and each catches people once.

There is no shell, so CMD cannot use shell form and there is no sh -c. The entrypoint is the runtime itself, which is why CMD is a script path rather than a command.

docker exec gets you nothing, because there is nothing to exec. Debugging is docker debug (Docker Desktop attaches a toolbox without altering the image), or nsenter from the host into the container's namespaces with binaries from the host — the technique from Containers From Scratch.

Healthchecks cannot use CMD-SHELL or curl. Either ship a small static healthcheck binary, or move the check outside the container entirely.

Docker Hardened Images

Docker's own line of minimal images, aimed at the compliance side of the problem rather than only the size side. What they commit to:

• Minimal surface — distroless variants strip the majority of what a normal base carries.
• Non-root by default, so the USER decision is made for you.
• Continuously patched, targeting near-zero known CVEs.
• Signed, with verifiable SBOMs and SLSA Build L3 provenance on every image.
• VEX statements included, so the findings that remain arrive with justifications attached.
• Full, unsuppressed CVE visibility — the findings are published rather than filtered, which is the part that makes the near-zero claim checkable.

They are used like any other base:

FROM <your-org>/dhi-node:22-alpine3.22 AS build
...
FROM <your-org>/dhi-node:22-alpine3.22-runtime

The pattern to notice is the pairing: a build variant with a toolchain and a runtime variant without one. Mixing them up produces either a build that cannot compile or a runtime carrying a compiler, and the second is the one nobody notices.

docker dhi is the CLI plugin for browsing and managing them. Docker Hardened Images are a paid product; the techniques in this lesson are not, and distroless plus the previous lesson's practices gets most of the way for free.

Choosing, honestly

Match the base to how the service is actually operated:

• A service you deploy weekly and debug rarely — distroless or hardened. The debugging cost is paid seldom and the surface reduction is permanent.
• A service under active development — Alpine or -slim. Being able to exec in matters more right now, and you can tighten later.
• A single static binary — scratch, with the CA bundle copied in.
• Something needing glibc, a distro package, or ancient dependencies — debian:13-slim. Fighting musl to save 40 MB is not a good trade.

The mistake worth avoiding is adopting distroless for a service the team debugs interactively every week. The image is more secure and the on-call experience is worse, and what happens next is somebody adds a shell back "temporarily".

COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

RUN echo 'app:x:10001:10001::/nonexistent:/sbin/nologin' > /etc/passwd.min
# then, in the final stage:
COPY --from=build /etc/passwd.min /etc/passwd

Next up: signing and trust — proving an image is the one you built.