The joy of VEX, part II

 

When I wrote the first part of this series, I was thinking there would be only two parts. However, I now realize there will definitely be more than that, and they will likely be spread out (since I have severe ADD and can never focus on a single subject in a set of consecutive posts).

I also realized that, in order to have a firm foundation for the posts to follow this one, I need to restate most of what I wrote in the first post and focus on exactly how VEX can greatly expand the possible types of vulnerability notifications – as well as why that is a good thing. 

Vulnerability notifications have almost always been of one type: A notification that a particular vulnerability (usually a CVE) is exploitable in a particular software product (or set of products), and in a particular version (or set of versions). This notification is almost always accompanied by an announcement that a patch is available that will fix the vulnerability, in the version specified in the notification.

In 2020, the Software Component Transparency Initiative of the National Technology and Information Administration, which has been conducting a “multistakeholder process” to establish guidelines for production, distribution and use of software bills of materials (SBOMs), identified the need for a new type of vulnerability notice: a notification that a vulnerability is not exploitable in a particular software product.

At first, it seems strange that one would want to put out an announcement about a vulnerability not being exploitable. After all, previous announcements about a vulnerability being exploitable were always accompanied (sometimes in the same document) by an announcement that a patch is available that will fix the vulnerability. If you know the vulnerability is exploitable, you presumably will have all the motivation you need to apply the patch.

But if a vulnerability isn’t exploitable, then the announcement is essentially saying “Relax, you don’t have to do anything about this.” Do human beings really need motivation to do nothing about a problem? Most of us (maybe some of you are exceptions, but I doubt it) are quite happy to get a pass on action, since there are close to an infinite number of actions that we know we should be taking, but we aren’t – volunteer in a refugee camp in Bangladesh, sell our gas-powered car and take public transportation everywhere, move next door to our parents so they don’t have to fly across the country to see their grandkids, etc. Finally, here’s someone telling us we shouldn’t do anything!

As I’ve explained in various posts (including in part I, but even better in this post), the NTIA initiative (and others) realized that, because a large percentage of vulnerabilities in software components aren’t in fact exploitable in the software product itself, when SBOMs are widely distributed this will lead to two serious problems: 1) suppliers will be overwhelmed with support calls about component vulnerabilities that aren’t exploitable – i.e. they’re false positives – and 2) software users will waste large amounts of time scanning for, and generally worrying about, those same component vulnerabilities.

So the VEX is almost the exact opposite of the “traditional” vulnerability notification described above. Instead of saying “CVE 123 is exploitable in Product A Version X”, the VEX says “CVE 123 is not exploitable in Product A Version X”. In other words, “Don’t worry about CVE 123, at least as far as our product is concerned, even though it does apply to one of the components of our product.”

The message conveyed by a VEX is important, but just as important is the fact that the VEX is machine-readable, like an SBOM is. A single software product has on average 135 components, but can in fact have in the thousands. Since it’s likely the majority of vulnerabilities identified for those components won’t in fact be exploitable in the product itself, there will likely need to be many more VEXes issued than SBOMs.

When an organization receives an SBOM from a software supplier, they will process it through a tool that will look up current vulnerabilities for each of the components (there will also be services available in the near future, that will do this for the user). This will likely produce a big list of vulnerabilities, but before anyone panics after seeing this list, the VEXes will also start coming in and will remove the non-exploitable vulnerabilities from that list. The list will be drastically pared down. So suppliers won’t be overwhelmed with support calls for phantom vulnerabilities in their products, and users won’t lose sleep over those same phantom vulnerabilities.

However, when I wrote this post two months ago, I had begun to realize that the fact that VEXes are machine-readable means there are many more possibilities for messages that can be conveyed. Currently, the only uses that have been discussed for VEX are a) a notice that a vulnerability is exploitable in a particular product and version (i.e. a “traditional” vulnerability notification, although in machine-readable format), and b) a negative notice that a vulnerability isn’t exploitable in a particular product and version. However, there are a number of other notifications that can be sent out using VEXes, which now have to be handled as support calls, or at least by the user going to a website to try to get the answer for themselves.

I illustrated one of these notifications in the first post, although I now realize I could have gone a lot further than I did. Here’s the full scenario:

1.      The “traditional” positive vulnerability notification says for example “CVE 123 is exploitable in product A version 3.2.”

2.      Suppose a user is actually on an earlier version, say 2.8. Normally, they would need to contact the supplier – or at least look at their web site – to answer the set of questions, “What about version 2.8? Is CVE 123 also exploitable in that version? And if it is, have you patched it? Or do I need to upgrade in order to fix the vulnerability?”

3.      Suppose the supplier wants to be proactive in answering these questions, since they can certainly be anticipated. Moreover, they want to answer all of these questions for all of the versions of their product – and they want to do it in a single machine-readable document, not a whole set of documents as well as a bunch of support calls. This way, any user with these questions, who is running any previous version of the product, will simply be able to check in their own configuration or vulnerability management system. They’ll be able to find out immediately whether they need to apply a patch to their version, upgrade the version to fix the vulnerability, or do nothing.

Is it possible to do all of this using a single document?

You may have guessed that the answer is yes. And what’s the name of that document? You guessed right again – it’s the VEX! Here is what the VEX would say, although in more human-readable form:

A.     CVE A is exploitable in versions 2.5, 2.8-3.0, and 3.2 of Product A.

B.     It is not exploitable in versions before 2.5, as well as versions 2.6-2.8 and 3.0.

C.      Patch JKL has been issued for the current version 3.2. Please apply this as soon as possible, if you’re on the current version.

D.     If you’re not sure whether patch JKL has already been applied, check the version you’re running now. If it’s 3.25, the patch has already been applied. If it’s 3.2, you need to apply it.

E.      Patch MNO has been issued for versions 2.9 and 3.0. Please apply this as soon as possible, if you have either of those versions.

F.      If you’re not sure whether patch MNO has been applied yet, check the running version number. If it’s 2.95 or 3.05, patch MNO has been applied. If it’s 2.9 or 3.0, it still needs to be applied.

G.     There is no patch for versions 2.5 and 2.8. Please upgrade to version 3.2 as soon as possible.

H.     No action is required for all versions before 2.5.

A supplier could make all of these notifications in a single VEX, which would have fewer than ten statements. In other words, with this one VEX, the supplier would have answered all questions that users might ask about any previous version of the product, with respect to CVE 123. Even better, all of this is done without users having to contact the supplier, and without the supplier having to hire a bunch of new call center workers to handle the calls.

Pretty neat, huh?

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.