VEX! or... How to Reduce CVE Noise With One Simple Trick!
summary
VEX provides a machine-readable statement that links CVEs to software components and says whether a product is actually known affected, known not affected, or under investigation, using the SBOM identifier as the lookup key and including remediation steps or version fixes. It reduces scanner noise by letting dashboards suppress non-actionable findings and focus real risk, but requires trust in vendors, consistent product/version normalization, and wider tooling and repository adoption to be practical at scale.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:57Risk
- 2:36Value
- 3:58Cost
- 6:10Log for Shell
- 7:53Main Message
- 8:12Software Build Materials
- 9:32Modeling Gap
- 10:17Mapping
- 10:49Not everything is affected
- 13:36Policies
- 16:04VEX
- 17:56Workflow
- 19:53Gaps
- 21:38Questions
- 21:53Sbomb
- 22:32Sbomb Problems
- 23:30Open Source
- 25:13VEX Documents
- 25:32Is there a repository
- 26:17CycloneDX
- 28:10What VEX is trying to do
- 30:06Duplicate CVs
- 30:19Conclusion
related talks
45mVEXing Open Source Security: Vulnerability Data for Everything
30mTaming the Scanner Storm: How VEX Brings Context to Vulnerability Data
50mBOF - Discussion Regarding False Positive Results from Vulnerability Scanners and the Use of VEX
37mVEXed by Vulnerabilities That Don't Affect Your Product? Try This!
47mVEX Overview
45mCSAF/VEX: Improved Security Data
48m5 Steps to VEX Success: Managing the End-to-End Workflow
32mUnderstanding Exploitability with VEX, EPSS, and Other Standard Frameworks