Buying zero-CVE base images trades a predictable subscription fee for the unpredictable engineering cost of patching base images yourself; the subscription usually wins once you maintain more than a handful of distinct images or face customer-facing CVE SLAs, while DIY hardening wins when your image count is small, your stack is unusual, or procurement friction outweighs engineer-hours. Neither option removes the vulnerabilities in your own application layer, which is where the actual incidents tend to originate.
First, an honest definition. "Zero CVE" means zero known, unpatched CVEs in the image at scan time — vendors like Chainguard, Minimus, and Docker (Hardened Images) achieve it by shipping minimal images, rebuilding nightly, and backporting fixes fast. It is a maintenance promise, not an immunity guarantee: tomorrow's disclosure applies to today's "zero-CVE" image just the same. Treat the marketing phrase as "aggressively patched and minimal" and the comparison gets rational.
What you're actually comparing
| Dimension | Zero-CVE subscription (Chainguard-class) | DIY hardening (distroless/Alpine/scratch + your pipeline) |
|---|---|---|
| Upfront cost | Procurement cycle, migration effort | Engineering design: multi-stage builds, base selection |
| Ongoing cost | Subscription (commonly five to six figures/year at org scale, per-image pricing) | 0.25-1.0 FTE for a real image factory: rebuilds, triage, exceptions |
| Patch latency (base OS CVEs) | Hours-days, vendor SLA | Whatever your rebuild cadence and on-call attention deliver |
| CVE scanner noise | Near zero in base layers | Dozens-hundreds per image on glibc distros; fewer on Alpine/distroless |
| Stack coverage | Vendor's catalog (large, but finite) | Anything you can build |
| Supply chain posture | Signed, SBOM-attached, SLSA-provenance builds | As good as you make it — sigstore, SBOMs, provenance are all DIY-able |
| Lock-in | Image references + package naming conventions (Wolfi/apk) | None beyond your own tooling |
The real cost of "free" DIY
The Dockerfile is the cheap part. A credible internal hardening program means: nightly rebuilds of every base image, automated promotion when scans pass, a triage rotation for new CVEs, an exceptions register for the unfixable ones, and someone who answers "are we affected?" within hours of the next Log4Shell-class event. Across teams we've worked with, that lands between a quarter and a full FTE once you pass roughly 10-15 distinct base images — call it $40k-$180k/year in loaded cost, which is the number to put next to the vendor quote. Most orgs discover this cost only after they've committed, because the first three months of DIY are genuinely easy.
There's also the fatigue line-item nobody budgets: a standard debian:bookworm-based image carries dozens of low/negligible CVEs with no fix available upstream. Your scanner reports them forever, your customers' scanners report them forever, and your security team answers the same questionnaire questions forever. Distroless bases cut this dramatically — our distroless vs Chainguard vs Wolfi comparison has the layer-by-layer numbers.
Where zero-CVE subscriptions earn their price
Three situations flip the math decisively toward buying:
- Contractual CVE SLAs. If enterprise or government customers require "no critical CVEs older than N days" (FedRAMP-adjacent language increasingly does), a vendor SLA converts your compliance risk into their engineering problem.
- Wide image estates. Fifty services on twelve runtimes means your image factory is a product. Vendors amortize that cost across hundreds of customers; you can't.
- Audit-grade provenance out of the box. Signed images, per-image SBOMs, SLSA provenance — assembling this yourself with cosign and syft is entirely doable, but it's another quarter of platform work.
The honest counterpoints: catalog gaps are real (that CUDA-pinned ML image or ancient PHP runtime may not exist in the vendor catalog, and now you're hybrid), pricing scales per-image in ways that surprise at renewal, and migrating means retraining everyone who types apt-get in a Dockerfile — Wolfi-based images use apk semantics and different package names, which breaks more Dockerfiles than teams expect.
The risk math both camps get wrong
Base-image CVEs are the most visible vulnerability class and among the least exploited in containerized breaches. The attacks that actually land come through your application dependencies, leaked credentials, and exposed control planes. A zero-CVE base under an app layer with a reachable deserialization bug is a clean-looking compromised system.
So sequence accordingly: run SCA with reachability analysis on the application layer first — that's where exploitable findings concentrate — and treat base-image strategy as a noise-reduction and compliance play. Generate SBOMs for the whole image, not just the base, so the next ecosystem-wide incident is a query in SBOM Studio rather than a war room. Scanning discipline matters more than base pedigree: an unmonitored zero-CVE image from last quarter is strictly worse than a monitored Debian image from last night.
A decision rule
- Fewer than ~10 base images, no CVE SLAs, standard stacks → DIY on distroless or Alpine, nightly rebuilds via a scheduled pipeline, and spend the savings on application-layer scanning.
- CVE SLAs in contracts, or 15+ distinct images, or a lean platform team → subscribe for the catalog-covered images, DIY the gaps, and negotiate per-image pricing with your growth curve in writing.
- Regulated/air-gapped → either works, but test the vendor's offline mirror story before signing; some "zero-CVE" pipelines quietly assume registry connectivity.
Most orgs past a certain size end up hybrid, and that's fine — the failure mode isn't picking the wrong option, it's running either one without the rebuild-and-rescan discipline that makes both work.
Frequently asked questions
Does a zero-CVE base image mean my container is secure?
No — it means the base layers had no known unpatched CVEs at build time. Your application dependencies, your code, your secrets handling, and your runtime configuration are untouched by the base image choice, and that's where most container compromises actually start.
Can I get to zero CVEs with free images alone?
Often close: Google's distroless images and scratch-based Go binaries frequently scan clean or nearly so. What you don't get is the rebuild SLA — when the next glibc CVE drops, you're waiting on upstream and your own pipeline rather than a contractual turnaround, which is precisely what the subscription is priced on.
How do zero-CVE vendors handle CVEs with no upstream fix?
Typically by backporting patches themselves, removing the affected component from the minimal image, or publishing a VEX statement documenting non-exploitability. Ask to see a real example of each during evaluation — the VEX quality varies meaningfully between vendors.
Is Alpine a shortcut to fewer CVEs?
Partly — musl and the small package set genuinely shrink the CVE surface, but musl introduces compatibility landmines (DNS behavior, glibc-assuming binaries) that cost debugging time. Distroless variants of glibc distros often hit a better compatibility-to-noise ratio for typical web services.