The hunt for truly zero-CVE container images

Vendors chasing “zero-CVE” container images on top of traditional Linux distributions are running into structural limits in upstream release models. CVEs remain a useful, but imperfect metric, for measuring safety. 

We all want zero Common Vulnerabilities and Exposures (CVEs) in our container images, and creating such images has become a business in itself. What started as an aggressive “shift‑left” posture has become a baseline expectation for containerized workloads. But what’s the best way to create these safe images? 

Chainguard, one of the leading zero-CVE container image vendors, uses its new software, Factory 2.0, and its DriftlessAF open-source approach to rebuild containers and libraries directly from source whenever an upstream change is detected. Each container build manifest represents a reproducible output of the system, spanning initial builds, dependency and vulnerability-driven rebuilds, tooling changes, and generated SBOMs and signatures, all reconciled toward a secure-by-default state. 

Other zero-CVE image builders, such as Docker with its Docker Hardened Images (DHI), offer a reduced attack surface, non‑root defaults, SBOMs, and cryptographic provenance, and take a different approach. Those are tied to the Alpine Linux and Debian Linux upstreams. 

Sam Katzen, Chainguard’s Staff Product Marketing Manager, argues in a recent interview with The New Stack that “the long dependency chains and slower release cycles of upstream distro maintainers […] simply cannot keep pace with today’s explosive growth in reported vulnerabilities. Because these vendors rely on upstream distros to patch and rebuild, there is an inevitable lag between disclosure and a fix. This puts vendors that rely on distros like Debian or Alpine in a bind: they inherit vulnerabilities they didn’t create and can’t easily control.”

When non-DSA is not enough

Diving deeper, Katzen states that because DHI is built directly on Debian, its images inherit Debian’s package set, security posture, and release timeline. In practice, many of DHI’s Vulnerability Exploitability eXchange (VEX) entries — machine-readable documents that tell scanners whether a CVE actually affects a given image — effectively mirror Debian’s own Security Advisory (DSA) triage state.

Debian’s security team uses the “no‑DSA” flag in its tracker for issues that do not warrant an immediate DSA and out‑of‑cycle rebuild. These decisions are often made because the security problems are considered minor or too difficult to exploit for them to be worth fixing immediately. Debian DSA documentation explicitly frames “no‑DSA” as an advisory‑prioritization mechanism. To be exact, “Such issues are not kept unfixed in general, but can still get fixed via a point update or by piggybacking the fix with a future update for a more severe issue.”

That may be good enough for Debian, but Katzen thinks that may not be good enough for you. True, he says, “Many of the CVEs flagged no-DSA are completely unexploitable and reasonable to address in this way.” Nevertheless, treating that triage flag as proof that a package is “not affected” conflates risk prioritization with the absence of vulnerabilities and can mislead downstream consumers who rely on scanners wired to VEX.

This is a meaningful issue when upstream maintainers have already merged fixes, but those fixes have not yet landed in Debian, and therefore not yet in DHI. Specifically, Katzen points out three significant CVEs that haven’t been caught and fixed yet in Debian.

• CVE‑2026‑0861: This glibc flaw in the memalign family can lead to integer overflow and heap corruption, and is rated HIGH (8.4) in the National Vulnerability Database (NVD). Debian currently lists multiple releases, including bookworm and trixie, as vulnerable, with a fix only in a newer “forky” series. Despite this, DHI’s VEX entry associated with Debian’s “no‑DSA” classification marks affected images as “not affected,” citing that the vulnerable code cannot be controlled by an adversary, while continuing to ship the unpatched Debian glibc. Because many DHI images, such as language runtimes and databases, depend on glibc, that status effectively suppresses a real, unpatched CVE from scanner output.
• CVE‑2026‑0915: A separate glibc issue that can leak memory contents is also rated HIGH (7.5) by NVD and likewise marked with “no‑DSA” in Debian, signaling a decision to defer the fix to a regular release. Here too, DHI’s VEX data follows Debian’s prioritization, labeling images as “not affected” even though the underlying Debian package version remains listed as vulnerable and no downstream patch has been applied. Until Debian rebuilds or a downstream vendor cherry-picks the upstream commit, images that embed that glibc build are technically affected, and scanners should reflect that state.
• CVE‑2025‑6141 (ncurses): This ncurses bug permits a stack buffer overflow when processing termcap entries, requires local access, and is rated low severity. This bug was fixed in the upstream in ncurses 6.5‑20250329 in March 2025. Months later, Debian still had not shipped a patched package for all relevant releases and marked the CVE “no‑DSA,” deferring remediation to its standard cycle. DHI’s VEX history for at least one Debian‑based image first recorded the issue as “under investigation” while “waiting for upstream fix,” then later flipped the status to “not affected” based on the Debian no‑DSA tag – again without evidence that a fixed ncurses build had been integrated into the image.

Therefore, Katzen states, “the vulnerability exists in DHI, and a fix is available upstream, but the fix has not been pulled into DHI. The CVE is suppressed in scans automatically by Docker Scout and through the use of the VEX document in other scanners.”

Are hardened images enough?

From where Chainguard sits, this means vendors building “hardened” images on top of general‑purpose community distributions can find themselves caught between transparency and reaching near‑zero CVE count. Cherry-picking fixes ahead of Debian would push Docker and others who use a similar cadence into maintaining a de facto fork, with all the long‑term maintenance and regression headaches that implies. 

Katzen claims this shifts the tension onto customers and their tooling. As VEX becomes more deeply integrated into scanners and compliance workflows, over‑aggressive suppression of “inconvenient” CVEs undermines the very promise of normalized, machine‑readable exploitability data.

He then, of course, praises Chainguard’s model, where CVE triage and remediation can be driven directly from source to image without waiting on upstream distro schedules. That end‑to‑end control underpins its catalog of 2,000‑plus minimal images that are continually rebuilt to maintain a zero‑CVE state while preserving supply‑chain visibility, SBOMs, and explicit CVE handling. 

On the other hand, you could argue that some CVEs really are, as the Debian maintainers would say, not as serious as they appear. Therefore, you can wait for them to be fixed.

But how important are CVEs anyway?

But this debate also raises a more fundamental question: is the CVE system itself the problem?

Some security organizations and companies, such as the Cloud Security Alliance and SecOps Solution, contend that CVEs are environment‑agnostic. They say “a vulnerability exists,” but they don’t say whether it’s dangerous for your deployment. 

On top of that, according to one study, as many as a third of CVEs aren’t valid. Dr. Aram Hovsepyan, co-founder and CEO of security business Codific, points out, “For security professionals, a CVE entry is also a valuable addition to a résumé. This creates a clear motivation to generate more CVEs, even when the impact may be questionable. Moreover, the system can be gamed, and creating a CVE for the sake of it isn’t particularly difficult.” Adding insult to injury, it’s all too easy to use AI to create bogus security reports, as cURL creator Daniel Stenberg recently pointed out.

In other words, as Hovsepyan comments, “CVEs aren’t useless. They’re valuable inputs. But they should never be the foundation of an entire AppSec strategy. We need to start with a shared understanding of risk, grounded in threat modelling and contextual triage. Vulnerability dashboards can help, but only when interpreted through a scientific lens.”

In short, there’s something to be said for both approaches, and CVE counts alone are not enough to be certain your images are completely safe. Zero counts, but you can’t assume zero means safety. No one ever said security was easy. These new images help, but they’re not perfect. 

The post The hunt for truly zero-CVE container images appeared first on The New Stack.