The VEX Concept is Burdensome on Software Vendors and Unnecessary for Software Consumers

[UPDATE 2/20/2023 "VEX is such a poorly understood concept – mainly because there’s so little documentation of VEX, and what little there is contradicts itself. For example, the recently approved, but not yet published, VEX “Minimum Requirements” document directly contradicts the previous CISA Use Cases document on several key points, without even mentioning that fact. The user is left to discover this contradiction on their own. ]

In 2020 the U.S. National Telecommunications and Information Administration NTIA initiated a work stream to focus on the development of guidelines to aid software vendors in the development of Vulnerability Exploitability Exchange artifacts, known as VEX. CISA provides the following description of a VEX document in the June 2022 guidelines:

 A Vulnerability Exploitability eXchange (VEX) document must include the product’s status as it relates to a particular vulnerability. Consequently, VEX documents may contain a justification statement of why the VEX document creator chose to assert that the product’s status is NOT AFFECTED. This document provides the recommended NOT AFFECTED status justifications of a VEX document and offers the reader examples of when the different status justifications might be used. This document is part of a series of descriptions and guidance documents for VEX.

The VEX work has transitioned from NTIA to CISA where it is being led by Allan Friedman. An introductory video to VEX is available online.  It's clear from the June 2022 VEX document issued by CISA that VEX artifacts are used to inform consumers that a set of software products are not affected by a vulnerability. It’s important to note that many software vendors are contractually obligated to inform their customers when a software product is vulnerable to a particular vulnerability. The OASIS Open group has developed a CSAF Security Advisory (profile 4) which vendors can use to communicate with consumers when a software product is impacted by a newly reported vulnerability. I’m not aware of any contractual obligations for a software vendor to send security notifications to customers for products which are not vulnerable to a newly reported vulnerability, known as a CVE.  But this is precisely what a VEX is supposed to contain; a listing of software products that are NOT AFFECTED by a newly reported vulnerability (CVE) .

The author of VEX, Thomas Schmidt describes VEX "Vulnerability Exploitability eXchange (VEX) is a profile in CSAF. VEX was developed in the SBOM community as a way for manufacturers to easily convey that a product is not affected by issuing a so-called negative security advisory. VEX is designed to work with SBOMs, although it is not necessary to have an SBOM to use VEX documents." then further in the article, Thomas reiterates the purpose of a VEX "When paired with an SBOM, VEX documents enable administrators to use asset management systems to quickly determine what vulnerabilities are not exploitable, which frees them to focus on any vulnerabilities that could put their businesses at risk."

In my opinion a VEX document is:

• Unnecessary; Consumers can deduce that a software product is not affected by a new vulnerability (CVE) by examining the list of products that are affected, shown in a CSAF Security Advisory document
• Burdensome;  Software vendors are obligated to examine their software products when a new vulnerability (CVE) is reported and provide customers with their analysis, when a software product is impacted and a “security advisory” is issued listing the affected products. With VEX, a software vendor would also be required to issue a “VEX” document listing all of  the software products that are not affected by a newly reported vulnerability (CVE) and provide detailed justification showing why each software product is not affected. The sheer number of software products that may not be affected by a new vulnerability could be enormous. Take for example Microsoft; suppose Microsoft becomes aware of a vulnerability that only affects the Windows 10 operating system. Microsoft would be obligated to publish a “Security Advisory” informing consumers of the vulnerability and provide mitigating measures to prevent the vulnerability from being exploited. With VEX in force, Microsoft would also be required to produce a VEX document listing every other Microsoft Software product in their portfolio of software products that are not affected by this vulnerability, and provide detailed justification as to why each product is not affected. This would result in Microsoft having to produce a VEX with 1000’s of products which are not affected along with justifications why Microsoft is making the assertion of “not affected”, and send the VEX to consumers.
• No Additional Value for Consumers; Consumers need to become aware of risks that may exist in software products installed within their digital ecosystem. Many times, these vulnerability notification requirements are specified in procurement contracts, requiring a vendor to notify a customer within a certain time frame when they have identified a vulnerability in their software products. A VEX is used to inform consumers of software products which are not affected by a particular vulnerability (CVE), essentially creating a ying-yang view of a software vulnerability, a CSAF security Advisory lists the products that are affected and a VEX lists the products which are not affected. Consumers can readily deduce that their software products are not affected IF their product is not listed in the Security Advisory showing affected products.
• Added cost to Consumers; Software Customers should expect to pay significantly more for software products if a software vendor is required to produce both a “Security Advisory”, showing affected products and a VEX document listing products that are not affected by a new vulnerability, along with justification for why they are not affected. A software consumer can easily deduce if their software products are unaffected by a new vulnerability by examining the CSAF Security Advisory of known affected products.
• A NIST Vulnerability Disclosure Report (VDR) is far more useful for software consumers to help identify software risks within software products.

This article describes how a software consumer can proactively monitor for software vulnerabilities using a combination of SBOM and a NIST VDR.

I welcome all comments and insights on this topic.