VEXed by Vulnerabilities That Don't Affect Your Product? Try This!
summary
A machine-readable way to state that a vulnerability does not affect a product is now defined as a VEX profile of the OASIS CSAF format. It links product identifiers (CycloneDX or SPDX SBOMs), a CVE, and a status with an action or impact statement, and offers five machine-readable justification categories (e.g., component absent, code not in execution path). Implementations exist in medical device and ICS sectors and paying customers use it today.
AI-written summary · about
chapters (12)
- 0:00Introduction to VEX
- 1:50The challenge of vulnerabilities
- 5:54Defining VEX and its purpose
- 8:36Use cases and benefits
- 12:27CSAF framework implementation
- 14:19Structure of a VEX document
- 17:06Status and justification fields
- 20:07Machine-readable justifications
- 23:20Implementation and ecosystem
- 27:44Cultural and technical hurdles
- 29:20Call to action and next steps
- 32:11Q&A session
related talks
47mVEX Overview
31mVEX! or... How to Reduce CVE Noise With One Simple Trick!
45mVEXing Open Source Security: Vulnerability Data for Everything
45mCSAF/VEX: Improved Security Data
50mBOF - Discussion Regarding False Positive Results from Vulnerability Scanners and the Use of VEX
47mI Can’t Cope! How OWASP Is Helping To Manage Vulnerability Overload
48m5 Steps to VEX Success: Managing the End-to-End Workflow
46mThree Musketeers: CVE, CSAF, and VEX