Many people confuse VEXes with vulnerability notifications and wonder why there needs to be a VEX format at all. After all, software suppliers have been providing notifications of new vulnerabilities to their users for years. These notifications have been provided in many human-readable forms, including email text, PDF attachments, web pages, etc. They have also been provided in machine-readable forms, including the CVRF format[i] and its successor, CSAF[ii] (the general vulnerability reporting format on which one of the two VEX formats is based).
The VEX concept arose because of the need to provide negative vulnerability notifications: Instead of stating that a particular product and version(s) are affected by a particular vulnerability (CVE), a VEX indicates that the product and version(s) are not affected by the vulnerability. Is this the difference between a VEX and a “traditional” vulnerability notification?
The answer is no, for two reasons: First, A VEX document can provide a positive vulnerability notification, simply by changing the status designation in a negative statement like “Product X version Y is not_affected by CVE-2022-12345” to “Product X version Y is affected by CVE-2022-12345”.
Second, a negative notification can be provided in the same way as any positive notification is now delivered; a VEX isn’t required for this. For example, instead of issuing an email stating that a particular vulnerability is exploitable in their product (and therefore customers need to apply a patch or upgrade), a supplier can send an email stating, “None of our products is subject to the Ripple 20 vulnerabilities.” In fact, it is safe to say there is nothing that a VEX document can do that a “traditional” vulnerability notification cannot do; why are they both needed?
The difference between a VEX and a traditional vulnerability notification has nothing to do with their respective formats. Rather, the difference between the two is due to the fact that a VEX is designed to address a particular use case: the case in which a software user has utilized the list of components from an SBOM to find vulnerabilities that might be exploitable in a software product (or intelligent device) operated by their organization.
The VEX identifies vulnerabilities that are a) listed in a vulnerability database as applicable to a component of the product, yet b) are not exploitable in the product, taken as a whole. A software tool that ingests SBOMs and VEX documents would utilize the VEX documents to “trim down” the list of vulnerabilities identified for components found in the SBOM, so that the only vulnerabilities remaining on the list are exploitable ones[iii].
Another way that VEX documents differ from traditional vulnerability notifications is that a VEX only makes sense if it is “read” by a software tool. This is because, if a software product just contains a small number of components and the supplier only needs to notify their users that a few vulnerabilities are not exploitable in the product, it would be much easier for the supplier to do this in an email.
Under these assumptions, users could simply maintain a spreadsheet listing all the vulnerabilities identified (in the NVD or another vulnerability database) for components of the product. When they receive an email saying a vulnerability isn’t exploitable in the product, they would simply delete the line in the spreadsheet where that vulnerability is listed. Therefore, at any point in time, the spreadsheet would list all the component vulnerabilities currently deemed exploitable.
However, the average software product contains around 150 components and many products – including some commonly-used ones – contain thousands of components. Clearly, trying to manage exploitable component vulnerabilities using emails and spreadsheets will be impossible when products like these are encountered.
Of course, VEX documents can be used for other purposes than negative notifications (like the one just described). For example, a VEX document can be used to notify customers that one or more versions of a product are vulnerable to a serious vulnerability, as well as provide a notice of a patch and/or upgrade path to mitigate the vulnerability. However, given that almost every software supplier already has some means to notify its customers that a serious vulnerability is exploitable and a patch is available for it, why would a supplier want to use a VEX to convey this notification?
While this is speculation, it is possible that some suppliers will use VEXes for patch notifications like the above (as well as other positive vulnerability notifications), because they a) want to provide a machine-readable notification to their users and b) they are already providing VEXes for “negative vulnerability notification” purposes – meaning they have some experience with the format. Therefore, they might be more inclined to experiment with a new use case for a format (VEX) they already understand, rather than experiment with both a new use case and a new format.
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at email@example.com.
[iii] Of course, this is an aspirational goal. It will require any supplier that provides SBOMs to their customers also to publish a VEX as soon as they discover that a vulnerability listed in the NVD for a component isn’t exploitable in the product. This will place a burden on suppliers and may dissuade some suppliers from producing SBOMs at all, at least in the near term. This is why I have proposed “real-time VEX”, as a way to greatly lessen the burden on suppliers of providing negative vulnerability notifications to their customers. See this post: https://tomalrichblog.blogspot.com/2022/08/whats-best-sbom-no-sbom-whats-best-vex.html