2026 teams can pair CycloneDX 1.7 SBOMs with OpenVEX and Trivy to cut scanner noise in CI/CD while keeping trails and exploitability context. Read now.
Why scanner noise became the real bottleneck
Most CI pipelines that run a vulnerability scanner produce more findings than any team can triage. A single container image can surface hundreds of CVEs, and the majority point at packages that ship in the image but are never reached at runtime, or that the vulnerable function is never called. When every build fails on a red wall of findings, engineers start ignoring the scanner entirely, which defeats the point of running it.
The fix is not a quieter scanner. It is attaching machine-readable context that says whether a given vulnerability actually affects your software. That context is what a VEX (Vulnerability Exploitability eXchange) document carries, and pairing it with a Software Bill of Materials lets the pipeline separate "present in the dependency tree" from "genuinely exploitable here."
How CycloneDX, OpenVEX, and Trivy fit together
The three pieces play distinct roles. A CycloneDX 1.7 SBOM is the inventory: it enumerates every component, its version, and its relationships. An OpenVEX document is the assertion layer: for each vulnerability it records a status such as affected, not affected, fixed, or under investigation, along with a justification when you claim it does not apply. Trivy is the consumer that generates the SBOM, scans against it, and then applies the VEX statements to filter results before the pipeline decides pass or fail.
Keeping these as separate artifacts matters. The SBOM changes when dependencies change; the VEX statements change when your triage decisions change. Because both are portable formats rather than scanner-specific config, the same documents can travel with the artifact to downstream consumers, auditors, or a different scanner.
Wiring it into a CI workflow
The goal is a deterministic sequence that runs on every build and leaves a trail. A practical shape looks like this:
- Generate a CycloneDX 1.7 SBOM from the built artifact as a versioned step, so the inventory reflects exactly what shipped.
- Store OpenVEX statements in the repository alongside the code, reviewed through pull requests like any other change.
- Run Trivy against the SBOM with the VEX documents supplied, so suppressed findings are filtered by explicit assertion rather than by an ignore list.
- Fail the build only on findings that remain after VEX filtering, and publish the SBOM, the VEX file, and the scan report as build artifacts.
Because the suppression lives in a reviewed VEX document with a justification, a muted finding is auditable: anyone can see who marked a CVE not-affected and why. That is the difference between disciplined noise reduction and a growing pile of undocumented exceptions.
Keeping the trail honest over time
A VEX statement is a claim about a moment. When you upgrade a dependency, a "not affected" justification tied to an old version may no longer hold, so regenerate the SBOM on every build and treat stale VEX entries as something to revisit rather than trust indefinitely. Tie each statement to specific component versions so it stops applying automatically once the underlying package moves.
Done this way, the pipeline stays green for the right reasons. Engineers see a short, honest list of exploitable issues, security reviewers get a documented record of every suppression decision, and the exploitability context that justified each call travels with the artifact instead of living in someone's memory.