Topic starter
21/08/2026 4:46 pm
TL;DR: Curated container images and runtime profiling change exposure before deployment, according to Rapidsort. Appsec teams still need provenance, scanner support, and runtime evidence to decide whether lower CVE counts are trustworthy.
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: 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.
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.
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.
Glossary terms: Curated Container Image, Pipeline Bill Of Materials, Software Bill of Materials, Runtime Truth Gap
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
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