Will VEX go both ways?

 

Probably the person I have learned the most from with regard to SBOMs is Steve Springett, chair of the OWASP CycloneDX working group, leader of the OWASP Dependency-Track project, and leader of the OWASP Software Component Verification Standard (SVCS) project (BTW, he has a day job as well!).

Steve is someone who is always far ahead of the “conventional wisdom”. One illustration of this is the fact that he developed Dependency-Track, which is a tool that ingests SBOMs (actually, BOMs in general) and identifies and tracks vulnerabilities applicable to components. And he did it in 2012, years before the term “software bill of materials” was invented, and especially before the idea became prevalent of using SBOMs for vulnerability management purposes.

Another illustration is something that happened this week. I’ve been corresponding with Steve by email regularly (he lives only about ten miles from me in suburban Chicago, and I’ve suggested we have lunch sometime. He said he’d be glad to do that when there’s a restaurant with outdoor seating where we can meet. However, for some reason I haven’t been able to find a restaurant in Chicago that offers outdoor seating in January or February. I’ll keep looking, though!).

Steve and I were corresponding on the subject of VEX in CycloneDX and Dependency-Track, when he wrote, “I’m troubled by the one-way nature of how VEX is positioned. The word ‘exchange’ means that two parties both give something and receive something. The case you’re framing is a simple one-way transfer, which may be useful, but will not work in the real world.”

This hit me like a bolt from out of the blue, since I’ve always thought of VEXes (and SBOMs, too) as one-way documents. They’re issued by a supplier (or perhaps another party) and provided to their customers. The VEX’s purpose is to tell the customer the status of a vulnerability (i.e. whether or not the vulnerability is exploitable in the product itself, not just in one of the components when considered as a standalone product) in one or more versions of one or more of the supplier’s products. And I’m not alone in believing that VEXes are only one-way documents. I’ve attended most of the VEX meetings (formerly under the NTIA and now under CISA) since their inception in September 2020, and I’ve never once heard any discussion of the VEX as anything but a one-way document.

So what did Steve mean by two-way transfer of VEXes? He continued, “Having spent most of my life working for software companies, I can tell you with absolute certainly that customers report issues all the time. Sometimes they’re for previously unknown vulnerabilities or they prove that a third-party library that was thought not to be exploitable, actually is. Many customers have internal teams that conduct offensive engagements, or they work with consultancies that perform the engagements for them, or software companies work with bug bounty firms like HackerOne.”

What Steve has in mind is customers creating VEXes that state a particular vulnerability is exploitable or not exploitable in a particular product. Of course, they do this both for the supplier’s and their own benefit, so the supplier will patch exploitable vulnerabilities they weren’t previously aware of.

Note that the activity – a customer reporting the exploitability status of a vulnerability to a supplier – is something that software customers are already doing. What would be innovative about Steve’s approach is that the customer would be able to deliver the “report” in a machine-readable format, which is in fact the same format that the supplier uses to report status of vulnerabilities to the customer.

Who will be the main beneficiary of this two-way communication? The customer will benefit, since two-way VEXes will make it easier for them to report an exploitable vulnerability to a supplier, once they get the hang of creating VEXes themselves. Now, the report could be created entirely by an automated process, instead of having to spend time explaining it to someone in tech support on the phone or in an email.

But two-way VEXes will make life a lot easier for the supplier, since getting a vulnerability report from a customer won’t require the help desk staff to spend a long time on the phone with the customer, then transcribe what they just learned into the supplier’s internal vulnerability management system. Since the supplier will already be familiar with the CycloneDX VEX format, they will be able to link that to their internal system, so that future VEX reports from customers can flow directly into the system.

But once we have two-way VEXes in place (and it sounds like doing that will just require some simple tooling on both the customer and supplier sides), are there any other processes that might be automated by this as well? Maybe even new ones we hadn’t considered before?

Coincidentally, earlier on Monday I had heard of a vulnerability management communication that would be very helpful, both to end users and suppliers. But since there’s currently no way now to do this communication cost-effectively, it simply isn’t being done at all – in fact, I hadn’t even thought of this communication at all until another person (who is very knowledgeable about SBOMs and communication channels) suggested it to me.

To understand this type of communication, think about the main use case for a VEX: A supplier tells a customer that a particular vulnerability – which is listed in the NVD as applicable to a component of a supplier’s product - isn’t in fact exploitable in their product. The reason the supplier should tell the customer that a vulnerability isn’t exploitable is that, by doing so, they’ll save both themselves and the customer a huge amount of wasted time and effort. The customer won’t waste time bugging the supplier about when they’ll patch a non-exploitable component vulnerability, and the supplier’s help desk won’t waste a lot of time talking to customers about those vulnerabilities.

The reason this is a big deal is that almost without doubt the great majority of software component vulnerabilities aren’t exploitable in the product itself – in fact, that number could be around 95%. In other words, if a customer called their supplier about 100 vulnerabilities identified in components of a product in the NVD, 95 of those calls would be a waste of both the customer’s and the supplier’s time.

However, for a VEX to work best and save the most time and money, it needs to be sent as soon as the non-exploitability is discovered – i.e. the same day. If that isn’t done, then both the supplier and the consumer are likely to waste significant amounts of time dealing with false positive product vulnerabilities.

If the need for the supplier to communicate that a component isn’t exploitable to their customers didn’t occur very often, it wouldn’t be hard to send a VEX to every customer very soon after the non-exploitability was discovered, so not much time would be wasted.

But consider the case of a supplier that has ten products, each with thousands of components (as in one of the examples in my previous post). The supplier might well discover multiple non-exploitable component vulnerabilities every hour of the day. Rather than be constantly sending VEXes out to their entire customer base multiple times an hour, they may aggregate these notices into one VEX every day or even every week.

The problem is that, when a customer discovers a component vulnerability in the NVD but hasn’t seen a VEX saying it’s not exploitable, they will need to assume that the vulnerability is exploitable. So even if a VEX arrives a few days later saying it’s not exploitable, the customer may already have wasted a lot of their and the supplier’s time, under the assumption that it is.

Wouldn’t it be nice if, upon discovering a component vulnerability in the NVD, a customer could immediately query the supplier about whether or not it’s exploitable and get an immediate answer – with no human involvement required on either end? Given that the customer might use hundreds of products with collectively tens or hundreds of thousands of components, this would enable them to learn right away about the exploitability status of every component vulnerability they discover in the NVD (or another vulnerability database, of course). Currently, they simply can’t do this. 

I think Steve's two-way VEXes could enable this problem to be solved as well, possibly introducing a lot of new efficiency into the software vulnerability management process, for both customers and suppliers of software.

So Steve has given us another gift, which will probably enable a whole cottage industry and make some people – if not rich – at least fully employed for a lifetime. Not bad for a day’s work.

By the way, would you like to know the technical name for this bi-directional VEX capability?...I didn’t think so, but I’ll tell you anyway: it’s biVEXuality. Catchy, no?

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.