The Software Bill of Materials (SBOM) gets stymied by SBOM quality and vulnerability-specific noises. CISA has recommended creating VEX information with Minimum Requirements for Vulnerability Exploitability eXchange to tackle the latter.
The VEX Minimum Requirements document recommends including fields in the VEX embedded in an SBOM or as a stand-alone document.
In an earlier post, we focused on detailing where CycloneDX VEX, OpenVEX, and CSAF stand in relation to the vulnerability disclosure.
In this post, we breakdown the field mappings of Minimum Requirements to CycloneDX VEX and OpenVEX.
VEX, an acronym for Vulnerability Exploitability eXchange, is a structured data format that facilitates the exchange of vulnerability information between software vendors, security analysts, and consumers. It aims to address the challenges associated with legacy vulnerability advisories, which often lack machine-readability and fail to convey whether a vulnerability is truly exploitable in a given product or environment.
CISA’s Minimum Requirements for VEX document defines the minimum elements independent of VEX format or specification with a focus on machine-readability.
It describes a VEX document divided into VEX document metadata and at least one VEX statement, which in turn consists of Statement metadata, Status, Vulnerability Details, and Product Details.
Document metadata
VEX statement metadata
VEX statement Product
VEX statement Vulnerability
VEX statement Status
CycloneDX included vulnerabilities and their analysis as fields with version 1.4 and expanded them with version 1.5. Therefore, CycloneDX is a natural specification for embedding VEX information with the SBOM.
However, some field mappings might not be obvious at first glance.
Interlynk recommends implementing Minimum Requirements for VEX with CycloneDX as following:
Document metadata
VEX statement metadata
VEX statement Product
VEX statement Vulnerability
VEX statement Status [Required]
VEX statement Justification [Conditionally Required]
VEX statement Impact Statement
VEX statement Action Statement
OpenVEX specification was updated alongside the CISA working group writing the Minimum Requirements document, and therefore OpenVEX provides the most direct mapping to the referenced fields.
Document metadata
VEX statement metadata
VEX statement Product
VEX statement Vulnerability
VEX statement Status [Required]
VEX statement Justification [Conditionally Required]
VEX statement Impact Statement
VEX statement Action Statement
Better utilization of SBOM towards vulnerability management and risk assessment does require baseline machine readability of the VEX document. Therefore, we recommend creating VEX within CycloneDX or OpenVEX using a common agreed-upon convention.
Interlynk is trying to make security disclosure easy, obvious, and automated. We are happy to answer any questions you might have. Feel free to reach out to us at hello@interlynk.io or via interlynk.io.