Topic starter
18/08/2026 2:54 pm
TL;DR: Context-aware analysis can reduce a flood of 1,200 critical CVEs to about five reachable issues by pairing signed SBOMs, VEX reporting, and provenance evidence in the build pipeline, according to Kusari. The governance shift matters because security teams need prioritised, auditable risk signals, not broader alert volumes, to support fast release decisions.
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: What should teams do when CI scanners produce thousands of critical CVEs?
A: Treat the output as a prioritisation problem, not a blocking queue.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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