What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current product line names and which are covered by the free tier: confirm with vendor
- Language coverage for the built-from-source libraries offering: verify against vendor documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Chainguard attacks the container vulnerability problem from the supply side rather than the scanning side. Its images are built from Wolfi, a Linux distribution designed for containers, with no package manager or shell in the runtime variants and only the packages an application actually needs. Fewer packages means fewer components for a scanner to match, which is why teams adopting these images see vulnerability counts fall without changing application code. The images are rebuilt continuously rather than on a release train, so the gap between an upstream fix and a patched image is short.
Every image ships with the artifacts a supply chain program needs to verify it: a Sigstore signature, SLSA provenance attestation describing how it was built, and an SBOM generated at build time rather than reconstructed afterwards by scanning. The same approach extends to language dependencies, where Chainguard builds common Java and Python libraries from source in its own hardened pipeline so consumers can pull artifacts with known provenance instead of trusting a public registry directly.
Where it fits
This is a platform engineering decision, implemented in Dockerfiles and base image policy, with security as the beneficiary. Adoption means changing the FROM line across your builds and fixing what breaks, because the absence of a shell, a package manager and many assumed utilities will break things. It fits organizations that already centralize base images and is much harder where every team picks its own. Nothing here removes the need to scan your own application dependencies.
Strengths
- Attacking image contents rather than triage volume means the backlog shrinks instead of being reprioritized.
- Continuous rebuilds close the window between upstream fix and available image, where most base image drift comes from.
- Signatures, provenance and build-time SBOMs arrive as a package rather than a project you run yourself.
Limitations
- Minimal images are genuinely harder to debug and to migrate to. Expect broken builds, missing utilities and unhappy developers during the first weeks.
- You are moving from a public distribution you could patch yourself to a commercial supplier, a real concentration of trust.
- Coverage is broad but not universal. Anything you need that has no equivalent image still runs on your old base, so gains are partial unless adoption is thorough.
Who it suits
A strong fit for organizations with centralized base image ownership, a large container fleet and a backlog they cannot patch their way out of, particularly where customers or regulators ask for provenance. A poor fit for teams needing shell access in production containers, running niche runtimes with no equivalent image, or unable to accept a commercial dependency at the base of every build.
Used Chainguard? Recommend it under your own name and title.
Recommend this tool