Wednesday, August 10, 2022

What’s the best SBOM? No SBOM. What’s the best VEX? No VEX.


Steve Springett, leader of the OWASP CycloneDX and Dependency-Track projects (as well as the SCVS project, which I haven’t written about previously but is also important for software security in general and SBOMs in particular), and I attend a weekly meeting where we and others discuss problems that are holding back widespread distribution and use of SBOMs. We’ve been working for five months on the naming problem, and will soon publish our proposed close-to-solution to the problem (plus, we’re getting the different parts in motion to implement that solution, although ultimately we can only present our case to the people who need to make it happen).

At last week’s meeting, Steve asked what we would tackle next (assuming we want to tackle anything next, but there’s no question that we want to do that. There are still some serious problems that need to be addressed before SBOMs can be widely used. No rest for the weary - although I find this quite interesting and invigorating).

I suggested an idea I brought up in a post a while ago (which was also based on something Steve said. No coincidence, there – BTW, what I’m talking about here appeared at the end of that post), which I call “real-time VEX”. IMHO, the idea is quite simple:

1.      Because about 90-95% of vulnerabilities in software components aren’t exploitable in the product itself, end users are going to be reluctant to utilize SBOMs for vulnerability management purposes (probably the most important security use case for SBOMs, although there are other use cases as well), unless they can be assured that they’re not spending 95% of their time chasing false positive vulnerability identifications.

2.      About two years ago, a working group within the NTIA Software Component Transparency Initiative started work on a format for documents that would allow a supplier (or perhaps another party) to notify customers that vulnerability CVE-2022-12345 isn’t exploitable in their Product X Version Y, even though the NVD shows the CVE is found in Component A, which is included in X.

3.      The name VEX was chosen (or more accurately, stumbled into) for the document; then the words “Vulnerability Exploitability Exchange” were identified as a good enough explanation of what VEX stands for (people never like it if you tell them that an acronym stands for NBI, Nothing but Initials, but that often happens. In fact, “CVE” is officially NBI now, even though it did stand for something initially).

4.      Now there are two standards for creating VEX documents: one based on CycloneDX and the other based on the OASIS CSAF vulnerability reporting standard. However, no software supplier is currently providing VEX documents to their customers, except perhaps in one or two isolated cases. The biggest reason for this is that – even more than SBOM – VEXes need to be consumed by automated tools. There is currently only one tool that consumes SBOMs and VEXes, which is Dependency-Track (I believe there will be one or two third-party services available in the near future, that will also do this). Another important reason why VEX isn’t exactly taking the world by storm is that there is no playbook currently available that describes how to create and consume VEXes (although the CISA VEX committee is starting work on one now).

5.      The big problem with the fact that VEX isn’t taking off is that this inhibits interest in SBOMs as well, for the simple reason that people don’t like the idea of wasting 95% of their time looking for vulnerabilities that aren’t there. Given that they can’t be sure that won’t happen if they start looking for vulnerabilities in components of a product, they aren’t very interested in SBOMs or VEXes.

I thought until recently that a good bit of education would help suppliers and consumers of software become comfortable with VEXes. That is coming and will help, but there’s another problem: While an SBOM will have to be produced whenever the software changes (including patches and new builds), VEXes will need to come out in much greater numbers, in order for users to be assured that the list of vulnerabilities that their SBOM/VEX tool shows them, for a particular product and version, consists mostly of exploitable vulnerabilities that are worth pursuing, rather than non-exploitable vulnerabilities that aren’t. As I discussed in this post, a large company would probably need to receive literally thousands of VEX documents every day (if not every hour), in order to reach the goal of narrowing down the component vulnerabilities that they take seriously, to only the exploitable ones.

The problem is made even worse by the fact that there is real urgency with VEXes (even more so than with SBOMs). Most users will want to know as soon as possible which component vulnerabilities aren’t exploitable, especially if these are serious vulnerabilities. If a supplier learns that a serious component vulnerability isn’t exploitable in one of their products, their users aren’t going to react favorably if the supplier waits until the end of the month, when they aggregate all of their VEX notices in one document; it’s likely that users will already have wasted a lot of time looking for that vulnerability in the product. In fact, the users probably won’t be satisfied if they hear the supplier issues a VEX once a week, or even once a day. They will want to know as soon as the supplier decides that a vulnerability isn’t exploitable.

But here’s the problem with that: Until there are automated tools to produce VEXes (and currently there are none, in either format), putting out a VEX is going to require a non-trivial amount of time. In fact, people are going to need to produce VEXes day and night, in order to keep up with demand (I believe the term for these people is “VEX workers”). My guess is that anybody with that job will either quit or commit suicide within months.

