Topic starter
21/08/2026 4:46 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Rapidsort: “The RapidFort Platform”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:06 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CI/CD hardening and near-zero CVE images reshape appsec control