Container Image Hardening: Distroless, Wolfi, and Chainguard Patterns
Cybersecurity
A standard Ubuntu base image ships with around four hundred packages. Your application needs about twelve of them. Everything else is attack surface, CVE noise, and patch cycle overhead. We walk through the modern minimal-image patterns with Distroless, Wolfi, and the Chainguard Images catalog.
By Arjun Raghavan, Security & Systems Lead, BIPI · August 20, 2023 · 9 min read
The default container base image is a full Linux distribution, which is roughly the same as deploying your web service inside a workstation. It works, but you carry around hundreds of packages your application never calls, each one a potential CVE that has to be triaged when the next bulletin drops.
The fix is to start from a minimal base and add only what the application actually needs. The pattern has matured significantly since the original Distroless project, and the Wolfi and Chainguard Images ecosystem now makes it operationally easy.
Distroless: the original minimal
Distroless images from Google ship a runtime and nothing else. No shell, no package manager, no coreutils. Just the language runtime and the certificates you need to talk to other services. The CVE surface is a tenth of a standard Ubuntu base, sometimes less.
- gcr.io/distroless/static for static Go binaries
- gcr.io/distroless/base for binaries that need glibc
- gcr.io/distroless/java for JVM workloads
- gcr.io/distroless/python3 for Python workloads
The catch with Distroless is that debugging is harder. No shell means no kubectl exec into a broken pod. You either accept that and lean on observability, or ship a debug variant for non-production.
Wolfi: a minimal distro for containers
Wolfi is what happens when you design a Linux distribution specifically for container use. Glibc-based, apk package manager, fast security update cadence, and SBOM and signatures shipped for every package. It is the base that Chainguard Images are built on.
Wolfi packages are rebuilt on a daily cadence, which means CVEs get fixed in the base much faster than Ubuntu or Debian-based equivalents. For teams that were getting paged by their container scanner on every weekly Debian advisory, this is the unlock.
Chainguard Images
Chainguard Images are pre-built minimal images for common runtimes, signed with Cosign, shipped with SBOMs, and built on Wolfi. nginx, python, node, postgres, redis, all available as minimal hardened images that drop into existing Dockerfiles with a base image swap.
Swapping a base image from ubuntu:22.04 to a Chainguard equivalent typically cuts CVE count by 80 to 95 percent on the first scan.
Multi-stage builds are the prerequisite
None of these minimal bases let you compile inside the runtime image. You build in a fat stage with the toolchain, then copy the artifact into the minimal stage. If your Dockerfile is not multi-stage today, that is the first refactor. Once it is, swapping the runtime stage to Distroless or Chainguard is usually a one-line change.
- Move to multi-stage builds with a builder stage and a runtime stage
- Swap the runtime stage to a Distroless or Chainguard base
- Add a debug variant tag for non-production troubleshooting
- Wire Trivy or Grype into CI to confirm the CVE drop
- Document the base image policy and forbid pulling from anything outside the approved list
The operational gotchas
- No shell in production means your runbooks need to assume kubectl debug with an ephemeral container
- Some libraries assume tools like file, ldconfig, or uname are present, test before you ship
- Glibc vs musl matters, do not mix base images across the same workload
- FIPS requirements may push you back to a non-minimal base, plan accordingly
Closing
Image hardening used to be a niche practice for security-paranoid teams. The Wolfi and Chainguard ecosystem has made it the obvious default for any team that takes CVE triage time seriously. The migration is a quarter of work, the operational savings are continuous, and the security posture improvement is real.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.