Needed: Real-time VEX

The VEX format was developed to solve a very specific problem with SBOMS: Probably over 90% of vulnerabilities identified in components of a software product (i.e. when those components are scanned as standalone software) aren’t exploitable in the product itself.

Of course, this is basically a good thing – after all, if I identify (through the NVD) 100 unpatched vulnerabilities in components of a software product that I use, that means that 90% of them aren’t exploitable in that product. In other words, I don’t need to concern myself with them.

But the problem is that I don’t know up front which of the 100 vulnerabilities I identified are the ones that aren’t exploitable. Absent some notification from the supplier (or perhaps a third party) that certain vulnerabilities aren’t exploitable, I have to treat them all as exploitable. This means I will probably waste a lot of time scanning for (and in some cases patching) vulnerabilities that aren’t there. And since I’m likely to contact the supplier to find out when they’re going to patch all of these vulnerabilities, suppliers are worried that their support staff will be overwhelmed, due to having to respond to emails and calls about non-exploitable vulnerabilities.

Of course, this is why God created VEXes (OK, He didn’t do that. Frankly, I’m not even sure He created SBOMs). The VEX essentially says, “Even though you found in the NVD that CVE-2022-12345 is found in Component X and Component X is found in our product ABC, the vulnerability isn’t in fact exploitable in ABC. So you don’t have to worry about it.” [i]

But here’s a question: After a component vulnerability appears in the NVD (and users of SBOMs learn about it, since they will hopefully be using an automated tool or third-party service that tracks these things), how long will it be before the supplier (or perhaps a third party, either engaged by the supplier or acting independently of them) puts out a VEX stating whether or not it’s exploitable?

And here’s the problem: It’s highly unlikely that a supplier will issue a VEX immediately after they discover that a component vulnerability isn’t exploitable – after all, the average software product has over 100 components, and many products have in the thousands or even tens of thousands; new component vulnerabilities will be popping up all the time in the NVD. Since they have other things to do, it’s likely the supplier (specifically their PSIRT) will only issue VEXes once a week, or even less frequently. This means that their customers may be searching in vain for a serious component vulnerability (and or bothering the help desk about it) for say a couple of weeks before they get the VEX saying it’s not exploitable.

Wouldn’t it be nice if a user could find out about a non-exploitable vulnerability as soon as the supplier knows about it? Yes it would, and that wouldn’t be hard to do. Someone would just have to insert some fairly simple code in some tool used for vulnerability management, which does the following:

1.      Identifies, in the NVD, a serious vulnerability (CVE) in a component of a software product (or intelligent device) that is being used by the organization. Then,

2.      Sends a query to an API running at a URL pre-specified by the supplier of the software or device, inquiring whether this vulnerability is in fact exploitable. In effect, one of these three responses will be quickly received:

a.      “This vulnerability isn’t exploitable in our Product ABC version X.Y.Z.” There should also be a brief textual description of why this is the case, e.g. “Even though one or more modules in this library are included in our product, the vulnerable module isn’t included”[ii]; or

b.      “This vulnerability is exploitable in our Product ABC version X.Y.Z. We recommend you immediately apply the patch available at this location…”; or

c.      “We are currently investigating the exploitability status of this vulnerability in Product ABC version X.Y.Z.” [iii]

Note that the above three statements are just a small subset of the totality of statements that can be made in a single VEX; for an example of a single VEX that would include all of the notifications that a supplier might need to make when a serious vulnerability is patched, see this post. That full document could never be replicated by the simple API above. So what I’m suggesting doesn’t replace VEX documents.

However, it seems to me that this would be fairly easy to implement. The main thing would be to disseminate the API to suppliers interested in distributing SBOMs for their products, since – as I’ve said a number of times – SBOMs almost certainly won’t be widely used until VEX documents are widely available.

The moral of this story: Real-time VEX information will save a lot of users and suppliers time and money. And it will make SBOMs much more usable.

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.

---

[i] There may be some high-assurance users who want even non-exploitable vulnerabilities patched; this is because in some unusual circumstances, a vulnerability might become exploitable later. I have also been told by a couple large developers that they have customers who demand that every vulnerability be patched, regardless of whether or not it’s exploitable. They say they need this for compliance purposes. I strongly doubt they’re right about this, but of course it’s not my business to argue with them; it seems those developers are simply taking their word for it. 

[ii] This was a case with a lot of instances of the Log4j library being incorporated into particular products. If the Log4Shell module wasn’t included in the product (which normally the supplier would have to tell you. The NVD doesn’t track that sort of information), the user probably wasted their time if they patched the product. 

[iii]  If the vulnerability is exploitable but the supplier is still working on a patch, they would be well advised not to state that it’s exploitable, but just say it’s under investigation – for reasons that should be obvious.