However, when I wrote the post I referred to earlier, I had just come to realize that there may be a solution to our problems. We don’t need a VEX (or any other document) for the primary VEX use case: informing users of non-exploitable component vulnerabilities found in products they use. Instead, we need:

1.      A “VEX server” at the supplier (or at a third party that offers this as a service on behalf of the supplier) will list, for each currently-used version of software products (or intelligent devices) produced by the supplier, all of the component vulnerabilities currently shown in the National Vulnerability Database (NVD), as well as perhaps other databases like OSS Index (which is better for open source components, I’m told). The components behind each list will be those in the SBOM for that version (since every change in the software should produce a new version as well as a new SBOM, there should always only be one SBOM for each version).      

      The VEX server will continually search the vuln databases for new vulnerabilities for each product and version (if this sounds like a lot of work, consider that Dependency-Track is now being used 200 million times a month to search OSS Index for vulnerabilities applicable to open source components – and that works out to about 20 billion SBOM-based vulnerability searches a month, just with that one open source product. Also, consider that security-conscious suppliers should already be continually searching for new component vulnerabilities in their products. They should already have this information), and continually update these lists.

2.      As the supplier identifies a component vulnerability that isn’t exploitable in a particular version of their product, they will set a “not exploitable” flag for that vulnerability, product, and version in the VEX server.

3.      Meanwhile, end users (or a third party performing this service on their behalf) will operate software tools that track all vulnerabilities listed for components of any software product/version used by their organization.  Whenever they identify a component vulnerability in the NVD, they will add it to a list (rather, their tool will do this) of vulnerabilities for the product/version (this list might be included in a vulnerability or configuration management database). Each vulnerability will initially be assumed to be exploitable (there is no other choice, if you think about it).

4.      There will be an API that can be called, as often as required, by software operated by end users (such as Dependency-Track), or by a third party acting on behalf of users. It will send three pieces of information to the appropriate server:

a.      Product name (Product A)

b.      Product version string (Version X.Y.Z)

c.      CVE number (CVE-2022-12345)

5.      These three pieces of information will be interpreted by the VEX server to mean, “What is the exploitability status of CVE-2022-12345 in Product A Version X.Y.Z?”

6.      The server will return one of two pieces of information in response:

a.      Not exploitable

b.      Under investigation

7.      If the answer is a, the user tool will flag CVE-2022-12345 as not exploitable in Product A Version X.Y.Z. If the answer is b, the tool will do nothing, and the CVE will continue to be listed as exploitable.

8.      It will be worthwhile for the user tool to use the API to query the VEX Server at least once a day, and more often if possible. This way, the list of exploitable component vulnerabilities will, at any particular time on any day, contain only the vulnerabilities that the supplier has not yet decided are not exploitable (note that I don't think the API should optionally return a third piece of information "Exploitable". Unless there's a patch available for the CVE in question - and it's been advertised to all customers of the product - that would be a dangerous thing to do).

Of course, there will always be some vulnerabilities that are currently listed as exploitable, that will later be found not to be so. Thus, the vulnerability management staff will still waste some time looking for non-exploitable vulnerabilities in the products the organization uses. However, they will at least know that the list they have reflects the supplier’s most current knowledge.

Note there are still a number of VEX use cases that need to be handled with a VEX document, for example a “positive” vulnerability announcement (e.g. “Product A Version B is vulnerable to CVE-2022-YYYYY and the patch is available at (URL)”), or a more complex scenario like patching a longstanding vulnerability in the product. But IMHO the most time-critical and high-volume use case, can be handled much more efficiently by “real-time VEX”.

To continue my story, when I’d described my idea in the meeting (in much less detail than above), Steve pointed out that he’s sometimes asked in interviews where he thinks SBOMs will be in ten years. He always says, “I hope they won’t be needed at all.” He went on to explain what he meant (I’m paraphrasing him): "What really matters is if the supplier (or a third party) has the data the consumer needs when they need it. If that can be exchanged purely using APIs, that’s great. We don’t need either SBOMs or VEXes.”

While I agree with Steve that the goal is not to need either SBOMs or VEXes, I think the low-hanging fruit at the moment is what I’ve just described. This may be one thing (along with solving the naming problem and the availability of user tools and third-party services) that opens the floodgates for use of SBOMs and VEXes for software vulnerability management. 

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.

 

No comments:

Post a Comment