Skip to main content
Back to Articles

Report: Chainguard "Zero CVE" Container Images

16 min read
11/20/2025
Regenerate

Overview

Chainguard markets Chainguard Images (containers and now VMs) as having “zero known CVEs” or “zero known vulnerabilities at release time”, maintained through frequent rebuilds and tight control of the software supply chain.1 This report looks at what that actually means, how they achieve it, and where the promise holds up versus where it has limits in practice.

What Chainguard Actually Promises

Chainguard’s own docs and marketing are very explicit about the scope of the claim:

  • "Zero known CVEs at release time" – not forever.

    • Their docs define zero‑CVE images as having no known CVEs when the image is built and shipped.2
    • They stress that CVEs will accumulate over time as new vulnerabilities are disclosed against the same components.3

  • Low‑to‑zero CVEs, not literally always zero:

    • Docs and marketplace listings describe images as “low-to-zero known CVEs”.4
    • FIPS and hardened variants are described as “daily builds with zero-to-minimal CVEs under SLA”.5
    • Marketing phrases like “zero known vulnerabilities at release” and “CVE-free container images today” are used, but are consistently anchored to build/release time.67

  • Comparison-based value proposition:

    • Chainguard positions itself as a safer alternative to traditional distro-based images, claiming up to 97.6% reduction in CVEs vs OSS equivalents and reporting that popular Debian-based community images often have ~300 CVEs where Chainguard equivalents have near zero at build time.89

Interpretation: The fair reading is not “these images will never have a CVE,” but:

“When we ship a fresh image, our goal is that no vulnerabilities are known in the components we include, and we rebuild aggressively to keep that as close to true as possible.”

How Chainguard Gets to (and Near) Zero CVEs

1. Minimal, distroless-style images

Chainguard Images are minimal, hardened, often distroless container images:

  • They “eliminate most of the unneeded packages and consequently, the vulnerabilities affecting these packages”, significantly reducing attack surface and vulnerability noise in scans.10
  • They often strip out up to ~80% of standard packages you’d see in a traditional Linux/container image, along with the majority of CVEs attached to them.11
  • External appsec practitioners have noted that migrating to Chainguard yielded “less CVEs for safer container runtimes” in practice.12

This is classic attack surface reduction: fewer components = fewer places to have vulnerabilities.

2. Built from source on Chainguard OS / Wolfi

Instead of inheriting a general-purpose distro, Chainguard uses its own Wolfi-based/Chainguard OS stack:

  • Packages are rebuilt from source with upstream security fixes applied, rather than copying pre-built distro packages.2
  • Chainguard OS is described as a minimal, hardened distro for containers, with components assembled and maintained specifically for this purpose.13
  • They keep only one current version of each Wolfi package, tracking the latest upstream version; older vulnerable versions are not left around as “dark matter.”14

This gives Chainguard more control over:

  • When a fix lands
  • How quickly it’s integrated
  • Avoiding long tails of old, unpatched components

3. Frequent rebuilds (“nano-updates”) and SLAs

A core operational promise: images are rebuilt constantly.

  • Docs state that Chainguard Containers are rebuilt nightly so they are “completely up-to-date and contain all available security patches.”15
  • Third‑party analysis describes daily “nano‑updates”, with critical CVEs patched within about 7 days and often earlier.2
  • Their security advisory docs emphasize that new vulnerabilities will appear over time, and that their primary effort is to keep the latest image versions “as close to zero CVEs as we can” and nudge customers to stay on supported versions.3
  • FIPS/regulated variants advertise an SLA around zero‑to‑minimal CVEs plus STIG hardening.5

In other words, the zero‑CVE claim is backed by a continuous rebuild and patch pipeline, not a one‑off marketing line.

4. Scanner compatibility and transparency tooling

Chainguard invests in making their images visible and understandable to common tooling, and in measuring their own performance:

  • They maintain SBOM attestations for every image, signed with their release automation so consumers can verify authenticity and provenance.16
  • They explicitly work to ensure compatibility with multiple vulnerability scanners, acknowledging this is “hard” and describing substantial engineering effort so scanners produce accurate, actionable findings.17
  • The Chainguard CVE Visualizations capability lets users compare CVE counts between Chainguard images and upstream/OSS alternatives over time.7
  • The Chainguard Images Directory exposes per‑image CVE status and security data, showing that images do accrue CVEs after release and are then remediated.18

Where the "Zero CVE" Story is Strong

