← Concepts & Glossary
Signing & Supply Chain Trust

Zero CVE Container Images

Base images curated so none of the packaged components carry known CVEs.

What are zero-CVE container images?

A zero-CVE container image is a base image — typically based on a minimal distribution such as Wolfi, Alpine, or a purpose-built distroless variant — in which none of the packaged components carry known CVEs at the moment of publication. The image is continuously rebuilt as its upstream components are patched, so the zero-CVE property holds as a living guarantee rather than a single-point-in-time snapshot.

The model was popularised by Chainguard with its Wolfi undistro and the Chainguard Images catalogue, and it has since been adopted in various forms by Red Hat (UBI Micro), Google (distroless), and most major cloud providers. Common shape: a few megabytes, no shell, no package manager, and a Sigstore-signed attestation shipped alongside.

How they work

Four engineering choices make zero-CVE possible:

  1. Minimal surface. The image ships only what the application needs at runtime — no shell, no coreutils, no compiler, usually no package manager. Fewer components means fewer CVEs can apply, and the denominator of the CVE-count fraction stays small.
  2. Continuous rebuilds. Every time an upstream package ships a security patch, the image is rebuilt from source and republished — often within hours of the upstream fix. The rebuild cadence is the whole point: zero-CVE is an SLA, not a label.
  3. Source-first toolchains. Distributions like Wolfi build every package from source against a known-good toolchain, which means patches can be integrated as soon as they land upstream — without waiting for a distro maintainer to cut a release.
  4. Signed provenance. Every image is signed (usually with Cosign) and carries a Sigstore-verifiable SBOM and attestation — so consumers can prove not just that the image has zero CVEs, but that this is the image the producer actually published.

Why it matters

The base image is usually the single largest contributor to a container's CVE count — a stock ubuntu:22.04 can carry hundreds of open CVEs on the day it is pulled, most of which will never be exploitable but all of which show up in every scan report. Swapping to a zero-CVE base cuts the raw finding count by 80–95% in typical engagements, and — more importantly — removes a class of perpetual compliance noise.

The economic argument writes itself: every CVE that never appears in the base image is a CVE that never has to be triaged, exception-documented, or remediated.

What value they add

  • 80–95% fewer scanner findings on day one

    Most of a container's raw CVE count comes from the base. Swap the base, and the scanner output shrinks accordingly.

  • Patch cadence measured in hours, not weeks

    Continuous rebuilds close the window between upstream fix and deployed patch, which is where most exploitation happens.

  • Compliance evidence is pre-packaged

    Signed SBOMs and attestations ship with the image — so the answer to "what's in this container?" is a single cosign verify away.

  • Smaller attack surface by construction

    No shell and no package manager means a whole category of post-exploitation techniques (shell payloads, live package installation) simply does not apply.

  • Lower operational cost per image

    Less triage, less exception paperwork, less time spent explaining inherited CVEs to auditors — the savings accumulate across every image a team ships.

How Safeguard uses it

Safeguard continuously verifies that promoted images use an approved zero-CVE base and still carry a valid producer signature. If a rebuild introduces a regression or the signature fails to verify, the self-healing pipeline opens a Fix PR on the Dockerfile automatically.

Measure the impact of a zero-CVE base.

Point Safeguard at a few images. See the CVE count before and after a base swap — and how much triage time you get back.