TL;DR: Container base images now sit at the centre of software supply chain risk, with Rapidsort arguing that mature distributions, curated images, and scanner visibility matter more than cosmetic CVE counts. The practical issue is not eliminating every vulnerability, but reducing inherited exposure before workloads ever reach production.
At a glance
What this is: This whitepaper argues that near-zero CVE container images matter most when they come from mature distributions, are easy for scanners to recognise, and reduce inherited supply chain risk before deployment.
Why it matters: Container teams and IAM-adjacent platform teams need to treat base images as governance objects, because image provenance, patching, and visibility shape the trust boundary for CI/CD and runtime workloads.
By the numbers:
- 85% of enterprise software is open source.
- 10 hrs from vulnerability disclosure to active exploit.
Context
Near-zero CVE container images are a supply chain control, not a magic fix. They reduce inherited vulnerabilities in base layers, but they still depend on how well teams govern provenance, scanner visibility, dependency updates, and the realities of brownfield application builds.
For IAM and platform security teams, the identity angle sits in the trust chain around CI/CD runners, build systems, and curated images. If image origin, patch status, and runtime dependency drift are not governed, the pipeline can hand production workloads a false sense of assurance rather than a meaningful reduction in exposure.
Key questions
Q: What fails when container images are small but not well governed?
A: Small images do not automatically mean lower risk if teams cannot prove what is inside them, who maintains them, and whether scanners can identify them correctly. In that case, exposure is simply compressed into a harder-to-audit package, which weakens assurance and delays remediation when vulnerabilities are discovered.
Q: Why do mature base images reduce software supply chain risk?
A: Mature base images reduce inherited risk because they arrive with broader community scrutiny, regular patch cycles, and clearer vulnerability reporting. That gives teams a more reliable starting point than ad hoc or obscure distributions, especially when application teams depend on third-party packages they did not author.
Q: How do teams know whether near-zero CVE claims are real?
A: Teams should verify that their scanners, SBOM processes, and vulnerability databases correctly recognise the exact image family and its components. If the tooling cannot classify the image consistently, the CVE count may be incomplete rather than genuinely low, which creates false confidence.
Q: When should organisations choose curated images over scratch images?
A: Curated images are usually the safer choice when workloads have legacy dependencies, unclear package requirements, or limited engineering capacity for continuous rebuilds. Scratch images can be effective, but only when the team can maintain the dependency graph and hardening effort over time.
Technical breakdown
Why curated base images reduce inherited attack surface
Curated base images package operating system components, common libraries, and selected runtime dependencies into a maintained starting point for application builds. That matters because most enterprise applications inherit more risk from what they consume than from what their developers write. A well-maintained base image reduces the number of known CVEs that reach later stages of the pipeline, but only if teams understand what is included, what is updated, and what is intentionally excluded. The control is structural, not cosmetic: the goal is to remove unnecessary exposure before deployment rather than scanning it into existence later.
Practical implication: choose base images with predictable patching and a clear dependency model, then govern them as a supply chain control.
Why scanner recognition matters to near-zero CVE claims
A container image only becomes operationally useful when security tooling can identify what it contains. If a distribution is obscure, custom, or poorly mapped in vulnerability databases, mainstream scanners may miss components or fail to reconcile findings accurately. That creates a blind spot where a low CVE count may reflect poor detection rather than low risk. For container governance, scanner recognition is part of the assurance model because risk scoring, exception handling, and audit evidence all depend on consistent identification across build and runtime tools.
Practical implication: validate that your scanners recognise the exact image family before you accept its CVE posture as real.
How scratch images and curated images change maintenance burden
Scratch images are minimal and can reduce attack surface, but they shift responsibility for dependency tracking, hardening, and updates entirely onto the application team. Curated images absorb much of that maintenance work up front, which is why they are often better for brownfield systems with legacy dependencies or unclear package requirements. The trade-off is operational: minimalism can look attractive, yet without disciplined rebuild and profiling practices it can increase breakage and slow remediation. In practice, the right choice is the one your team can maintain continuously rather than the one that appears smallest on paper.
Practical implication: use scratch images only where you can own continuous rebuild discipline, not just initial hardening.
Threat narrative
Attacker objective: The attacker benefits from weaknesses already embedded in the software supply chain, gaining a wider exploitation window before the vulnerable workload is remediated.
- Entry occurs when a container build inherits vulnerable packages, libraries, or base-image components before the workload is deployed.
- Credential or trust abuse follows when teams assume the image is safe because it has few visible CVEs, even though the scanner may not fully recognise the distribution or its contents.
- Impact is delayed detection and avoidable exposure in CI/CD and runtime environments, where inherited flaws persist until the image is rebuilt or replaced.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Near-zero CVE is really a provenance problem: the decisive issue is whether teams can prove what is inside the image, where it came from, and how reliably it is scanned. A low vulnerability count is only meaningful when identification is accurate and the base image is governed as a lifecycle asset. For practitioners, that means treating image provenance and scanner visibility as first-class supply chain controls.
Container supply chain risk is increasingly inherited, not authored: the article correctly shifts attention away from application code alone and toward the operating system and third-party layers that most teams do not write themselves. That aligns with the reality of modern DevSecOps, where much of the exposure profile is established before the first commit reaches production. The practical lesson is to reduce inherited exposure at the image layer, not to chase it solely at runtime.
Scanner blindness creates governance debt: if the security stack cannot consistently recognise an image family, the organisation cannot reliably compare exposure, enforce exceptions, or produce audit evidence. This is a governance failure as much as a tooling failure, because assurance depends on visibility before remediation begins. Teams should treat unsupported or obscure distributions as a control gap, not a discount opportunity.
Curated images shift security left only when teams preserve flexibility: the value of a hardened base image disappears if application owners cannot update it without breaking workloads. The article’s strongest point is that security and operability have to be designed together, especially in brownfield environments with fragile dependency chains. Practitioners should optimise for maintainable exposure reduction, not just the smallest possible image.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Near-zero CVE images do not remove supply chain risk, they compress it into earlier control points. The programme question is whether your build system can prove image origin, dependency content, and patch state before the workload ships. That is where container governance becomes identity-adjacent: the CI/CD runner and build path become part of the trust boundary, not just the deployment target.
Image provenance will matter more than raw vulnerability counts. If 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, the lesson is clear: attackers are targeting the build path because it shapes what reaches production, according to the State of Secrets Sprawl 2026. Teams should respond by hardening the image intake process, not just the final artefact.
Near-zero CVE images are only useful when scanner visibility is dependable. If a distribution is not recognised, the assurance model fails even when the image appears clean, so security teams need repeatable evidence, not vendor claims, before they treat a base image as trustworthy.
For practitioners
- Validate distribution recognisability before adoption Confirm that your chosen base image family is detected and classified correctly by the scanners, SBOM tools, and vulnerability databases already in use.
- Govern base images as lifecycle assets Track who owns each image, when it was last patched, what changed in the dependency tree, and when the next rebuild is due.
- Prefer curated images for brownfield workloads Use maintained base images where legacy dependencies, missing package clarity, or fragile builds make scratch images too risky to sustain.
- Separate low-CVE from low-risk Require evidence that the image is both well maintained and fully visible to your tooling before you treat a near-zero CVE claim as meaningful.
Key takeaways
- Near-zero CVE container images can lower inherited exposure, but only when the base distribution is mature, visible to scanners, and continuously maintained.
- This is a supply chain governance problem as much as a vulnerability problem, because image provenance and dependency drift determine how much risk reaches production.
- Practitioners should treat base images as lifecycle assets and verify that scanner recognition, patch cadence, and rebuild discipline all hold up in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, SLSA and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Container image selection and hardening are application supply chain controls. |
| Recommendation — Apply CIS-16 to govern image provenance, hardening, and update cadence before workloads ship. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Is Protected | The post emphasises protecting software assets and inherited components before deployment. |
| Recommendation — Use PR.DS-01 to treat base images and packaged dependencies as protected assets in the build pipeline. | ||
| SLSA | L3 — Build services securely | The article is about trust in the build and image supply chain, not just runtime scanning. |
| Recommendation — Adopt SLSA-aligned build integrity checks so image provenance can be verified before release. | ||
| MITRE ATT&CK | TA0003;TA0006 — Persistence; Credential Access | Supply chain compromise often persists through build artefacts and exposed pipeline trust. |
| Recommendation — Map build-path compromise to persistence and credential access tactics so detection focuses on CI/CD infrastructure. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Container pipelines depend on controlled identities for build, scan, and release actions. |
| Recommendation — Use IAM controls to restrict who and what can publish or modify trusted base images. | ||
Key terms
- Near-Zero CVE Image: A container image curated to minimise known vulnerabilities through continuous patching, package reduction, and controlled maintenance. The term does not mean vulnerability-free. It describes an image strategy that aims to reduce inherited exposure enough that remaining risk can be validated and governed more effectively.
- Curated Base Image: A prebuilt container foundation that includes only the packages an application is expected to need, maintained by a vendor or trusted distributor. It reduces dependency uncertainty in brownfield systems and gives teams a more stable baseline than rebuilding every layer from scratch.
- Scanner Visibility: The degree to which security tools can recognise, classify, and assess a container image and its component packages. Good visibility is essential for trustworthy vulnerability reporting, because an unrecognised distribution or opaque package set can hide exposure rather than eliminate it.
- Supply Chain Risk: Supply chain risk is the chance that a weakness, failure, or compromise in an external supplier, partner, or upstream dependency will affect your organization. It includes software, hardware, cloud, data, and service dependencies, where trust, integrity, availability, or confidentiality can be disrupted through third-party access, updates, or operational failure.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect build-time controls to identity risk. It helps security and platform teams align identity governance with the controls that protect modern software supply chains.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org