TL;DR: RapidFort’s white paper argues that CI/CD security gaps persist because fast-moving build pipelines hide vulnerable code, unchecked dependencies, and limited runtime visibility, while its platform claims up to 99.9% vulnerability reduction and 90% attack-surface reduction within hours, according to Rapidsort. The governance issue is not just scanning faster, but deciding how much trust to place in curated images, profiling, and SBOM evidence across build and runtime.
At a glance
What this is: This white paper argues that CI/CD security problems are often created by pipeline speed, tool sprawl, and limited runtime visibility, and that near-zero CVE images aim to reduce those gaps by hardening containers without code changes.
Why it matters: It matters because appsec, cloud, and platform teams need to decide whether to treat curated images and runtime profiling as operational controls, not just build optimisations, especially where identity-bound pipelines and deployment trust are involved.
By the numbers:
- RapidFort says its approach can eliminate up to 99.9% of software vulnerabilities within hours.
- The platform claims up to 90% reduction in software attack surface.
Context
CI/CD security is a governance problem as much as a tooling problem. When release pipelines move quickly, teams can ship workloads whose dependency base, runtime footprint, and audit evidence no longer line up cleanly with what was built and approved.
That gap matters for identity and access as well as application security because build systems, container registries, and deployment pipelines depend on tightly controlled credentials, approvals, and provenance. If the pipeline cannot show what actually runs, it becomes harder to govern trust in the software supply chain.
The article's core premise is typical of modern platform security: the weakest point is often not the application code itself, but the speed and opacity of the delivery path.
Key questions
Q: What breaks when container security tools only scan at build time?
A: Build-time scanning catches known issues in images, but it misses what changes after deployment. Runtime drift, active exploitation, exposed secrets, and newly disclosed CVEs can all emerge later. If teams rely only on build-time checks, they may assume production is safer than it really is.
Q: Why do near-zero CVE images create a trust question for appsec teams?
A: Because lower vulnerability counts do not automatically mean higher assurance. Teams still need to verify provenance, scanner compatibility, and runtime behaviour so the hardened image can be validated independently rather than accepted on claim alone.
Q: How should security teams use SBOMs and runtime profiles together?
A: Use SBOMs to understand what was included in the image, then use runtime profiles to see what actually executes. Together they support better remediation, exception handling, and compliance reporting than either evidence source can provide on its own.
Q: What should teams do before adopting curated container images broadly?
A: Check whether the curated baseline is recognised by existing scanners, whether it fits application requirements, and whether governance can track image lineage through the full pipeline. If those controls are missing, the image may reduce vulnerabilities while increasing blind spots.
Technical breakdown
Why CI/CD pipelines hide security debt
CI/CD pipelines compress testing, packaging, and deployment into a narrow window, so unexamined dependencies and unused code often move forward with the release. That creates security debt because the system optimises for velocity before it has enough evidence to separate active runtime code from dormant or bundled material. In practice, this is where scanning-only programmes struggle: they can identify known vulnerabilities, but they do not always tell teams which components will actually execute in production.
Practical implication: move from build-time inspection alone to controls that distinguish shipped artefacts from executed runtime paths.
How curated container images change the control point
Curated container images shift security left by starting from a hardened baseline rather than a generic upstream image. The hardening logic is to strip unused packages, reduce attack surface, and standardise the image so downstream pipelines inherit a smaller exposure set. That can help, but it also changes the governance burden: teams must be able to validate the image lineage, understand what was removed, and confirm that the curated baseline is still compatible with application behaviour and compliance requirements.
Practical implication: treat image curation as a controlled supply-chain decision with approval, traceability, and compatibility checks.
Why SBOM and runtime evidence are not the same
A software bill of materials lists the components included in an application, while runtime evidence shows what code actually executes under real conditions. Those are related but not interchangeable. An SBOM can support transparency and vulnerability management, but it may still overstate risk if large portions of the image never run. A runtime bill of materials narrows that gap by showing operational reality, which is why it is more useful for prioritisation and audit evidence than a static component inventory alone.
Practical implication: pair SBOM review with runtime profiling before making remediation, risk acceptance, or compliance claims.
NHI Mgmt Group analysis
Near-zero CVE container images are really a provenance and trust problem, not just a vulnerability-reduction tactic. The article's central promise is about reducing the number of exploitable components, but the harder question is whether teams can verify what was removed, what remains, and whether the resulting image is still recognisable to mainstream security tooling. For practitioners, the issue is governance over the image lifecycle, not a single hardening action.
Runtime evidence changes the security conversation from potential exposure to executed exposure. SBOMs are useful, but they are still inventory. When a platform can show that only a subset of code actually runs, teams get a better basis for prioritising remediation, exception handling, and compliance reporting. That is especially important in CI/CD environments where build artefacts often contain far more than the application truly uses.
CI/CD control maturity now depends on whether security evidence is machine-readable across the build and runtime chain. Curated images, profiling, and compliance artefacts only help if they can be validated by the rest of the estate, including scanners, auditors, and pipeline gatekeepers. The named concept here is runtime truth gap: the distance between what a build contains and what a workload actually executes. Practitioners should close that gap before they rely on hardening claims in policy or audit processes.
This pattern strengthens the case for supply-chain controls that are verifiable by third-party tooling. If a hardened image cannot be reconciled by common scanners, teams inherit a new trust problem even when the vulnerability count drops. For identity and platform teams alike, the practical conclusion is that trust must be anchored in evidence that other controls can consume, not in a vendor assertion alone.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 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: Guide to the Secret Sprawl Challenge
What this signals
Runtime truth gap: security programmes should treat the difference between shipped artefacts and executed code as a distinct governance issue, because build-time inventories can look complete while runtime exposure remains unknown. That makes runtime profiling a control input, not just a reporting artefact.
Where CI/CD is already tightly coupled to identity, the next maturity step is to govern the trust chain end to end, from image provenance to deployment permissions and audit evidence. Teams that cannot reconcile those signals will struggle to defend hardening claims under scrutiny.
For practitioners
- Validate curated image provenance Confirm that hardened images are identifiable by your standard scanners, registries, and governance workflows before treating them as trusted baselines.
- Pair SBOMs with runtime profiling Require both component inventory and runtime execution evidence so remediation priorities reflect what actually runs, not only what was shipped.
- Gate CI/CD releases on image lineage Add approval and traceability checks for curated base images, especially where container builds depend on shared registries and automated promotion.
- Align compliance evidence to executed code Use runtime bills of materials and benchmark output to support audit packages, rather than relying on build-time artefacts alone.
Key takeaways
- CI/CD hardening is no longer just about scanning faster, because curated images and runtime profiling change what counts as exposure in the first place.
- The article's main control tension is between lower vulnerability counts and the need for independently verifiable provenance, scanner support, and runtime evidence.
- Practitioners should align build, runtime, and compliance evidence before trusting near-zero CVE claims in production pipelines.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | CI/CD toolchains and container build paths are common routes for attacker credential abuse and downstream impact. |
| Recommendation — Map pipeline hardening gaps to TA0006 and TA0010, then prioritise controls that reduce build-path exposure and runtime abuse. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest is Protected | The article centres on protecting software artefacts, build inputs, and compliance evidence across the delivery chain. |
| Recommendation — Protect build artefacts and image inventories as governed security data under PR.DS-01. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | CI/CD hardening depends on controlling build inputs, dependencies, and approved baselines. |
| Recommendation — Apply SA-10 to govern approved container baselines and enforce traceable build inputs. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about hardening application delivery and reducing exploitable software content. |
| Recommendation — Use CIS-16 to embed secure build and release controls into the software delivery lifecycle. | ||
| SLSA | L2 — Build integrity | Curated images and pipeline trust both depend on software supply chain provenance and build integrity. |
| Recommendation — Adopt SLSA build-integrity checks before promoting hardened images into production. | ||
Key terms
- Curated Container Image: A curated container image is a pre-built image based on approved components and reduced software content. It is designed to lower exposure by removing unnecessary packages and limiting the code that ships into production, while preserving the application’s required function.
- Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Runtime Truth Gap: The runtime truth gap is the distance between what teams believe an API does and how it actually behaves in production. It emerges when documentation, ownership, and policy do not stay aligned with live traffic, creating both security blind spots and reliability failures.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is the industry's only accredited NHI security programme for practitioners who need to connect identity controls to wider security operations.
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