Zero CVE Images in 2026

Two years after "Your Guide to Zero CVE Images," the market data backs up the original advice: pick a mainstream OS first, then get to zero.

In December 2024, Your Path to Near-Zero CVE Images: A Practical Approach was published. Its core argument was simple: a "zero CVE" image only helps if it's built on an operating system you can live with for years. It should be mature, widely supported, independently tracked, and readable by every scanner you use.

Since then, "zero CVE" has gone from niche to mainstream. Several vendors now ship their own Linux distributions built specifically to show an empty scan report. So it's worth asking whether the original advice still holds.

I think the chart below answers that question

Estimated share of production container workloads by base OS in 2026, split into commercial, finance/large regulated, and public sector (DoD/federal), with DISA STIG status for each OS. Ranges are triangulated from Docker Hub pull data, Iron Bank com

What the data shows

1. Three distributions run most commercial workloads. Debian (30–40%), Ubuntu (20–25%), and Alpine (15–20%) together account for roughly two-thirds or more of commercial container workloads. Debian's lead comes largely from the official language images (python, node, openjdk, and others), along with slim and distroless variants that many teams adopted without consciously choosing an OS.

2. Regulated industries shift toward Red Hat. In finance and large regulated organizations, Red Hat (UBI/RHEL) climbs to an estimated 20–35%. In the public sector it dominates at 40–55%, with Ubuntu (12–20%) a distant second. Supported lifecycles, certification, and compliance tooling drive these choices more than image size does.

3. Vendor-built "zero CVE" distributions are still rounding errors. Chainguard OS, Wolfi, WizOS, and Azure Linux each sit below 1% in every segment. They may well grow. But today, adopting one means moving your workloads onto an OS that almost nobody else runs in production.

4. STIGs split the field. Look at the second column. Ubuntu (22.04, 24.04 LTS), RHEL (9, 10), Amazon Linux 2023, and Oracle Linux (8, 9) all have DISA STIGs. Debian and Alpine don't, and neither does any of the vendor-built distributions. Chainguard OS offers vendor-written guidance mapped to the SRG, which is not a DISA STIG. If you sell to DoD or federal agencies, that column may matter more than any CVE count.

The four principles, revisited

1. Start with a mature, widely supported OS

This is still the most important decision, and the chart shows why. Your base OS shapes your package manager, your C library (glibc or musl), your file layout, your team's skills, and every Dockerfile you maintain. Moving a large fleet onto a distribution used by less than 1% of the market is a re-platforming project, not a security patch. It also ties your OS lifecycle, and your pricing, to one company's roadmap.

The better approach is to get to near-zero CVEs on the OS you already run. For most organizations that means Debian, Ubuntu, Alpine, or UBI.

2. Prefer curated images over rebuilding from scratch

Scratch and minimal images work well for greenfield services with small teams. Most enterprises run brownfield estates with legacy code, native dependencies, and Helm charts that expect specific packages to be present. For those workloads, a curated base image is the practical route. It keeps the same OS, the same components, and the same version tags, but it is continuously patched so the fixed CVEs simply stop appearing in your scan results.

In practice the switch is usually one FROM line:

# Before
FROM python:3.13-bookworm

# After
FROM quay.io/rfcurated/python:3.13.14-jammy-rfcurated

(Tag shown for illustration. Curated tags are fully patch-versioned and roll forward often, so confirm the current one with rfcatalog -r python before you build.)

Once you're on a curated base, runtime hardening comes next. You profile what the application actually uses, then remove everything else. The order matters: patch first, then reduce.

3. Insist on trustworthy, independent advisories

When one company builds the distribution, writes the advisories, and sells the "zero," that's a conflict of interest. Mainstream distributions have public security trackers, large and varied maintainer communities, and long track records that anyone can audit.

The same standard applies to vulnerability triage. If an image vendor marks a scanner finding as a false positive, ask for the evidence: NVD entries, distro tracker records, upstream commits, or backport data. Ask too whether that determination stays the same no matter which scanner reported it.

4. Make sure every mainstream scanner can verify the claim

A "zero" only counts if your own tools can confirm it. Trivy, Grype, Wiz, Prisma, and other scanners all have mature detection and vulnerability data for Debian, Ubuntu, Alpine, and RHEL. Newer or custom distributions depend on each scanner adding and maintaining support. Until that happens, an empty report might mean "no vulnerabilities," or it might mean "nothing recognized."

In 2026 I'd add a fifth requirement: cryptographic provenance. Every base image you adopt should be signed and should ship with a verifiable build attestation, such as SLSA provenance checked with cosign. That way your CI pipeline and admission controller can prove the image you run is the image your vendor built, without having to trust the vendor's word.

What this looks like in practice

Results depend on your starting point, but here are two reference examples:

• A 13-image Kubernetes cluster: switching to curated images cut CVEs from 5,286 to 505 (86%) in about a day of work. Adding runtime profiling and hardening brought the total to 3 over roughly five days.
• A Java 21 Spring Boot app on Debian 12: the original image had 101 CVEs and was 839 MB. After the curated base swap it had 4 CVEs at 528 MB. After hardening it had 0 CVEs at 241 MB.

Neither example required changes to application code or a move to a different OS.

A short checklist for 2026

1. Inventory your base OS mix. Most teams find more Debian than they expected, because it comes in through the official language images.
2. Map your compliance requirements to that mix. If DISA STIG applies, your options are Ubuntu, RHEL/UBI, Amazon Linux, or Oracle Linux.
3. Swap to curated equivalents of the OS you already run before you consider re-platforming.
4. Verify with your own scanner and your own signature check, not just your vendor's dashboard.
5. Harden with runtime profiles to reduce attack surface and image size after the CVE count is under control.

The bottom line

Zero CVE images are now expected rather than unusual. But "zero" is an outcome, not a strategy. The strategy is still the one from 2024: pick a mature, widely supported OS, keep advisories independent, and make sure your own tools can verify the result. Then use curated images and hardening to get to zero without re-platforming.

The market has largely made the OS decision already. The right zero-CVE approach should fit that decision instead of asking you to replace it.

If you want to see what curated images look like for the OS you already run, browse the catalog at hub.rapidfort.com.