It’s time for the VEX talk…

 

I’ve wanted to have this talk with you for a long time, but I’ll admit I’ve been putting it off. However, there are some important things you need to know about VEX, and I’d rather you hear them from me than from someone else (such as one of your friends):

1.      There are now two VEX formats. They’re very different, although they have the same purpose. The first is based on the new CSAF version 2 vulnerability reporting standard from OASIS (it uses a subset of the capabilities in that standard, called a profile). The other is based on the OWASP CycloneDX SBOM format, although any SBOMs referred to in the VEX can be in either CycloneDX or SPDX format.

2.      There is no direct connection between SBOMS and VEX documents. Even though the VEX format was developed to address the issue of non-exploitable vulnerabilities identified using SBOMs, the VEX itself doesn’t need to refer to an SBOM or to a component. The question of the exploitability of a vulnerability, that is found in a particular component, only applies to the product as a whole: Is the vulnerability exploitable in the product or not?

3.      There’s no way to do a direct translation between the two formats; by that I mean not only that there aren’t translation tools, but that I don’t even see a good way to do a direct translation, other than to extract the data from one format and create a new VEX in the other.

4.      Currently, there aren’t any automated tools to create VEXes[i] in either format. This recently approved document from the CISA VEX committee provides links to JSON code for various use cases, in both VEX formats.

5.      However, unlike with SBOMs, where the format used should be a concern for end users, end users really shouldn’t care in what format a VEX is provided, as long as the tool or third-party service they are using to track vulnerabilities in software components can interpret it. This is because a VEX document, even though it’s comprehensible to a human who wants to invest some time learning about the format it’s written in, will always be created with machine readability in mind.

6.      Suppliers are already providing vulnerability notifications to their users in various ways now – in emailed PDFs, website postings, etc. So, VEXes don’t give them a new capability (as SBOMs do)[ii]. When suppliers start providing VEXes, they’ll be expressly intended to be read by machines; the user will seldom read a VEX themselves. If they do, it will probably be to satisfy their curiosity about what the VEX looks like, not actually to absorb information.

7.      And speaking of machine readability, what tools or third party services are currently available to utilize VEX documents? The tool will need to do more than ingest VEXes, since VEXes alone won’t usually provide any useful information. Instead, a tool will need to do all of the following:

a.      Ingest an SBOM about a particular software product (or intelligent device) – say, product A - and retrieve all the component information from it;

b.      Using the NVD or another vulnerability database like OSS Index, create a list of vulnerabilities currently applicable to components listed in the SBOM for A;

c.      Ingest a VEX document or documents that apply to A;

d.      Based on the information in the VEX documents, remove from the list of vulnerabilities applicable to A all vulnerabilities that aren’t exploitable in A; and

e.      Repeat this process daily, if not more often.

8.      As VEXes are received, the list will be whittled down so that it contains only exploitable vulnerabilities. Thus, the user is much less likely to waste their time trying to identify and patch non-exploitable vulnerabilities, than they would be if they didn’t receive VEXes at all.

9.      Currently, there are no tools or subscription-based third-party services that perform steps a. to e. above. However, I know that the Dependency-Track open source tool will soon be able to ingest CycloneDX VEXes (it can create VEXes now, in the CycloneDX VEX format). Dependency-Track has for at least ten years been able to read SBOMs (in the CycloneDX format) and look up vulnerabilities in the NVD or OSS Index. It is now getting a huge amount of use from developers who want to learn about vulnerabilities affecting components in a software product they’re developing. The VEX ingestion capability (which I’ve seen demonstrated) should be available soon.[iii]

10.   Even with the current lack of tools for utilizing VEXes by end-users, I’m optimistic that the tools and the VEXes will be available before long. This is because software suppliers are the main drivers behind the VEX format. Two very large suppliers were the most interested in getting work on the format started in 2020 and are still heavily involved with that work today. Both of these suppliers – as well as many more – are very concerned about the heavy load that will be placed on their help desks if customers start calling in about the large number of vulnerabilities that will be found in the NVD for components of their products. The customers will naturally think of all these vulnerabilities as exploitable – when in fact only a small percentage of them are. One of the two large suppliers said they expected that producing VEXes along with SBOMs will end up saving them thousands of false positive help desk calls every month.

11.   In this post, I suggested that suppliers should take responsibility for a) looking up components vulnerabilities in the NVD every day, and b) “whittling down” the list of vulnerabilities so that only exploitable ones are left on it. This would confer the added advantage that VEX documents would never have to be sent outside the supplier (or outside the third party that the supplier engaged to perform this work for them), and end users wouldn’t have to look up component vulnerabilities themselves.

12.   If you think about it, it’s somewhat silly that, if a supplier has for example 10,000 customers, every one of those customers should have to look up the same components in the NVD and get the same list of vulnerabilities, vs. the supplier just doing it once for all of them. Following the five steps listed above, the supplier would provide their customers a continually updated list of exploitable vulnerabilities in particular versions of their product or device (whichever versions the customer is using). I think this idea makes a lot of sense and will probably be realized one of these days, just due to market pressures.

13.   Another thing I would like to see happen is what I call “real-time VEX”. These are simple VEX documents focused on only one product (although perhaps multiple versions of that product), that simply list non-exploitable component vulnerabilities in the product. Because they are so simple, the supplier would put one out as soon as they discover that a particular component vulnerability or vulnerabilities isn’t exploitable in the product. Receiving these right away will allow end users to avoid what could be a lot of wasted effort looking for vulnerabilities that simply aren’t there – as opposed to waiting a week or more to receive that information.

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] By “automated tool for producing VEXes”, I mean a tool that will ask the user (typically a supplier producing a VEX for their product) the specific questions that need to be answered in a VEX, including “What is the product?” “What is the vulnerability?” “What is the status of that vulnerability in each of the versions that you wish to report on?” etc. With the answers to those questions, the tool will produce a VEX in one of the formats (CSAF-based or CycloneDX-based). I don’t think it will be hard to develop such tools (at least as far as one of the formats is concerned), and I’m sure some will be developed soon. 

[ii] VEX was developed specifically to provide a “negative vulnerability notification”. The normal “positive” notification that we’ve all seen from software suppliers usually says something like “This vulnerability (CVE-2022-12345) is exploitable in our product. Please apply patch XYZ or upgrade to version XX.XX.” However, a negative notification essentially says, “This vulnerability is not exploitable in our product. You don’t have to do anything about it.” Negative notifications have always been an option, but they were not often needed until SBOMs started becoming available. However, since there’s agreement in the software community that a majority of vulnerabilities found in software components aren’t exploitable in the product itself, the advent of SBOMs suddenly created an immediate need for machine-readable negative notifications. Of course, both VEX formats can produce positive notifications as well. 

[iii] Fairly soon, there will also be a subscription-based third-party service that will ingest both SBOMs and VEXes and provide users with a continually updated list of exploitable component vulnerabilities in products of concern.