The big problem with VEX

Suppose you’re a talent scout for a major league baseball team. Every year, you want to find about 50 of the best college ball players, out of approximately 60,000, to sign contracts and enter your farm team program.

You have two options for identifying those 50 players:

1.      You can go to games, talk to people, read stats, etc. – and use that research to identify the Nifty Fifty; or

2.      Instead of identifying the 50 directly, you can identify the 59,950 that you don’t want to sign a contract with. Once you’ve done that, you’ll sign contracts with the remaining 50.

Either way, you’ll end up with 50 players, and for the sake of argument, let’s assume you’ll end up with the same 50, regardless of how you identify them. Is there any advantage to choosing one of the two methods over the other or are they more or less the same?

If you think that it doesn’t matter whether the scout chooses Door Number 1 or Door Number 2, you should put on your dunce cap and sit in the corner. Door Number 2 will require a huge effort and probably a small army of scouts. On the other hand, Door Number 1 is probably something you and an assistant could handle quite easily in the course of a year. Door Number 1 is really the only choice.

Now, let’s change the field from baseball to software component vulnerabilities. Suppose you know that, on average, over 95% of software component vulnerabilities – which you identify by looking up the components found in an SBOM in a vulnerability database like the NVD or OSS Index – aren’t exploitable in the product itself. Thus, if you spend a lot of time trying to verify every component vulnerability you identify, and perhaps you harass the supplier’s help desk by asking when they’ll fix each vulnerability, on average, 95% of that time will be wasted.

Wouldn’t it be great if you had some way of knowing beforehand which were the 5% of vulnerabilities that were exploitable, so you could just focus your time on those? You would suddenly become 95% more productive. Maybe you’d be able to make it home for dinner with your family more often than you do now.

Of course, this is the problem VEX is intended to solve. So, here’s the big question: Which of the above two methods does VEX use? If you rely on VEXes to narrow down your list of component vulnerabilities to the 5% that are exploitable, are you choosing Door Number 1 or Door Number 2? The answer is…envelope, please…Door Number 2! Yes folks, instead of identifying the 5% of component vulnerabilities that are exploitable, VEX documents – if they work as intended - tell you the 95% that aren’t exploitable. You then need to remove the 95%, so you’re left with the 5%.

Is this efficient? Obviously not! But why can’t a VEX document just tell you the exploitable 5% of vulnerabilities, not the non-exploitable 95%? I doubt I have to tell you this: If a software supplier were to produce a document that lists just the exploitable vulnerabilities and send it to their customers, they might as well skip the middle man and send it directly to Uncle Vlad himself at russia.piratestate.gov. Because a supplier has to assume that any document they send out is going to end up in the wrong hands, no matter how many NDAs and blood oaths they require from their customers. That’s just the nature of documents.

You may wonder why Door Number 2 creates such a problem. If the supplier just prepared a single VEX document that listed all the non-exploitable vulnerabilities in their product and your tool (when one is available) ingested that document and removed all the non-exploitable vulnerabilities from the list for the product in question, would that be so hard? In fact, you could pick up your coffee cup and take a sip while your tool was doing this, and the tool might finish before you did. What’s wrong with that?

The problem is that the supplier isn’t likely to identify all or even most non-exploitable component vulnerabilities at one time. It may take them weeks or months to identify even most of them. Is it likely they’ll wait ‘til they’ve identified a large number of them, then send you one VEX document with all that they’ve discovered so far? Not if they want to keep their customers. The last thing they’ll want to do is delay a week or two to send out a VEX saying that 20 component vulnerabilities aren’t exploitable, then receive a bunch of angry emails from customers, telling them how much time they spent trying to find and patch those 20 vulnerabilities, and telling them where they can put their stupid software from now on.

Suppliers that value their customers’ time (and license fees) will feel compelled to send out a VEX as soon as they learn a component vulnerability isn’t exploitable. And if they’ve sent out three VEXes in the morning and they learn about another non-exploitable vulnerability in the afternoon, they’re not going to wait overnight to see if they learn about a few more the next morning, before they send another VEX. They’ll send the new VEX in the afternoon and more VEXes the next morning, if they learn about more non-exploitable vulnerabilities then.

This is why I said in this post that, once SBOMs start to be distributed widely, there will almost inevitably be “rivers of SBOMs and oceans of VEXes” – perhaps hundreds or thousands of VEXes for every SBOM that comes out. Remember, plenty of SBOMs have thousands or even tens of thousands of components. How many VEXes do you think there will need to be for every one of these SBOMs?

My “real-time VEX” API idea – which I’m happy to relate will be incorporated into a larger standard  proposal to the IETF by Steve Springett (co-leader of the OWASP CycloneDX and Dependency-Track projects) next year – is meant to mitigate this problem. It will be hugely more efficient for both suppliers and end users if an SBOM consumption tool can learn in real time whether or not a particular CVE is exploitable in a particular version of a product.

However, even with real-time VEX in place, there’s another problem that remains to be solved: Going back to our baseball analogy, suppose the scout – perhaps after having a few too many drinks one night – decides that Door Number 2 is the best way to identify the top 50 players, and they start eliminating players until there are only 50 left. Does that mean those 50 are all deserving of contracts? After all, the year these players were born (probably about 20-22 years before the current year) might have been a bad one for future baseball stars, and maybe there are only two current college players who deserve to sign a contract.

If our intrepid scout goes ahead and signs up the remaining 50 players and 48 of them turn out to be duds, do you think his scouting days might soon be over? Maybe he’ll make a career change to ball boy, if he’s lucky – or else hot dog vendor. By the same token, what will happen if the supplier decides, after they’ve put up real-time VEX notifications that 97% of vulnerabilities in a product aren’t exploitable, they put out a new notification saying the remaining 3% of component CVEs (which they’ll list) are exploitable? Yet, a month later, they have to admit that the real percentage of exploitable vulnerabilities is actually .02%, not 3.0%.  

Of course, if a customer took a chance and didn’t do anything after the original notification that said 3% of the vulnerabilities were exploitable, they may be happy, since their laziness paid off. However, if you were a customer who took the notification seriously and spent a weekend or two looking for a bunch of vulnerabilities that later turned out to be false positives, how happy would you be? Might you likely remove the supplier from your holiday card list? Or even worse?

What this problem reveals is it would be great if it were possible for a supplier to provide a truly secure notification to a customer about a set of exploitable component vulnerabilities (which of course the supplier hasn’t been able to patch yet. If they’d patched them, the vulnerabilities wouldn’t be exploitable after all). As I said, I don’t see how this would be possible if the only option for a notification were a document.  But when we’re talking about an API with authenticated access, there may be some ways to do this. In fact, I can think of several already, although it’s worth exploring a lot of options, since some will be less efficient than others.

Steve Springett (there aren’t too many posts these days in which I don’t mention his name at least a couple of times. I see no likelihood that will change very soon, thank goodness. He’s without much doubt the most creative and far-seeing person in the rapidly expanding SBOM world) said that he often gets asked on a podcast, “In ten years, where do you hope SBOMs will be?” He always answers, “I hope they won’t be needed at all.” Meaning, “The only reason we need to exchange machine-readable documents now is that we haven’t been creative enough yet, in figuring out how machines can exchange the information they need without any human intervention at all.”

The same goes for VEXes (in fact, much more so): Just as the best SBOM will be no SBOM, the best VEX document will be no VEX document. Just you wait!

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.