The joy of VEX, part I

I’ve said it before, and I’ll repeat it now: Even though the VEX document was developed to be a companion document to software bills of materials (SBOMs), I think it’s very possible it will end up being even more useful than SBOMs – which is saying a lot, since SBOMs themselves are quite useful. This is because having VEX available allows a software supplier (or a government agency) to answer, in a machine readable format, a lot of vulnerability management questions that are probably not even being asked now – and if they are, they can only be answered through a long phone call with someone in tech support. Here’s what I mean.

The VEX format was developed in order to answer one question: If CVE 123 is found in a component of Product ABC, does that mean that XYZ is actually exploitable in ABC? There are many reasons why a vulnerability in a component of a software product won’t be exploitable in the product itself – meaning an attack that utilizes that vulnerability won’t succeed. These include a) the component is a library, and the library module that’s vulnerable wasn’t included in the product; b) even though the vulnerable code is present, there’s no code path to it; c) the report that the product is vulnerable is mistaken (e.g. I’ve heard that Juniper gets calls every time Cisco announces a vulnerability in one of their products); etc.

To answer this question (often before it’s asked) in the negative, the supplier of ABC will put out a VEX that essentially says “Even though one of our components is susceptible to CVE 123, our product ABC isn’t susceptible to it, because (insert reason).” Why would a supplier put this out? For both a selfish and an unselfish reason.

The selfish reason is suppliers fear that, when a serious component vulnerability is announced, their support lines will be overwhelmed with calls from customers demanding to know when they’ll patch this vulnerability, even though in most cases the vulnerability isn’t exploitable (it seems to be agreed in software circles that more than half of component vulnerabilities aren’t exploitable in the product itself). The unselfish reason is that the supplier doesn’t want their customers to waste a lot of time scanning their product for a vulnerability that isn’t there.

Of course, can’t a supplier do this now, using non-machine readable means? Since most now notify users of exploitable vulnerabilities in their products using PDFs, web site postings, emails, etc., why can’t they use those same means to notify users of non-exploitable vulnerabilities?

They certainly can do that. For example, when a widely-publicized set of vulnerabilities comes out, like Ripple 20 or Amnesia:33, some suppliers put out notices saying in effect “You don’t need to worry. We have examined our products carefully, and to the best of our knowledge, these vulnerabilities aren’t present in our products.”

However, it’s safe to say that suppliers aren’t currently even bothering to issue a statement saying that a vulnerability isn’t exploitable in a particular product, despite the fact that it’s found in one of the components of the product. Why aren’t they doing this? Their customers aren’t likely to be concerned about component vulnerabilities, since few suppliers are even providing SBOMs to their customers. So most software customers don’t even know about the components in their software, let alone vulnerabilities in those components.

But this situation is changing rapidly. It’s safe to say that, by this time next year, software users will be much more likely to know about components of the software they use, and also about vulnerabilities that apply to them. This is due to recent events, including the May 12 Executive Order 14028 and Microsoft’s recent blog post, which said they will start providing SBOMs for all of their products. And since a) the average software product has 135 components and each of those components can have vulnerabilities, while at the same time b) perhaps more than 90% of component vulnerabilities aren’t exploitable in the product itself (meaning 90% of component vulnerabilities might require a VEX), it’s clear that software suppliers have good reasons to be worried about their support resources being overwhelmed with calls about non-exploitable vulnerabilities.

But I’ve come to realize lately that there are a lot more questions about software vulnerabilities that aren’t being asked or answered now by any means – machine readable or not. Yet these questions aren’t being overlooked because they’re not important ones. They’re probably being deliberately put aside, because the resources that are required to answer them, including a customer spending a lot of time on the phone with one or more support people, are substantial. So in most cases, asking the question doesn’t seem to be worth the trouble for users.

Having a machine readable means of proactively answering the question for all customers of a product – as soon as the need to answer it becomes apparent – will make it much more likely that these questions will be asked and answered in the first place. What are some of these questions? And what would be the best way for the supplier to proactively answer them, using their powerful new VEX tool?

Note that I’m assuming below that there’s either a vulnerability management tool or a third-party service on the customer’s end, which is capable of reading VEXes and incorporating information from them into the list of open vulnerabilities in each software product in use in the organization. There isn’t such a tool or service now, but I know there’s more than one in the works.

Question 1: I’ve heard a lot about the new serious vulnerability CVE 123. Have you (i.e. the supplier) released a patch for CVE 123 yet?

