The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


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

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents, Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 375 items added with 121,876 views
  • Sep 15, 2021

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, the NVD doesn’t list vulnerabilities in components of a product, just those found in the code actually written by the supplier you bought the product from.

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

Richard Brooks's picture
Richard Brooks on Sep 15, 2021

Reading this article you might get the impression that SBOM is something futuristic and not readily available today. Let me assure you, SBOM is here today and there are numerous tools available for both NTIA supported SBOM formats SPDX and CycloneDX, to help software vendors and software consumers implement now and reap the benefits of SBOM.

VEX is completely independent from SBOM. You do not need VEX in order to implement SBOM today. VEX may indeed be a futuristic vision, as Tom points out, but do not conflate SBOM with VEX. SBOM, as input to a NIST C-SCRM risk assessment can help software consumers identify risky software and prevent it's installation, where it can cause harm, resulting in painful and costly recovery. Plus, it's very easy to get started with SBOM, all a consumer needs to do to start using SBOM is to simply "Ask your software vendor to provide an SBOM in SPDX or CycloneDX format".

Also, The Linux Foundation is helping to advance SBOM adoption by hosting a DocFest on 9/16 where numerous SBOM tool providers are sharing SBOM's to show interoperability and provide convincing evidence that SBOM is here today and it works as expected. You can stop ransomware and other harmful software from taking up residence in your systems and networks today; use SBOM to identify vulnerable/risky software and prevent it's installation, NOW.

Tom Alrich's picture
Tom Alrich on Sep 15, 2021

Dick, the NTIA initiative decided to develop VEX because some major suppliers were saying they couldn't distribute SBOMs until there was some channel by which they could notify users when a component vulnerability wasn't exploitable in their product. So it's not at all an exaggeration to say that there won't be widespread distribution and use of SBOMs until VEXes are also widely distributed and used.

Fortunately, the VEX format is already established now, and medical device makers are currently producing VEXes to go with their SBOMs, as part of the healthcare SBOM Proof of Concept. And the energy and Autos PoC's  will also produce both SBOMs and VEXes. So the two documents will grow together.


Richard Brooks's picture
Richard Brooks on Sep 15, 2021

Thanks for clarifying, Tom. I was just pointing out that vendors and consumers can begin to use SBOM today, without waiting on VEX to reach critical mass. Having both available is clearly better, to your point.

Jim Stack's picture
Jim Stack on Sep 15, 2021

Nice of you to add in some humor with all those acronyms.  QUOTE=What is VEX? A) What reading this blog does to me. 

It's good it is software generated with 5,000 components in some products. QUOTE=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.

Tom Alrich's picture
Tom Alrich on Sep 16, 2021

Thanks, Jim. Actually, I'd say it's likely there will be more than 5,000 vulnerabilities in components identified. But a huge portion of these will end up being non-exploitable in the product itself, which is why VEX is so important. Without VEXes there will be massive time-wasting as people search for non-existent vulnerabilities.

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »