What is VEX? A) What reading this blog does to me, or B) A new advisory format that’s just as important as SBOMs?

More than a year ago, the NTIA Software Component Transparency Initiative came to the realization that there was a need for another new type of document, somewhat related to software bills of materials (SBOMs) but serving a different purpose. The initial name for the document was VEX, an acronym for Vulnerability Exploitability eXchange; this name has stuck. I’ve written two posts about this document, the more readable (and recent) of which is this one.  

I’ll let you read the previous post, but my purpose now is to describe why I’ve come to believe that VEXes might end up having as big an impact on software supply chain security as SBOMs, perhaps even more. The NTIA workgroup that’s been working on VEX has so far finished just one document – a one-pager – that describes VEX. It will be published this week (and will be available here). More documents will follow later, and I’m sure I’ll have more blog posts.

You may be wondering what the h___ the workgroup has been doing for a year, if all they’ve been able to accomplish is developing a one-page document. 90% of our work (I’ve been part of that workgroup) has been developing the format for VEX, and working with the OASIS Common Security Advisory Framework (CSAF) project to incorporate VEX as a “profile” within CSAF 2.0. CSAF 2.0 in an “official draft” status, meaning it’s completed the first of two or three steps required for it to be approved as an international standard. It will replace the existing CVRF format, which was developed by the same group. The German government is very involved with this project and intends to approve it as the official standard for vulnerability reporting in Germany (probably other European governments will do that as well).

That work is now done, so that a VEX will simply be a special case of a CSAF document. The purpose of “piggybacking” off an existing standard was to avoid (whenever possible) creating new formats. The NTIA initiative hasn’t created its own SBOM format, either. Instead, they have identified three existing SBOM formats – SPDX, CycloneDX and SWID – as equally worthy of consideration for a software supplier starting to produce their own SBOMs. In fact, last week SPDX was approved as an ISO standard; yet the three formats are different enough – and equally robust – that a supplier should consider all three  before they choose one (and a supplier can certainly produce SBOMs in multiple formats. There’s no need to stick to one).

Now that the format is settled, the VEX workgroup is starting to turn its attention to use cases and “rules of the road” for VEX. It turns out that, as I’ve delved further into these issues, I’ve come to realize that VEX isn’t just an adjunct document for SBOMs; it could come to be a key element of software supply chain security in its own right, as important as SBOMs themselves. Why do I say this? I’m glad you asked. Here’s some of what I’ve come to realize recently, although there’s much more that can be said.

Since the average software product has over 100 components (some have thousands), and since 90% of the average product consists of components, this means that vulnerabilities are far more likely to be identified in components of a software product than they are in the product itself. However, when you search for a product in the NVD, you will just see vulnerabilities that have been reported for the product itself, not vulnerabilities that are found in components of the product - since the NVD doesn't have an SBOM to tell it what those components are. 

That’s the bad news. The good news is that, for various reasons, the majority – and perhaps the great majority - of these component vulnerabilities aren’t actually exploitable in the product itself. That is a good thing, but it does make it likely that a lot of time will be wasted by suppliers and software users, responding to false positive reports of component vulnerabilities.

The solution to this problem is for suppliers to issue notices to their customers that essentially say “Even though CVE Y is found in component X, and component X is included in our product, CVE Y isn’t in fact exploitable in our product.” This might be because the supplier has already patched that vulnerability, but it could also be for various technical reasons. However, these notices need to be machine-readable, just as SBOMs need to be. That way, they can be fed into automated tools for vulnerability and configuration management, rather than have a burdensome manual process in between the VEX (or the SBOM) and the tool.

Every security person is used to receiving notices from software suppliers about vulnerabilities that are found in their products (or “exploitable in their products”); I call these positive software vulnerability notifications. However, the VEX can be thought of as a negative vulnerability notification, since it says that a vulnerability isn’t found in the supplier’s product.

Did VEX invent the idea of negative notifications? Not at all. Suppliers have been notifying users of non-exploitable vulnerabilities for years. The biggest example of this is patch notices: They say that if the user applies a patch to the software they’re running (or they download the current patched version), one or more vulnerabilities that were previously exploitable in the product will no longer be exploitable.

However, it is very likely that the number of VEXes will be overwhelming, far more than the number of patch notices currently put out. For example, since the average software product has 135 components, let’s say that each of these has a 1% chance of developing a vulnerability during any year; let’s also assume that the supplier’s own code in the product (which is actually called the “principal component” by the NTIA initiative) has a 1% chance of developing a vulnerability.

Since only the latter vulnerabilities are likely to appear in the NVD, this means that the NVD could be assumed to list only 1/136 of the total vulnerabilities that are found in the product – if you don’t take into account the fact that the majority of these vulnerabilities are unexploitable. If 90% of component vulnerabilities are unexploitable, this means that, once suppliers are regularly providing SBOMS (which means users will start looking up component vulnerabilities in the NVD), they will want to issue at least 120 VEXes every year, for every vulnerability identified for their product in the NVD. In fact, the number of VEXes per year is likely to be much larger than this, since my guess is more than one vulnerability is identified every year for the average software product.

However, a software product could easily have thousands of components (and some do, including products used every day by corporate and government users), at which point these numbers become huge. If a product has 5,000 components, this means there will be 5,000 component vulnerabilities identified every year, per my assumption. Since 90% of these won’t be exploitable and will need a VEX to state that fact, this means that the supplier of this product will have to issue at least 4,500 VEXes every year for the product.

This is of course a big number, but this explains why VEXes have to be machine readable. A user can receive SBOMs in a human-readable format (usually CSV or XLS files), but trying to keep track of VEXes will probably overwhelm – in a few years, not immediately – any manual effort to do that. However, it will be quite possible to track all VEXes, and to match them to a database of product components, through automated means.

And my feeling is that, once the tooling (or third party services) is developed to process VEXes, other types of negative software vulnerability notifications – especially patch notifications – will also move to the VEX format. Moreover, since VEXes can easily provide notification that a vulnerability is exploitable in a particular product, it seems to me that, in the not-too-distant future, those positive notifications will also move to VEX (right now, they’re mostly not machine-readable, and they’re provided in proprietary formats particular to each supplier. Note that suppliers will still be free to issue those advisories, even when they start providing positive VEX notices of exploitable vulnerabilities, since a lot of users will still want to have an advisory that they can read).

In other words, VEX is coming. And it might turn out to be an oncoming train. You should start thinking about how your organization might jump aboard.

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 National Technology and Information Administration’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.