1. Dramatic reduction vs typical base images

Chainguard’s own benchmarking plus external analyses support the claim that Chainguard images carry far fewer known CVEs than common alternatives:

  • A Chainguard hardened‑images report found that popular Debian‑based community images with Chainguard equivalents averaged nearly 300 CVEs, whereas the Chainguard versions showed zero or near‑zero at build time.9
  • Orca Security’s joint write-up reports a 97.6% reduction in CVEs in Chainguard images compared with standard OSS images.8
  • Multiple third‑party practitioners who switched to Chainguard observed visible scan improvements and reduced vulnerability noise.1210

This is consistent and well‑supported: if you scan a fresh Chainguard image with mainstream tools, you usually see zero or almost-zero CVEs, where the upstream image shows dozens or hundreds.

2. Operational discipline and fast reaction to new vulns

Chainguard appears to take the operational side seriously:

  • They recount cases where nightly rebuilds allowed them to fix vulnerabilities before they were widely detected or added to CVE feeds, due to pulling in latest upstream patches very quickly.19
  • For major incidents (e.g., the XZ/liblzma backdoor CVE‑2024‑3094), Chainguard published a detailed response, explaining how their supply‑chain processes and rebuild pipeline reacted and how affected artifacts were updated.20
  • Their docs emphasize a shared responsibility model: Chainguard keeps images updated, customers must regularly pull current tags and avoid pinning to stale, unsupported versions.21

Net effect: for teams that actually keep updating images, Chainguard’s model substantially reduces time exposed to known CVEs.

3. Alignment with compliance and regulated use cases

Chainguard’s approach aligns with regulatory and compliance pressures that increasingly expect low‑CVE baselines and demonstrable supply‑chain control:

  • FIPS/STIG‑aligned images, daily builds, SBOMs, signatures, and provenance make it easier for organizations to meet FedRAMP, financial, healthcare, and government requirements.522
  • Case studies (e.g., Snowflake, Cloudera) highlight how reduced CVEs in Chainguard‑based images contributed to meeting strict vulnerability budgets and Authority to Operate (ATO) expectations.2324

So for “can we get a base image portfolio that doesn’t blow our CVE SLOs?”, the answer with Chainguard is credibly yes.

Where the Claim Has Caveats and Limits

Even in Chainguard’s own materials, there are clear boundaries to the zero‑CVE promise.

1. Time window: zero at release, not over the image’s lifetime

Chainguard is explicit that CVEs accumulate after release:

  • Their security advisory docs: “When you scan a newly‑built Chainguard Container with a vulnerability scanner, typically, no CVEs will be reported. However, as software packages age, more vulnerabilities are reported and CVEs will begin to accumulate in container images.”3
  • Their focus is on keeping latest versions close to zero and pushing customers to upgrade; older tags can and do become stale and vulnerable.

Implications:

  • If you pin to a specific image digest and don’t update for months, the “zero known CVEs” property will not hold.
  • You only get the intended benefit if you consume fresh image builds relatively frequently.

2. Scanner and database discrepancies

Zero‑CVE is defined with respect to known vulnerabilities in particular data sources and scanners. Several nuances matter:

  • Chainguard itself has written about how vulnerability scanners miss or misreport issues, due to package dark‑matter, naming inconsistencies, and SBOM gaps; they even created a deliberately “most vulnerable” demo image to show how scanners can be tricked by mere artifacts/clues rather than actual vulnerable code.[^most-vuln-image]25
  • Their blog “This shit is hard: vulnerability scanner integration” lays out how much work goes into making Chainguard artifacts and advisory feeds map cleanly into common scanners—and that mismatches and false positives/negatives still occur.17
  • External reports note that different scanners and CVE feeds disagree, and that many “hardened” vendor images from the broader market still “harbour a significant number of vulnerabilities” despite their marketing.26

So in practice:

  • You may see different results across tools (Trivy vs Grype vs commercial scanners) even on the same Chainguard image.
  • “Zero known CVEs” usually means “zero known according to the scanners and data sources we target at build time,” not an absolute, tool‑independent truth.

3. Coverage gaps: unsupported software, dark matter, and non-CVE issues

The CVE system and scanners don’t cover everything:

  • Chainguard themselves describe “software dark matter”: orphaned files and components not tied to any package metadata, which scanners may not see at all.27
  • They also highlight “missing CVEs”: vulnerabilities that are fixed in code but never properly reflected in public databases or advisory feeds, so scanners and policies can’t see them.28
  • Vulnerability bulletins from CISA and others routinely include new vulnerabilities before CVSS scoring or complete metadata is available.29

