VEX (Vulnerability Exploitability eXchange) is a set of formats used to describe whether vulnerabilities that affect components of a software product affect the product itself.
To understand VEX and why it is important, we need to ignore what has been written so far and start with its purpose. Why is VEX needed? Even more importantly, is VEX needed at all?
VEX is most certainly needed. It’s needed because software bill of materials (SBOMs) will never be widely distributed or used by organizations that are not software developers until the problem that VEX is intended to address is solved.
What is the problem that VEX is intended to address? It is rooted in the fact that one of the primary reasons why software users need to have SBOMs (or at least the risk management information that can be derived from them) is to learn about vulnerabilities found in the software they utilize on an ongoing basis.
The “ongoing” part is important because new vulnerabilities are being discovered all the time. In 2022, approximately 20,000 new vulnerabilities were added to the CVE.org database. Since there are other vulnerabilities besides those designated with CVEs (e.g., GitHub Security Advisories or GHSAs), even 20,000 is an underestimate of new vulnerabilities identified every year.
Thus, a product that had been thought to have no vulnerabilities a few months ago might be discovered to be riddled with vulnerabilities today, even though the code hasn’t changed. It is no exaggeration to say that organizations that use software and/or intelligent devices should receive daily updates about vulnerabilities that affect their software. (From now on, this post will refer to software and intelligent devices collectively as “software products” or just “products.” )
To illustrate the problem, let’s assume that a user organization receives an updated SBOM for a product they utilize, which is installed on their network. The SBOM lists 150 components. The user then imports the SBOM into FOSSA, which provides a list of the vulnerabilities associated with those components.
Let’s further assume that, for those 150 components, the tool finds 50 open vulnerabilities that apply to one or more of them. Furthermore, let’s suppose the user immediately gets on the phone with the supplier’s help desk for that product, demanding to know when each of those 50 vulnerabilities will be patched.
The user will be surprised when the usually friendly help desk person replies in a tired voice that they happen to be the 279th person who has called that morning with exactly the same question, and that they’ll give the same answer they gave to each one of them: Only 3 of those 50 vulnerabilities are “exploitable” in the product. The other 47 vulnerabilities are not exploitable and therefore pose no threat to the user organization. The supplier will patch the three exploitable vulnerabilities as soon as possible, but will not patch the other vulnerabilities at all.
Why is this scenario realistic? It is because the general consensus in the software security industry is that at least 90% of vulnerabilities that are found in components of a software product are not exploitable in the product itself; a recent study found that around 97% of component vulnerabilities aren’t exploitable in the product.
What does “exploitable” mean? If a vulnerability is exploitable, this means an attacker of average skill level, that tries to utilize that vulnerability to compromise a software product that is affected by that vulnerability, will usually be able to succeed. Conversely, such an attacker would never succeed if the vulnerability were not exploitable in the product.
Of course, one reason why a vulnerability might be said not to be exploitable in a product is that it is not present in the product at all. However, this isn’t the issue that requires VEX.
VEX is needed when a) an SBOM has been provided to users of Product X that indicates Component A is included in X; and b) a major vulnerability database indicates that CVE-2023-12345 is present in A. However, except in possibly a few corner cases, an attacker cannot compromise X by trying to attack Component A directly; for the attacker to succeed, the attacker would have to compromise X itself. Were that to be possible, this would mean that CVE-2023-12345 is exploitable in Product X, not just in Component A.
The question then becomes, how can the end user determine whether or not a vulnerability that is present in a component included in a product they use is exploitable in the product itself? The answer to that question is: In most cases, the end user can’t determine this on their own.
In the great majority of cases, the only entity that can determine whether or not a particular component vulnerability is exploitable in the product itself is the person or organization that developed the product in the first place. Only in cases where the supplier cannot or will not provide this exploitability information will there be a good case for another person or organization to provide it. This information is called VEX.
VEX Use Cases
The concept of VEX came up because software suppliers were concerned that, once they started releasing SBOMs to their end-user customers, their help desks would be overwhelmed with customers calling (or emailing) about vulnerabilities they had learned were present in a component of one of their products.
Of course, most suppliers should be happy to have a large volume of calls to their help desk, since that normally means their customers are using the software they’ve purchased from them. This means they are likely to become longtime customers, purchase maintenance, upgrade when possible, recommend the software to friends, etc.
However, in this case, around 95% of help desk calls will be regarding false positives — that is, component vulnerabilities that aren’t in fact present in the product. The customers who placed those calls are likely to be unhappy that they had to waste so much time inquiring about false positives, just as the help desk staff will be unhappy that they had to waste so much time telling these people they had nothing to worry about.
How can the supplier avoid this situation? As soon as possible after they have released a new SBOM (which they ideally should do whenever there is any change in the code in a product), they should inform their customers of non-exploitable vulnerabilities found in components listed in the SBOM. If the customers have that information, they are much less likely to harass the help desk about those non-exploitable vulnerabilities.
Of course, it takes some time to determine whether or not a vulnerability in a component is transitively exploitable in the product itself. This means that, when a new product version is released along with a new SBOM for that product, a VEX will usually assign an “Under investigation” status to vulnerabilities. Because users will want to learn as soon as possible which component vulnerabilities are exploitable in the product and which are not, this means the supplier should not wait to inform their users when they change the status of even one vulnerability from “Under investigation” to “Affected” or “Not affected.”
Note that this is not just a supplier concern. If end users aren’t informed quickly about false positive component vulnerability identifications, they are likely to waste large amounts of time searching for component vulnerabilities that aren’t exploitable in the products themselves. Both suppliers and users will benefit if suppliers make VEX information available to customers as quickly as possible.
Fields in a VEX Document
The reader may note that so far, this post has not discussed how VEX information will be provided to end users. The assumption from the very beginning of the VEX effort has always been that the only way to do that is with a machine-readable format. As it now stands, there are two VEX formats designed to fulfill the VEX purpose just described. One is based on the CSAF vulnerability reporting format; the other is based on the CycloneDX (CDX) BOM format (although it should be noted that a CDX SBOM does not need to accompany a CDX VEX or vice versa. Moreover, a CDX VEX can refer to either an SPDX or a CDX SBOM). For examples of VEX documents created in both of these formats, see the CISA VEX Use Cases document.
The two VEX formats use very different terminology for their fields, and each format requires some fields that are not present in the other format. The following are fields that are required to be in a VEX document of either format, in order for it to achieve its purpose. Note that the names of these fields are different in the two formats:
Component identifier - This is an optional field. For informational purposes, the author of a VEX may wish to identify the component of the Product that is the source of the vulnerability discussed in the VEX. However, the VEX describes the status of a vulnerability in the Product, not in a component that is a dependency of the Product.
Mitigation - If the status of a vulnerability is “affected” in Product A, the creator of the VEX needs to provide a text description of a mitigation for the vulnerability. The most common mitigations are “Apply patch XYZ, available at (url)” or “Upgrade to current version." However, other mitigations can include “Close firewall port XYZ”, etc. If the supplier will not patch the vulnerability, they can enter “Will not fix.”
Product - This can be a single product, multiple products, or a product family. If the latter, this should only be specified if a consumer tool will understand which products fall within the family; otherwise, designating a family is useless in a VEX (which is meant to be read by a machine, not a human being). The author recommends limiting a VEX document to a single product, since VEX status is always specific to one product.
Product identifier - There needs to be an identifier that will link a product to vulnerabilities in a vulnerability database. CPE and purl are by far the two most useful identifiers. It would be best to include both of them.
Status - This is the exploitability status of the vulnerability in the product. It answers the question, “Is CVE-2023-12345 exploitable in Product A?”, or equivalently, “Is Product A affected by CVE-2023-12345?” There are four possible values for Status:
- “affected”
- “not affected”
- “under investigation”
- “fixed” - i.e. patched
Status Justification - If the status of a vulnerability is “not affected” in Product A, the creator of the VEX needs to enter one of the status justifications. These are described in this CISA document. Note that CSAF has five “status justifications”, while CycloneDX has nine “justifications”, which address a superset of the status justifications described in the CISA document. The CycloneDX justifications have been available for more than two years, while the CSAF status justifications were introduced after publication of the CISA document in June 2022.
Timestamp
Version - The VEX format needs to be able to specify individual versions of a product, separately from the name of the product itself. It is also highly recommended that the format support version ranges, although it is likely that support will need to be limited to the set of versions identified in the VERS specification.
Vulnerability identifier - This can be designated using a CVE (e.g. CVE-2023-12345), a different vulnerability identifier like a GitHub Security Advisory (GHSA), or a textual description of the vulnerability. Both VEX formats provide fields for descriptive information like CVSS score.
The Future of VEX
The problem with both VEX document formats is they will require a fair amount of effort to produce and, more importantly, they will require a lot of effort to distribute to all customers (which will be required, of course). This means it is not likely that most suppliers will immediately produce a new VEX whenever there has been a change in the exploitability status of a component vulnerability in a product. Yet, this is exactly what customers are likely to require.
The author of this post has in recent months come to realize that suppliers might have to produce many VEX documents every day, for every version of every one of their products; of course, this means larger suppliers may have to produce hundreds or even thousands of VEX documents every day, and route them all to the proper users. This is simply not a sustainable situation.
What is sustainable is if the supplier maintains a distribution portal (or more likely shares space on the cloud dedicated to this purpose, with a lot of other suppliers. This service would be offered by a third-party service provider) that holds the information required for VEX. This includes (note that this information will always apply to a single version of a single product):
- Product name and version string
- A list of component vulnerabilities (derived from analyzing an SBOM for the product/version)
- The exploitability status of each component vulnerability in the product itself (“affected”, “not affected”, “under investigation”, or “fixed”)
- Other required VEX information (primarily, a “status justification” for every “not affected” status designation and a “mitigation” for every “affected” status designation).
Of course, it will be very difficult for suppliers to annotate exploitability status and justification at scale without context on package usage provided by customers. Consider asking your SCA/SBOM tooling vendor whether they support annotating SBOMs so that you may provide that context at scale.
This information will be required for every actively used version of every product that is being monitored; that is, if a supplier has ten products, each of which has ten actively used versions, there will need to be 100 separate sets of VEX information; each one will need to be updated regularly (ideally, at least daily). This is because VEX information only makes sense if it is for one version of one product. A supplier will need to update this information daily, although it will not always change in one day.
This server will be reachable through an API and will require authentication; in most cases, the users of the API will be customers of one of the products/versions that is being tracked. Instead of having to produce and distribute huge numbers of VEX documents, a supplier will only need to update the exploitability information in real-time on the VEX server; customers will be able to access the server using the API as often as they wish, which will normally be at least daily for each product that they use.
Note that the VEX information obtained through the API will be ingested by a tool operated by the user (or, more likely, a third-party service provider performing this analysis for the user). It will be used to manage vulnerabilities in the software product(s) operated by the user.
The author believes that this API will be specified in the near future, and that consumer services and/or tools will appear, which ingest SBOMs as well as the VEX API information, to help organizations understand the risks they face from active vulnerabilities in the software they utilize.
This post has described what is, in the author’s opinion, the most important use case for VEX information. As discussed above, this use case seems much more suited to an API than a JSON document distributed to end users. However, there is another use case for VEX information which is much better suited for JSON documents. This second use case, as well as other VEX-related topics, will be discussed in future posts.
