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.
NHIMG editorial — based on content published by Rapidsort: The RapidFort Platform white paper on CI/CD security and near-zero CVE images
By the numbers:
- Up to 99.9% of software vulnerabilities can be eliminated within hours through continuous scanning and container hardening, according to Rapidsort.
- The platform claims up to 90% reduction in software attack surface through curated images and runtime optimisation, according to Rapidsort.
Questions worth separating out
Q: What breaks when container security relies only on CVE scanning?
A: Teams miss the difference between vulnerable components that are present and components that are actually reachable at runtime.
Q: Why do CI/CD service accounts increase supply chain risk?
A: CI/CD service accounts are dangerous when they can change builds, approvals, or deployments across many systems with one credential.
Q: How do security teams know whether a hardened container image is really safer?
A: They should compare the image’s SBOM, runtime profile, and scanner visibility.
Practitioner guidance
- Establish approved base-image governance Define a short list of approved container base images, require provenance for each one, and block pipeline promotion when an image source cannot be reconciled by standard scanners.
- Pair SBOM with runtime profiling Use SBOM output for build inventory and RBOM or runtime profiling for execution evidence, then route remediation only to packages that are both present and reachable.
- Reduce privileged build identities Review CI/CD service accounts, API tokens, and signing credentials so build systems can publish artefacts without standing privilege that could be abused in a supply chain compromise.
What's in the full article
Rapidsort's full white paper covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of how curated images, profiling, and hardening fit into an existing CI/CD workflow.
- Detailed explanation of the platform's intake, build, and runtime stages for teams designing implementation plans.
- Compliance-oriented evidence generation, including SBOM, RBOM, CIS, and STIG alignment for audit readiness.
- The specific claims behind the near-zero CVE approach and the conditions that affect scanner visibility.
👉 Read Rapidsort's white paper on CI/CD hardening and near-zero CVE images →
Near-zero CVE container images: what they mean for appsec teams?
Explore further
Curated images create a supply chain control point, not just a packaging choice. The article is really about where organisations choose to establish trust in the software lifecycle. Curated images reduce the breadth of what must be scanned and patched, but they also shift governance pressure onto provenance, scanner compatibility, and approval workflows. For appsec teams, the practical conclusion is that image curation only helps if it is governed as a lifecycle control rather than a convenience layer.
A question worth separating out:
Q: Who is accountable when malicious open-source code reaches production pipelines?
A: Accountability usually spans application security, platform engineering, and identity teams because the issue crosses code, pipeline, and credential governance. Frameworks such as NIST CSF and software supply chain controls expect clear ownership for integrity, detection, and response. Organisations need explicit escalation paths for dependency compromise, not informal handoffs.
👉 Read our full editorial: CI/CD hardening and near-zero CVE images reshape appsec control