A number of people have claimed that I'm anti-VEX. That is simply not true.
VEX is good for its designed purpose; to inform parties when a software product is NOT affected by a vulnerability. VEX is the ideal choice when a software producer wants to inform its customers that their product is NOT affected by a vulnerability. Just like a "CSAF Security Advisory" is good at informing customers when their software product IS affected by a vulnerability. CISA VEX and CSAF Security Advisories are two sides of the same coin; heads you ARE affected, tails you are NOT affected by a vulnerability, according to this YouTube presentation. In this video Thomas refers to VEX as an anti-Security Advisory; I concur Thomas. The recent OpenSSF article on OpenVEX makes this point very clear.
A CSAF Security Advisory is like receiving a "weather radio alert WHEN THERE ARE tornados in the area." A CSAF VEX document is like receiving a "weather radio alert WHEN THERE ARE NO tornados in the area" - informing you that a software product is not affected by a new vulnerability. As I stated previously, VEX is good for its designed purpose.
But VEX is also impractical to implement in many situations as this message from Cassie Crossley confirms: https://youtu.be/j9MB7oaq8aI?t=3634Â Â Â 226,000 records to represent VEX for Log4J. Should all 226,000 VEX records be sent to every customer?
The claims by some that VEX will answer the question "Is my software product affected as of right now" - is simply false, and deceptive. VEX cannot answer this question. A NISTÂ SBOM Vulnerability Disclosure Report (VDR) is the only method that answers the consumer question "Is my software product affected as of right now" by linking an online, living VDR to an SBOM, as shown in the SPDXÂ SBOM example linked.
According to the CISA published VEX specification a VEX MUST identify a vulnerability (ref page 13 section 3.1.2 "A VEX statement MUST identify at least one product (or component) and exactly one vulnerability." and list products that are NOT affected and provide justification. The format of a VEX statement is shown on page 6 under section 2.3 in the VEX specification. A VEX MUST include an [impact statement] if no [justification] has been provided; see section 2.7.1.1.1 of the CISA published VEX specification, linked above.
There are plenty of software products that have no reported vulnerabilities, which makes it impossible to use VEX to communicate a software product's vulnerability status, when there are no vulnerabilities to report. A software producer that wanted to use VEX to answer the question "Is my software product affected as of right now" would have to list every vulnerability that has ever been reported and identify every product that is not affected by each vulnerability; AND they would have to reissue such a VEX whenever a new vulnerability is reported. One, very important aspect of vulnerability reporting is the ability to uniquely identify a software product. The VEX spec itself provides an answer to unique product identification (see page 8 of VEX spec: "[product_id] and [subcomponent_id] SHOULD conform to reasonable and current conventions, for example, follow a “supplier/product/version” construct") by specifying use of three SBOM data elements to uniquely identify a software product; Supplier Name + Product Name + Product version = a unique product name, when the supplier name is specified using DNS, for example dns:microsoft.com/Windows 10/1861
A NIST SBOM VDR is different; it does not require the listing of a vulnerability, because it only reports vulnerabilities that are reported for each component listed within an SBOM for a single software product and version, associated with an SBOM. A NIST SBOM VDR is akin to a CARFAX report, always showing the current status of a software product. A VEX is more like a police report reporting a car accident in which nobody got hurt (not affected vulnerability result). A Security Advisory is the opposite of a VEX, reporting an injury with a car accident, indicating an "affected status".
To summarize, I am not anti-VEX, but I am for telling the truth about what VEX can and cannot do. Any attempt to claim that a VEX answers the question that consumers are asking "Is my software product affected as of right now", is deliberately pushing disinformation. A VEX report identifies known vulnerabilities (CVE_ID) and indicates which software products are NOT affected by the CVE_ID.
An honest, and objective analysis of VEX and VDR is available from OWASP, thanks to Steve Springett.