Topic starter
18/08/2026 2:54 pm
TL;DR: 1,200 critical CVEs can collapse to about five reachable issues when pipeline evidence adds context, Kusari case work shows. Build gating then depends on reachability and provenance, not raw scan volume.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Breaking the "Department of No" - Ship Fast, but also Secure”.
Key questions
Q: Why do raw CVE counts create bad release decisions in build pipelines?
A: Raw counts collapse very different risk conditions into one number.
Q: Where does vulnerability management fail in CI/CD environments?
A: It fails when scanners report presence but not context.
Q: What should teams do when CI scanners produce thousands of critical CVEs?
A: Treat the output as a prioritisation problem, not a blocking queue.
Practitioner guidance
- Define build admission rules around reachability, not raw CVE counts Block releases only when a vulnerability is reachable in the shipped call path or when trust evidence is missing, rather than using severity alone.
- Require signed SBOMs and provenance attestation for every build Attach verifiable evidence to each artefact so downstream policy can decide whether the package came from a trusted, traceable pipeline.
- Use VEX to suppress non-actionable findings Route scanner output through exploitability context so security teams review the small subset of issues that can actually affect production.
Bottom line: CI pipeline vulnerability management breaks down when scanners produce large volumes of findings without enough context to separate reachable exposure from inventory noise.
Glossary terms: Software Bill of Materials, Vulnerability Exploitability Echange, Provenance Attestation, Context-Aware Detection
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
18/08/2026 3:37 pm
Context-aware pipeline security is fundamentally a governance correction, not a scan optimisation. The problem is not that teams can see too much, but that they cannot tell which findings change release risk. When security tooling treats every CVE as equally blocking, it creates a control that is precise in volume but weak in judgement. Practitioners should treat context as part of the control plane, not a reporting enhancement.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should organisations govern software artefact trust before deployment?
A: They should require signed provenance, policy-controlled admission, and evidence that a build was assembled from known inputs. That makes trust a gate condition rather than an assumption, and it gives security teams a durable audit trail from source to deployment.
👉 Read our full editorial: Context-aware pipeline security changes how teams handle CVE noise