It’s time for some basic VEX education

 

I’ve written a number of posts about VEX, but there are only one or two posts that I’ve linked when I want to explain the term itself, so that someone who hasn’t heard of VEX can get a quick education. However, I recently went back and read those posts, and realized that they don’t actually give a basic explanation of VEX. Instead, they assume basic VEX knowledge to start out. Now, I’m writing the post I should have written a while ago. I’ll use this as my “VEX education” link in the future.

VEX is an acronym for “Vulnerability Exploitability eXchange”. VEX is a simple yet machine-readable pair of formats for reporting the status of vulnerabilities found in software products and intelligent devices. While it can be used for any vulnerability reporting, it was developed specifically for a use case specific to suppliers that provide SBOMs for their products.

VEX was developed to enable a supplier to notify its customers, in a machine-readable format, that a vulnerability they may believe is exploitable in their product is not in fact exploitable. The primary reason that customers would ask this question in the first place is if they have received an SBOM and looked up its components in a vulnerability database like the NVD, then learned about one or more serious vulnerabilities that apply to those components. They might waste a lot of time (and worry) trying to find and patch vulnerabilities that aren’t exploitable, and therefore pose no danger to them.

Another reason for a VEX is that a specific vulnerability or set of vulnerabilities, like the log4j or Ripple20 vulnerabilities, has been widely discussed in the news – and users want to know whether or not it applies to a software product they use.

The consensus in the software industry is that at least 90% of component vulnerabilities are not exploitable in the product itself, usually because of how the component was incorporated into the product. For example, a library may have four modules, but the supplier might have only installed the three modules that they needed. A serious vulnerability could be identified in the library, but it happens to be found in the fourth module, which the supplier didn’t install. Therefore, the vulnerability is not exploitable in the product itself. A VEX document will state that fact.

It is likely that the great majority of VEX documents will be based on the use case of identifying non-exploitable component vulnerabilities. However, the simplicity of the VEX idea enables a number of other powerful use cases for vulnerability notifications. These use cases go beyond the case for which VEX was originally developed.

The need for VEX arose from discussions in the Software Component Transparency Initiative (hereinafter, “the Initiative”). This was a “multistakeholder process” convened by the National Technology and Information Administration (NTIA) division of the US Department of Commerce, beginning in 2018 and ending in late 2021. The purpose of the Initiative was to get together private and public “stakeholders” in the software marketplace to discuss securing software and intelligent devices from risks arising from use of third-party and open source components; of course, the main tool for accomplishing this purpose is SBOMs.

Early on in those discussions, it became apparent that there was a lot of concern about the problem that was discussed above: the fact that a large percentage of vulnerabilities identified in components included in a software product are not in fact exploitable in the product itself.

At first, this might seem to be a good thing. After all, if 90% of vulnerabilities in the components of a product aren’t exploitable in the product itself, this means that the “attack surface” of the product is reduced by 90%, compared to what it would be if all component vulnerabilities were exploitable in the product itself.

This is true, but the problem is that the end user cannot normally determine, through their own actions, which component vulnerabilities are exploitable in the product, and which are not exploitable. Not having this information, the user needs to assume that every component vulnerability they have identified is exploitable. Thus, they may waste a lot of their time trying to determine whether these vulnerabilities are actually present in the product. Moreover, they will waste the supplier’s time by continually contacting their help desk to inquire when each of these vulnerabilities will be patched.

The NTIA group discussing this problem decided that the best way to prevent this from happening is for the supplier to notify the customer that a particular vulnerability is not in fact exploitable in the product, even though it is listed in the NVD (or another vulnerability database) as applicable to a component of the product.

Note that this is a type of vulnerability notification that has not been used very much, simply because it has not normally been needed. A “normal” vulnerability notification says, for example, that CVE-2022-12345 is exploitable in product ABC version X.Y.Z. We call this a “positive” vulnerability notification, since it states that a particular vulnerability is exploitable in the product.

Of course, if this example is a positive vulnerability notification, then the notification mentioned above – i.e. that a particular vulnerability found in a component of a product is not in fact exploitable in the product – should be called a negative vulnerability notification.

The supplier is normally the party that is best able to provide vulnerability exploitability information, since they have access to the source code and know in intimate detail how the product was built. Fortunately, it is also in the supplier’s interest to get this information to their customers, since this will eliminate a lot of “false positive” calls to their help desk.  However, because it is likely that many suppliers, at least initially, will not provide either SBOMs or VEX documents, third parties might need to step in to provide VEXes on their own.

There are currently two VEX formats. The first is based on the CycloneDX SBOM format (although it can refer to SPDX SBOMs as well). The second consists of a subset of the CSAF vulnerability reporting format. Unfortunately, as of now (September 2022), the CSAF VEX format isn’t completely specified (a partial specification, which will be enough for someone who already understands CSAF, is here). A “playbook” for creating and using VEX documents is currently being prepared by the CISA VEX working group.

Because of the delay in developing proper documentation for producing and using VEX documents, as well as the fact that end users will want to know about the exploitability status of component vulnerabilities as soon as they learn about them – not several days or weeks later, depending on how long it takes the supplier to produce a VEX document – I am now advocating for the idea of “real-time VEX”.

This is essentially an API where a user will be able to learn instantaneously what the supplier currently believes to be the exploitability status of a particular component vulnerability (of course, that status may be “We’re still investigating it”). My guess is that, if this is implemented, the need for a majority of VEX documents will disappear. VEXes will still be needed for more complex use cases like patching, but the urgent use cases can all be handled by the API.

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.