VEX: Standardization for a Vulnerability Exploit Data Exchange Format
In late January, the VEX working group hosted by CISA (Cybersecurity and Infrastructure Security Agency) voted to publish the “Minimum Elements for VEX” document. The document defines the fields, flags and structure necessary to express valid VEX (Vulnerability Exploitability eXchange) statements. This document was derived from community input, design prototypes, and known use cases and experience — all while trying to keep VEX as compatible as possible with CSAF (Common Security Advisory Framework) and CycloneDX, the two existing implementations.
The “Minimum Elements” document, which is due to be officially published soon, signals the maturity of an idea under discussion and development for years. It also guarantees the necessary stability to enable VEX issuers and consumers to start building VEX features into their systems.
Some Background
As far back as 2019, participants in software bill of materials (SBOM) forums and working groups originally organized by NTIA (National Telecommunications and Information Administration) started to recognize that the new visibility into how software is composed and enabled by SBOMs would bring new challenges. One of those problems is the exponential growth of false-positive alerts — noise from security scanners derived from the increased number of packages under inspection.
Not all vulnerabilities affect all software. Scanners can’t easily capture this reality and this is the primary motivation behind projects like the CISA Known Exploited Vulnerabilities Catalog, which records vulnerabilities being actively exploited. However, projects like this have a reactive nature, and once exploits are in the wild, it may be too late to act.
A better approach is to proactively go to the source when a CVE hits to get insights from the supplier of the software about any possible impact. This is where VEX enters the field.
With VEX, suppliers or other third parties can relay data describing how and whether a piece of software is affected by a certain CVE. Once published, all stakeholders of the CVE can consume the document — developers, InfoSec teams, consumers, customers and suppliers, etc.
VEX documents contain machine-readable statements about a vulnerability’s known impact on a piece of software, answering questions like these: Is this product affected? No? Why not? Since when? In general, it is considered a companion document to SBOM, meant to move faster, relaying impact data as it changes through time.
How VEX Became VEX
VEX started to take shape in 2020, and before the year was out, there was a working group trying to determine what VEX could look like. The future features and requirements of the format were shaped on these community calls, capturing the views and needs of a diverse group. Based on this work, document formats started to write their implementation.
By the time 2021 rolled in, CycloneDX had presented its vulnerability extension to the VEX subgroup, which tangentially touched some areas of what VEX does. The collaboration between OASIS and NTIA was already underway to bake VEX into what would become a CSAF 2.0 profile a few months later.
The work and discussions continued, and 2022 was a big year for VEX. On Jan. 12, CycloneDX 1.4 was released and, to quote a member of the subgroup, CDX “surprised the working group” by rolling out its own version of VEX, which introduced a set of justification flags incompatible with those that had been under discussion by the VEX working group for months.
In April 2022, the VEX subgroup published a document with VEX use cases, followed by the June formalization of the status justification labels. The subgroup also published a one-page document, with a concrete overview of VEX, which was released in September. CSAF 2.0 was released on Nov. 21, 2022, with VEX included as one of the CSAF profiles.
To align implementations of VEX and avoid further divergence, the workgroup started to define a data model document to ensure the same data bits were present in all formats to ensure VEX statements can be formed from the information in them. This “spec of specs” became the “Minimum Requirements for VEX” document, which was finally approved after resolving all details over the Christmas break. It is now the basis for the compatibility of all VEX implementations.
Benefits of a Unified Minimum Elements Definition
Now that the minimum requirements to express VEX are frozen in a document, current and future implementations can check if the way they communicate exploitability information can be expressed in VEX. This ensures the whole history of exploitability knowledge and remediation of a software product can be pieced together regardless of which format each chapter is written in.
As an example, when a new CVE hits, a software publisher may issue a VEX document stating the vulnerability impact is under_investigation. A security researcher may add a new VEX document, possibly in a different format, asserting the product is affected. Finally, the publisher may issue a final one letting users know it has been fixed. Each of these steps can be expressed in any format complying with the Minimum Elements for VEX, and tools can piece together the whole history, informing users, dashboards and other tools as time passes.
The “Minimum Elements for VEX” document also provides individual implementations with a roadmap to improve their specs. At the time of approval, both existing VEX implementations guaranteed compatible data flows from each format to an abstract minimum elements-compliant pseudocode, but the other way around might not necessarily be true in all cases. Luckily, implementations are on board with the subgroup, and there is work already going on to bridge the new compatibility gaps created after the document was finalized.
The future to make SBOM more useful is now brighter as VEX, its ideal companion, became better defined. It is now up to the software publishers and tool makers to start the flow of exploitability data. Let’s silence those false positives once and for all.