Let’s say the supplier has already released a patch for CVE 123 in the current product, which is on version 1.30. Normally, they’ll release a patch notification in a PDF or some other non-machine readable format; this might or might not reach the right people in the organization. On the other hand, the VEX will go directly to the organization’s vulnerability management tool or service, so there’s no doubt it will be “heeded”. Here are the steps the supplier should take:

1.     When they patch the current version of the product, increment the version number. If the current version is 1.30, the patched version might be 1.31. Note that incrementing the version number should be a normal procedure. If the version number doesn’t change yet the code does change, the product becomes unsupportable.

2.      Send out VEX 1, which applies to v1.31. It indicates that CVE 123 has a status of “not affected” in the product (for a description of the VEX status designations, see this one-page VEX overview. Note that the “fixed” status could also be used in this case).

3.      Every “not affected” status in a VEX must be accompanied by a textual “impact statement” that describes why the product isn’t affected by the vulnerability in question (the impact statement isn’t mentioned in the VEX overview just referenced, but it’s mentioned in this CSAF Profile of VEX. I’ll freely admit that the Profile isn’t easy reading. I hope there will be more explanatory material out on VEX in the not-too-distant future). In this case, the supplier might write “CVE 123 was patched by Patch XYZ” for the impact statement.

4.      Assuming application of the patch automatically incremented the version number of the installed instance of the product from v1.30 to v1.31, the customer who asked that question will be able to ascertain whether or not their version has been patched, by simply checking the version number.

Question 2: I may have missed a patch notice. Does CVE 123 affect version 2.5? If so, do you have a patch for it?

1.      The supplier should issue VEX 2 indicating that CVE 456 has a status of “affected” with respect to version 1.30 of the product (i.e. the version that was patched, making it v1.31).

2.      Because a status of “affected” requires that the supplier provide a textual “action statement” that describes mitigation steps for the vulnerability, the supplier should enter something like “Apply patch XYZ (which of course is the patch for CVE 123).” If any other mitigation steps are required – and whether or not a patch is required – they should be included in the action statement as well.

Note that, with the actions taken to address questions 1 and 2, the supplier has effectively provided two different patch notifications. VEX 1 is like “traditional” patch notifications: it says “Here is the patch for CVE 123.” VEX 2 is unlike traditional notifications, since it says “Version 1.30 is vulnerable to CVE 123.”

Here’s an extra credit question: Why is it that you don’t currently see software suppliers issuing notifications like VEX 2, that state “Yup, we’re vulnerable to CVE 123, which has a CVSS score of 9.8. Have a nice day”? You’re right! It’s because they’d probably be out of business in a week, since every hacker in the world would now know exactly how to compromise their product.

In other words, when the supplier issues a “traditional” notification that they’ve patched CVE 123 in their product, they’re implicitly also stating that the product was vulnerable in the first place. They would never issue a notification that stated explicitly that their product was vulnerable, unless the patch was already available.

However, by using VEX1 and VEX 2 in place of their traditional (non-machine readable) notification, the supplier is able to accomplish more than they could without VEX. Specifically:

1.      By saying that v1.31 includes a patch for CVE 123, VEX 1 implicitly states that v1.30 is vulnerable. The message is clear for all who have ears to hear: If you still have v1.30 (meaning you haven’t yet applied the patch), you need to get off your a__ and apply Patch XYZ right away. A traditional patch notification works in a similar fashion.

2.      But what if someone didn’t get the traditional patch notification, so they don’t know about the new patch, and they also don’t know that v1.30 is vulnerable? Traditionally, their status would become SOL. However, VEX 2, which states that v1.30 is vulnerable to CVE 123 and a patch is available, will automatically notify the customer’s vulnerability management system that a patch needs to be applied. It will be much harder for that to slip through the cracks.

The point of this post is that use of VEXes provides the supplier (and government cybersecurity agencies, if they want to take advantage of VEXes) with capabilities they didn’t have before: in this case, the capability to provide a “failure-proof” notification to their customers that they need to apply a particular patch ASAP.

I’ve thought about other such cases as well, and it seems there are a number of them. I’ll hope to discuss one or two of these in the near future. In the meantime, I wish to call your attention to an old Irish limerick (the original Gaelic is listed in a comment below):

There once was a format named VEX,

Which we thought too opaque and complex.

When we learned it was free,

We shouted with glee,

"This is certainly better than sex!"

While I can’t vouch for the accuracy of the last assertion, this strikes me as a remarkably prescient piece of poetry.

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 CISA’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.