Even if Chainguard is diligent, zero CVEs ≠ zero security risk:

  • Newly discovered vulnerabilities (zero‑days) will not have CVE IDs at build time.
  • Some components or configurations might be risky yet never receive CVE assignments.
  • Supply‑chain attacks (e.g., dependency backdoors) may not show up as CVEs for some time, if ever.

4. Newly disclosed vulns & lag between disclosure and rebuild

The timing of disclosure vs rebuild matters:

  • Chainguard’s own articles and external coverage show they generally react quickly, but there is always a window between vulnerability disclosure and your cluster pulling a rebuilt image.1920
  • If your deployment cadence is slow (e.g., quarterly image refreshes), you can still be running a known‑vulnerable image for weeks or months, regardless of Chainguard’s internal rebuild schedule.
  • Complex vulnerabilities (e.g., incomplete vendor patches like the NVIDIA container toolkit CVE‑2024‑0132 case) highlight how downstream consumers can still be exposed even when an upstream fix exists, if integrations or configs lag or patches are incomplete.30

So again: Chainguard lowers the bar substantially, but cannot eliminate the need for your own patching and roll‑out discipline.

5. Scope: only what’s inside the image

Chainguard’s guarantees are about what they build and ship:

  • Their shared‑responsibility docs explicitly focus on the image content and build pipeline; runtime environment, additional sidecars, application code, and configuration remain on the customer.21
  • External security write‑ups emphasize that zero‑CVE images don’t protect you from runtime misconfiguration, weak secrets, exposed services, or app‑layer vulnerabilities.3132

If you layer vulnerable application code, insecure libraries, or poor network policies on top, the “zero‑CVE base image” doesn’t magically fix that.

Net Assessment: How True is the "Zero CVE" Claim?

Accurate if you read it as an engineering practice, not an absolute

Based on vendor materials and independent coverage, the strong, defensible version of Chainguard’s claim is:

  1. Freshly built Chainguard Images are usually free of known CVEs in the components they include, when scanned with mainstream tools against major vulnerability feeds.
  2. Compared to typical distro-based images, Chainguard’s minimal, distroless, continuously rebuilt approach produces an order-of-magnitude reduction in known CVEs.
  3. Chainguard backs this with concrete operational practices: nightly/daily rebuilds, source‑based builds, signed SBOMs and provenance, active integration with scanners, and public advisories.

On those terms, the “zero known CVEs at release time” promise is credible.

Misleading if interpreted as permanent or absolute security

The claim breaks down or becomes misleading if interpreted more strongly than Chainguard themselves define it:

  • Not permanent: CVEs accumulate after release; only regularly refreshed images are close to zero.3
  • Not scanner‑agnostic: “zero” is always relative to some combination of CVE feeds + scanners + SBOMs; other tools may still flag issues.
  • Not total risk elimination: zero‑CVE images don’t address zero‑days, business-logic bugs, misconfigurations, or vulnerabilities in code you add on top.

Practical Takeaways if You’re Evaluating Chainguard Images

  1. Treat Chainguard as a strong baseline improvement, not a silver bullet.

    • It can cut known CVEs dramatically and de‑noise vulnerability management, especially vs stock distro images.

  2. Plan for continuous refresh of images.

    • To “stay zero‑ish,” you must regularly pull the latest tags and avoid long‑lived, pinned images.

  3. Use multiple scanners and validate against your own policies.

    • Expect some discrepancies across tools; verify with at least one of the scanners Chainguard targets, but don’t rely on a single view.

  4. Keep doing full security work: threat modeling, config hardening, and app‑layer testing.

    • Zero‑CVE bases are one layer. You still need runtime controls, least privilege, secret management, and app security testing.

  5. If compliance is your driver, Chainguard’s FIPS/STIG images, SBOM + provenance story, and CVE visualizations can materially help, as long as you align your update cadence and SLOs with their rebuild pipeline.

Suggested Follow-up Questions

References

Footnotes

  1. Chainguard repeatedly defines its goal as container images with “zero known CVE (Common Vulnerabilities and Exposures) at release time” that are “kept continuously up-to-date to eliminate known vulnerabilities”.2 ↩

  2. “Chainguard’s ‘zero‑CVE’ container images are container-based images with zero known CVE at release time, which are kept continuously up-to-date to eliminate known vulnerabilities.” – W. Konitzer on Chainguard images and APT threats.[https://medium.com/@wkonitzer/securing-software-with-chainguard-zero-cve-base-images-against-advanced-persistent-threat-groups-300e26fbeb54] ↩ ↩2 ↩3 ↩4

  3. Chainguard security advisories docs: “When you scan a newly-built Chainguard Container with a vulnerability scanner, typically, no CVEs will be reported. However, as software packages age, more vulnerabilities are reported and CVEs will begin to accumulate in container images… our efforts are centered on keeping the latest versions up-to-date and as close to zero CVEs as we can.”[https://edu.chainguard.dev/chainguard/chainguard-images/staying-secure/security-advisories/how-chainguard-issues/] ↩ ↩2 ↩3 ↩4

  4. AWS Marketplace listing describing Chainguard images as “Low-to-zero known CVEs with daily patches and rebuilds.”[https://aws.amazon.com/marketplace/pp/prodview-hqh3qlqbdbaqo] ↩

  5. Chainguard FIPS/STIG images: “All FIPS images include STIG hardening, daily builds with zero-to-minimal CVEs under SLA, and build-time SBOMs.”[https://edu.chainguard.dev/chainguard/fips/fips-images/] ↩ ↩2 ↩3

  6. Chainguard claims to maintain “the industry’s most extensive set of trusted container images with zero known vulnerabilities at release.” – Meeting the Zero‑CVE Mandate.[https://www.chainguard.dev/unchained/meeting-the-zero-cve-mandate-how-chainguard-helps-businesses-ship-secure-software-that-customers-trust] ↩

  7. Chainguard CVE Visualizations and Image Directory described as “Get started with CVE-free container images today” and tools to compare CVE numbers between Chainguard Containers and upstream.[https://www.chainguard.dev/solutions/cve-remediation] ↩ ↩2

  8. Orca/Chainguard joint blog: “Chainguard is the safe alternative to traditional open-source software, with a demonstrated 97.6% reduction in CVEs compared to OSS equivalents.”[https://orca.security/resources/blog/container-security-chainguard-orca/] ↩ ↩2

  9. Chainguard hardened images report summarised as: “Popular Debian-based, community-supported images that have a Chainguard Images equivalent have, on average, nearly 300 CVEs.”[https://get.chainguard.dev/hubfs/Collateral/Reports_and_Whitepapers/ChainguardHardenedImagesReport.pdf] ↩ ↩2

  10. AppSec Untangled article: “Chainguard images are minimized hardened container images that eliminate most of the unneeded packages and consequently, the vulnerabilities affecting these packages, which significantly reduces the risk and noise caused by container vulnerabilities.”[https://medium.com/appsec-untangled/why-chainguard-images-is-a-game-changer-for-container-vulnerabilities-822554968b38] ↩ ↩2

  11. Techtarget: Chainguard image format “strips out up to 80% of standard packages included in most container images and Linux operating system distributions, and with them a majority of known vulnerabilities.”[https://www.techtarget.com/searchitoperations/news/366545164/Chainguard-automates-SBOMs-but-has-Images-based-agenda] ↩

  12. Practitioner write-up: migrating to Chainguard Images leads to “less CVEs for safer container runtimes”; notes that CVE counts “naturally fluctuate as new CVEs come out and new patches are available.”[https://dev.to/erikaheidi/migrating-to-chainguard-images-less-cves-for-safer-container-runtimes-j17] ↩ ↩2

  13. Chainguard OS overview describing a minimal, hardened base for container images.[https://edu.chainguard.dev/chainguard/chainguard-os/overview/] ↩

  14. FAQ: “Starting in March of 2024, Chainguard will maintain one version of each Wolfi package at a time. These will track the latest version of the upstream software in the package.”[https://edu.chainguard.dev/chainguard/chainguard-images/faq/] ↩

  15. Chainguard overview docs: “Chainguard Containers are rebuilt nightly to ensure they are completely up-to-date and contain all available security patches.”[https://edu.chainguard.dev/chainguard/chainguard-images/overview/] ↩

  16. “All Chainguard Images contain SBOM attestations, which are signed by our release automation, so that processes consuming the SBOMs can validate the authenticity of our SBOM’s provenance.”[https://www.chainguard.dev/unchained/into-the-deep-exploring-chainguard-container-images] ↩

  17. “At Chainguard we go to pretty extreme lengths to ensure that a variety of scanners can integrate with Chainguard's artifacts and advisory feeds, to produce accurate, actionable findings.” – on scanner integration.[https://www.chainguard.dev/unchained/this-shit-is-hard-vulnerability-scanner-integration] ↩ ↩2

  18. Chainguard Images security pages list per‑image CVEs and fix status (e.g., CVE‑2025‑63811 fixed in specific vault‑fips image revisions).[https://images.chainguard.dev/security] ↩

  19. Chainguard materials describe how nightly builds and rapid upstream patching mean they sometimes “fix vulnerabilities before they’re detected” by scanners.[https://www.chainguard.dev/unchained/how-chainguard-fixes-vulnerabilities-before-theyre-detected] ↩ ↩2

  20. Chainguard’s response to CVE‑2024‑3094 (XZ backdoor) details how their process identified and updated affected artifacts.[https://www.chainguard.dev/unchained/chainguards-response-to-cve-2024-3094-aka-the-backdoor-in-xz-library] ↩ ↩2

  21. Chainguard’s shared responsibility model explains they rebuild upstream software with latest toolchains and dependencies, but customers are responsible for consuming updated images and securing their own runtime.[https://edu.chainguard.dev/chainguard/chainguard-images/about/shared-responsibility-model/] ↩ ↩2

  22. Salesforce Ventures overview: “Dozens of enterprise customers, including Snowflake, HPE, Anduril, and Wiz rely on Chainguard’s container images to enable their compliance with federal government authorizations.”[https://salesforceventures.com/perspectives/welcome-chainguard/] ↩

  23. Chainguard case study with Snowflake describes reduced vulnerabilities helping assure users and meet regulated-industry expectations.[https://www.chainguard.dev/customers/securing-trust-in-the-data-cloud-snowflakes-journey-with-chainguard] ↩

  24. Cloudera press release: leveraging Chainguard to set a new standard for enterprise data security and satisfy rigorous ATO/ConMon requirements.[https://www.cloudera.com/about/news-and-blogs/press-releases/2025-10-22-cloudera-leverages-chainguard-to-set-a-new-standard-for-enterprise-data-security.html] ↩

  25. Chainguard and external sources describe how scanners rely on package metadata, naming conventions, and advisory feeds, and can both miss vulnerabilities and generate false positives.[https://www.chainguard.dev/supply-chain-security-101/what-is-vulnerability-scanning-and-how-does-it-work] [https://beaglesecurity.com/blog/article/limitations-of-vulnerability-scanners.html] ↩

  26. Threatintelligence.com reviewing Chainguard’s own hardened images report notes that many “hardened” vendor images still “harbour a significant number of vulnerabilities.”[https://www.threatintelligence.com/blog/container-security] ↩

  27. Chainguard’s discussion of “software dark matter” in debloated images: orphaned files not captured in package lists, which scanners may miss.[https://medium.com/@wkonitzer/debloating-container-images-security-boost-or-supply-chain-risk-c3929824efd4] ↩

  28. Chainguard blog on “vulnerability fixes in plain sight” describing “missing CVEs” that scanners never see because databases and advisories are incomplete.[https://www.chainguard.dev/unchained/vulnerability-fixes-in-plain-sight-how-your-scanners-are-missing-hundreds-of-vulnerabilities] ↩

  29. CISA vulnerability bulletins show new vulnerabilities weekly, often before full scoring or broad scanner coverage.[https://www.cisa.gov/news-events/bulletins] ↩

  30. Trend Micro and others documented how an incomplete NVIDIA container toolkit patch left systems exposed to CVE‑2024‑0132, illustrating the difficulty of relying solely on upstream patch signals.[https://hackread.com/incomplete-patch-leaves-nvidia-docker-users-at-risk/] [https://www.linkedin.com/pulse/incomplete-nvidia-patch-exposes-ai-infrastructure-qdxke] ↩

  31. Practitioner guidance (e.g., Docker/Kubernetes security books and blogs) consistently note that hardened base images reduce risk but must be combined with network, identity, and app‑layer controls.[https://www.dockersecurity.io] ↩

  32. Security overviews of software supply-chain risks (e.g., Armosec, CISA) stress that container image vulnerabilities are only one slice of a broader attack surface.[https://www.armosec.io/blog/software-supply-chain-security/] [https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf] ↩

Explore Further