Where are we with VEX? For that matter, where are we with SBOMs?

Last week, Dale Peterson released a podcast based on his interview with Matt Wyckhouse of Finite State. They had a good discussion about the state (no pun intended) of SBOMs and VEX, especially in light of the “SBOM Challenge” at the recent S4 conference, in which Finite State participated.

Regarding the state of SBOMs, I think what Matt said was close to what I would have said: SBOMs have already proved wildly successful among developers (in large part due to the efforts of the NTIA Software Component Transparency Initiative, which was led by Allan Friedman). However, SBOMs are hardly being requested at all by end users (i.e. organizations whose primary business isn’t developing software. And yes, there are still at least a few of those organizations left. Software hasn’t quite “eaten the world”, much though it might seem like that to those of us who make our living in some realm related to software).

Of course, Dale already knew this, but what he said had struck him during the SBOM Challenge was that at least SBOMs are making progress. On the other hand, VEX hasn’t gotten anywhere today – either among developers or end users (I’ll admit I’m reading a little into what Dale said, but I don’t think I’m changing his meaning). VEX isn’t being widely used anywhere (while SBOMs are being heavily used in at least one industry that I know of: the German auto OEMs, who are receiving and acting on SBOMs provided by big component manufacturers like Bosch. But that use case is entirely based on open source license management concerns, not cybersecurity. Moreover, I think the methods used to facilitate this exchange might be challenged by the FTC in the US, as a possible violation of US antitrust law. So this use case probably couldn’t be replicated here).

In fact, it became clear during the Challenge that different parties – i.e., Idaho National Labs, which organized the Challenge, and the five or so participating vendors - had very different ideas about what constituted a VEX, and there wasn’t any clear documentation on which they could all rely. If that’s the situation (which it is), then VEX won’t be going anywhere until this problem is solved.

The worst part of this situation is that the lack of understanding of VEX doesn’t just inhibit distribution and use of VEX documents. IMHO, this lack of understanding is most likely one of the two main reasons why SBOMs themselves aren’t being distributed or used by non-developer organizations (I discussed this situation in this post and in the document linked in the post. Note that I think there’s a third problem holding back SBOMs – the lack of easy-to-use commercially-supported consumption tooling. However, that problem is itself mostly caused by the other two problems: VEXual ambiguity and the “naming problem” – so they need to be addressed first).

There was another statement I heard last week that was further indication that the lack of VEX clarity is holding back SBOMs themselves. In one of the CISA SBOM workgroup meetings, someone who works for one of the few largest software suppliers in the world, and who I believe is leading that supplier’s SBOM efforts, hinted that his organization was debating whether they could release SBOMs “without VEX” (of course, like some other major suppliers, that organization is willing to provide SBOMs for some products to customers who ask for them, but they’re not “distributing” them and certainly not doing that regularly – which is required for SBOMs to really be used, IMO),.

My guess is that a lot of software suppliers are debating the same question, and they’re all coming up with the same answer: Probably over 95% of component vulnerabilities, identified through parsing an SBOM and looking up the components in a vulnerability database like the NVD, aren’t exploitable in the product itself. This means that, if they release SBOMs without providing their customers with information (in a machine readable form, of course) that separates exploitable from non-exploitable component vulnerabilities, they will end up with a) a support meltdown, as customers jam the help lines and email by the thousands to demand the status of this or that non-exploitable component vulnerability, and b) a lot of unhappy customers, who don’t appreciate being allowed to spend hours chasing down false positive vulnerabilities, only to be told later that they needn’t have bothered.

As I’ve said before, “No VEXes, no SBOMs (at least, SBOMs distributed to end users).” We have to figure out a) what the problem or problems are that need to be addressed, regarding false positive component vulnerability notifications, then b) how they can be addressed (it’s fairly clear by now that simply drawing up specs for VEX documents and congratulating ourselves on the great progress we’re making isn’t the answer to our problems).

In the near future, I plan to put up a high-level post outlining my ideas on this topic, although I’ve stated most of them in some form or other in past posts. A detailed discussion of this topic needs a book.

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.