What CVE Counts Miss About Container Security

Container scans can produce a reassuringly simple number, but that total rarely tells the full story. Two tools may return different results for the same image.

A severe-looking finding might also relate to a package whose vulnerable code path is unreachable or whose fix has already been backported.

The total becomes useful only when teams know what was scanned, whether a patch exists and whether the flaw can affect the running image.

Define What Near Zero Actually Means

For teams setting an acceptable vulnerability threshold, Near Zero CVE Images represent a policy that must be maintained rather than a guarantee that every scanner will return an empty report.

The Minimus analysis focuses on findings teams can act on, the patches available and any exceptions they have chosen to retain.

In practice, teams may set the line at having no unresolved critical or high-severity findings once a fix becomes available. Vulnerabilities without patches still need an owner and a date for review.

When a finding is marked as not affecting the image, that decision should be supported by technical evidence rather than used simply to lower the reported total.

A CVE identifier confirms that a weakness has been catalogued. It does not prove that the affected function is present, reachable, or exploitable inside a particular container.

That distinction matters more as the CVE system grows. In its April 2026 NVD update, NIST reported that CVE submissions rose 263% between 2020 and 2025.

It responded by introducing a risk-based enrichment model. Every submitted record remains listed, although lower-priority entries may not immediately receive the extra analysis traditionally associated with the National Vulnerability Database.

The figure covers the CVE system as a whole. It should not be read as the average number of flaws inside a container image. What it does show is that vulnerability records may appear before complete information on severity, affected products, or remediation is available.

Understand Why Scanner Results Diverge

Two scanners can inspect the same image digest and report different totals. Their data feeds may refresh at different times and each tool may use its own method for identifying packages and matching versions.

Coverage of operating-system software and language dependencies also varies.

Linux backports are a common source of disagreement. A distribution maintainer may patch the vulnerable function while retaining an older package version for compatibility.

A scanner relying mainly on upstream version numbers might continue to flag the CVE. Another tool that checks the distribution’s security advisory may recognize that the package has already been fixed.

Rejected, disputed and duplicate records create further variation. Some scanners keep them visible, while others exclude them from the final count. Neither result is automatically wrong.

The tools may be working from different feeds or applying different matching rules.

Before acting on the total, teams need to confirm that the component is present, that the finding applies to the exact build and that a usable fix exists.

That means checking the package, Linux distribution and image digest rather than accepting the headline number on its own. Using one scanner consistently for policy enforcement makes trends easier to compare over time.

Distribution advisories and secondary feeds can then be used when a result appears inconsistent or disputed.

Add Context Before Prioritising Findings

An SBOM ties package names and versions to a specific artifact. It should be associated with the exact image digest rather than a general release label, particularly when several images share the same application version.

Guidance on using SBOMs to audit container images explains how component inventories can trace Linux packages and third-party dependencies across deployed systems.

Those records also help teams locate every image affected when a new flaw is disclosed.

The next step is confirming whether the finding actually applies. VEX can record that a product is affected, fixed, or not affected, provided the status includes a defensible explanation.

The vulnerable code may have been excluded from the compiled artifact, for example, or may never be executable within that container.

Once applicability is clear, teams still need to decide what should be handled first. CVSS describes potential technical severity.

CISA’s Known Exploited Vulnerabilities catalog identifies flaws with evidence of active exploitation, while EPSS estimates the probability of exploitation in the wild during the following 30 days.

These sources can help sort the workload, although the final decision still depends on the affected system and its exposure.

Minimus examines the base-image side of the issue through package reduction, signed component records and rebuilding when upstream fixes become available.

Fewer packages usually produce fewer inherited findings and leave less software to investigate after disclosure. Application libraries and runtime configuration require separate attention.

Keep the Image Below the Threshold Over Time

Today’s clean scan may look different after the next database update. The image digest can remain unchanged while new CVEs are published, severity scores are revised, or evidence of exploitation emerges.

Useful measurements include the proportion of production images meeting the agreed threshold and the time needed to replace an affected base.

Teams can also track expired exceptions and repeated findings caused by services that remain pinned to obsolete images.

Maintaining near-zero CVE Images requires unchanged digests to be rescanned, affected bases to be rebuilt and temporary exceptions to be reviewed.

The count means little unless the team understands the remaining findings and can replace the image quickly when new information appears.