Thursday, July 14, 2022

What’s a VEX? What isn’t a VEX?


The CISA SBOM “listening sessions” kicked off this week, and they were all good – and very well attended. There are still two more next week, so you might want to check them out, if you’re at all interested in SBOMs. No registration is required, and you can get the times and connection information here.

One thing that struck me during the conversations is how many people spoke very knowledgably about VEX documents – and had completely the wrong idea about them. They were not only wrong, but they were 180 degrees wrong.

However, I don’t blame them for this. Until a few months ago, the only official publication on VEX was a one-page document published by the NTIA last fall. Having prepared the first draft of that document, I thought it was very good, but it’s now very much out of date and shouldn’t be relied on. There are now two good documents – one of which came out yesterday – that are useful for particular topics, but neither one constitutes a comprehensive introduction to VEX and how VEX documents can be produced and used. The two documents are both available at the first link above. I also have produced a number of posts on VEX, which you can find by searching on the term in the search bar at the top left.

The problem with what these people said is that they think VEX is a vulnerability report – a list of vulnerabilities that apply to components found in an SBOM, or maybe vulnerabilities in the product itself. What’s confusing is that a VEX can be exactly that. It can say (in JSON), “This component included in product X version Y is affected by CVE-2022-12345.” Or perhaps, “Product X version Y itself is affected by CVE-2022-12345.” Given the dearth of official information on VEX, it is quite understandable that people think this must be the purpose of a VEX. After all, they’re used to receiving notifications like that from their software suppliers now.

However, if that were the purpose of VEX, there would have been no need to invent the format (actually “formats”, since there are two, although they’re very different from each other). Yes, VEX is machine readable, and most of us are only used to seeing human readable vulnerability notifications in the form of emailed PDFs or web page notices. But machine-readable vulnerability notifications have been around for at least seven years. In fact, one of the two VEX formats is based on the CSAF vulnerability reporting format, which gives the supplier a huge range of options for reporting vulnerabilities. However, that VEX format itself just utilizes a small percentage of the available fields in CSAF. If your aim is to make the type of vulnerability reports that you’re used to seeing in PDFs, you would be much better off using the full set of CSAF fields, not the VEX subset.

VEX was developed because there was a need for a machine-readable format that said the exact opposite of what a traditional vulnerability report says. Instead of saying, “Product X version Y is affected by CVE-2022-12345”, a VEX says “Product X version Y is not affected by CVE-2022-12345”. At first glance, that might seem like a strange thing to say. After all, there are already more than 20,000 CVEs in the CVE database, and more are added all the time. Assuming a product is currently affected by ten vulnerabilities, does that mean the supplier needs to put out both a traditional notification that the product is affected by those ten CVEs, and t a VEX that lists the 19,990+ vulnerabilities it’s not affected by?

Fortunately, that’s not what VEX was developed for. VEX was developed to deal with the problem that, when you receive an SBOM and look up (in the NVD or another vulnerability database) the vulnerabilities applicable to the components, for every 20 vulnerabilities you identify, usually 18 or 19 of them (maybe 20 in some cases) will not be exploitable[i] in the product – meaning you wouldn’t find those vulnerabilities if you scanned the product with a vulnerability scanner, and a hacker wouldn’t be able to utilize them to attack the product. You don’t have to take any further action regarding the non-exploitable vulnerabilities.

Now you probably think I’m crazy (and there would be some merit to that diagnosis, I’ll admit). Why is it a “problem” if it turns out that 19 out of every 20 vulnerabilities identified in components of a product aren’t exploitable in the product itself? After all, you’ve just reduced your vulnerability management workload to 5% of what it would have been otherwise.

It’s a problem because, after you find those vulnerabilities in the NVD, you have no way of knowing which are one of the 19 non-exploitable vulnerabilities, and which is the exploitable one. You need to look for all of them on your network and then you need to call up and interrogate your supplier’s help desk staff about when they’re going to fix all 20 vulnerabilities.

But if you do harass the supplier about all 20 CVEs, the tired help desk person is going to tell you, for 19 of them, “Yes, I understand that CVE applies to component A in our product, but actually – as I’ve already told 245 people today – the CVE isn’t exploitable in the product, so you don’t need to worry about it anymore.

And then you’ll feel like an idiot, both for wasting the help desk person’s time and, most importantly, wasting your own time. Wouldn’t it be great if you could have learned about the non-exploitable vulnerabilities before you started pursuing them?

This is the problem that VEX was invented to solve. After you receive an SBOM, you’ll receive VEXes as the supplier realizes that certain vulnerabilities aren’t exploitable in their product, even though they are listed in the NVD for a component of the product. You will sleep better at night and the supplier will sleep much better, knowing they don’t have to hire another 50 help desk people to handle all the calls about vulnerabilities that turn out to be non-exploitable (in fact, one of the two huge suppliers that sparked the development of VEX in 2020 estimated that they would get thousands of false positive help desk calls for exactly this reason, if there weren’t some way of notifying users about non-exploitable vulnerabilities).

Of course, VEXes can be used to create positive vulnerability notifications as well – i.e., “normal” ones. And there are uses for positive notifications in VEX, usually in combination with negative notifications. For example, when a supplier has patched a serious vulnerability and wants to let their customers know about the status of the vulnerability in all versions of their product – i.e. whether each version is vulnerable or not vulnerable - they can issue a VEX that provides all this information in one place, in a machine-readable format. This post discusses that use case.

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 tom@tomalrich.com.


[i] For a discussion of exploitability, see this post.

No comments:

Post a Comment