Thursday, January 13, 2022

The CycloneDX SBOM format, now with VEX appeal!


On Sunday, I put up a post in which I included this passage:

…CycloneDX isn’t standing still, either. That project will soon announce (I think imminently, but definitely by the end of January) its new v1.4, which will significantly enhance the vulnerability management capabilities in v1.3 – and I thought those were already pretty good. While I haven’t seen any specs for v1.4 yet, I know that one addition will be a VEX-like capability.

Even though I used the word “imminently”, I was still surprised when I received an email announcement on Wednesday from Patrick Dwyer, co-leader of the OWASP CycloneDX SBOM format project (with Steve Springett, who has the dubious distinction of being mentioned in four of my last five posts, including this one), announcing that CDX 1.4 is now available.

While Patrick’s email listed four or five new capabilities in CDX 1.4, the one he promoted the most was the fact that it includes a VEX capability, which is of course something that I’ve written a lot about. Patrick also mentioned the new SaaSBOM capability, which I think begins to address the biggest new challenge for the CISA SBOM community – properly identifying components of cloud software, as well as cloud-based components of locally-installed software (when the CISA-sponsored meetings start up in February, SaaS - i.e. cloud-based – components will be the entire focus of one of the four working groups, although there are also old challenges that still need to be addressed as well. Hopefully, they will be addressed by the other working groups. BTW, anyone is welcome to join those working groups. Drop an email to sbom@cisa.dhs.gov).

But since VEX is something I know about, and since Patrick made it the big focus of his announcement, I’d like to ask – and answer – the question, “Will the CDX 1.4 implementation of the VEX concept be very useful to organizations trying to manage risks that arise from components found in software they use?”

First I want to describe how I view the VEX concept:

1.      The idea for VEX arose a few years ago in discussions among participants in the NTIA Software Component Transparency Initiative, which is now under CISA. The participants realized that the majority – and perhaps the great majority, like 90% or more – of vulnerabilities that can be identified in software components (i.e. by looking up the component’s CPE name in the NVD) are in fact not exploitable in the product itself. In other words, if an attacker looks up a particular software product’s component vulnerabilities in the NVD and then tries to hack into the product by using them one-by-one, probably at most he’ll succeed one in ten times.

2.      That’s great news, right? Unfortunately, this is a good news/bad news situation, with the latter being more important. The flip side of the fact that at least 90% of software component vulnerabilities aren’t exploitable in the product itself is that, when the customer of a product discovers a component vulnerability in the NVD and contacts their supplier to ask when it will be patched, in at least nine cases out of ten, they will hear that no patch is needed, since the vulnerability isn’t exploitable in the product itself, often because of how the vulnerable component was implemented in the product. This will be a source of much frustration to customers and it will cause a lot of unneeded expense for software developers, since they’ll have to tie up some expensive software developers, explaining to hundreds of callers every day why they don’t have to worry about a particular vulnerability, even though it’s technically present in one component of their product.

3.      Because of this, many large suppliers (including at least a few who are actively participating in the SBOM Initiative) are holding back from releasing SBOMs to their customers, for fear their support lines will be overwhelmed with literally thousands of “false positive” calls like this. In my opinion, in order for those suppliers to start distributing SBOMs, they will need to be assured that there’s some way for them to get the word out to users, when a component vulnerability isn’t exploitable. One large supplier said in a VEX meeting that they thought they would get 2,000 false positive calls to their help lines, if they started distributing SBOMs without also distributing VEXes.

4.      The solution that was decided on a few years ago (and work started on the solution in the summer of 2020) was a document that would state that e.g. CVE-2022-12345 is not exploitable in product X version 2.4. Like the SBOM itself, the VEX would be machine-readable, and it would be distributed through the same channels as the SBOM – since in many if not most organizations, the staff members who need to see SBOMs will also need to see VEXes.

However, I use the word “see” loosely. SBOMs, and especially VEXes, were never meant to be human-readable, although even the explicitly machine-readable versions can be read by humans, with some understanding of what they say. But, given that some software products can contain literally thousands of components, there’s simply no way that machine readability can ever be optional. No non-machine-readable format will ever scale.

Now let’s discuss use cases for VEX, although we need to start with SBOMs. By far the largest use case for SBOMs is vulnerability management. Specifically, the customer wants to learn, for every component listed in an SBOM, what vulnerabilities are currently listed in the NVD for it. To do this, the customer needs a tool like Dependency Track, which I discussed in this post. D-T ingests a CycloneDX SBOM and identifies all vulnerabilities (CVEs) listed in the NVD for each component of the product. Moreover, it will keep updating that list as often, and for as long a period, as desired by the user.

That’s good, but the fact is that at least 90% of the vulnerabilities identified by D-T won’t actually be exploitable in the product itself. That’s where VEXes come in, but D-T doesn’t today ingest VEXes; and since the VEX format is about three months away from being finalized (even though some of us had thought it was finalized last summer), neither D-T nor any other tool can ingest it now. In other words, with Dependency Track or similar tools (including software composition analysis tools), you can see a list of component vulnerabilities applicable to a software product. However, you can’t see the much smaller, but much more useful, list of exploitable component vulnerabilities in the product.

Obviously, D-T won’t be able to ingest VEXes until the format is finalized, and I have no idea if VEX ingestion is planned or not.[i] But if we did have a tool that a) ingested SBOMs and VEXes, and b) output a list of exploitable component vulnerabilities in the product (hey, a guy can dream, can’t he?), how would it work? The important point about that tool is it needs to create a database. Even if it the tool just analyzes a single SBOM and identifies vulnerabilities applicable to components found in that SBOM, the fact is that VEXes that apply to that SBOM can appear at any time in the future. In fact, it’s very likely that, when the SBOM for a new product version is first released, there will be few VEXes that are applicable to the specific components that are called out in the SBOM. An SBOM is released at a point in time, whereas VEXes that apply to that SBOM (and sometimes to other SBOMs as well, usually for different versions of the same product) will dribble in over time.

This means that the tool will need to maintain a database that lists different versions of a product, each of which should have its own SBOM, since any change at all in the software requires a new SBOM. For each of those versions, the database should list the components (including version numbers) found in the SBOM, as well as any vulnerabilities found in the NVD for those components. Note that, even though the component vulnerabilities are of interest due to the fact that they apply to a component of the product, the vulnerabilities are “in” the product itself – since there’s in general no way that an attacker could attack just a component, not the whole product. Once the vulnerability has been identified in the NVD and linked to the product that contains the component, there’s no further reason to link the vulnerability with the component.

In other words, while it might be interesting to know which component is “responsible” for a particular vulnerability being present in a product, the only information that’s essential is the list of exploitable vulnerabilities in the product itself, regardless of which component they might apply to (or even whether they apply to any component at all. See items 2-7 in the list of VEX use cases below, none of which even mentions a component).

As I’ve described it so far, the database just lists vulnerabilities applicable to a product, not the much smaller (but much more useful) set of exploitable vulnerabilities. The latter set, a subset of the full vulnerability set, is arrived at by applying information retrieved from VEX documents to the lists. That is, if a VEX says that CVE-2022-12345 isn’t exploitable in Product A, then the tool will remove that CVE from the list. Even better, the tool will flag that CVE as not exploitable and put it in a separate list, but it won’t delete it from the database altogether. I’ll discuss why this is a good idea in a future post.

Thus, the database will maintain, for each version of each product in the database, a list of exploitable component vulnerabilities; that list might change every day (and for a product like the AWS client, which has 5600 components, it might change hourly). In theory, the user will be able to look in the database at any time to find the most up-to-date list of exploitable component vulnerabilities, for each product and version that they’ve stored in the database (which hopefully will correspond to every product and version currently in use in their environment – although that might not be possible for a while).

Now, let’s look at some use cases for VEXes. I’ve been participating in the NTIA/CISA VEX meetings since the second one in September 2020 and I’ve heard lots of discussion of use cases, so I’m not inventing any of these:

1.      The simplest use case is: A VEX states that CVE-2022-12345 is not exploitable in Product A version 2.4, even though it’s listed in the NVD as a vulnerability of  X, and X is a component of A v2.4.[ii]

2.      A VEX states that CVE-2022-12345 is not exploitable in versions 2.2 through 2.4 of X.

3.      A VEX states that CVE-2022-12345 is not exploitable in any current version of a family of products made by a particular manufacturer (e.g. routers made by Cisco™).

4.      A VEX states that CVE-2022-12345 is not exploitable in any current version of any product made by a particular software developer.

5.      A VEX states that CVE-2022-12345 is not exploitable in the current version of a software product, but it was exploitable in all previous versions after v1.5. In other words, the supplier has just patched a vulnerability that had been present in their product for a while, but which they didn’t know about until very recently (this is a very common scenario, BTW, since usually nobody knows about a vulnerability until it’s discovered by some researcher or software developer – or maybe by one of the bad guys, heaven forbid).

6.      A VEX states that CVE-2022-12345 is not exploitable in versions 2.0-2.7, 3.0-3.2, 3.8-4.1, and 5.9 of product X. It should be assumed to be exploitable in all other versions.

7.      A VEX states that none of the collection of vulnerabilities known as Ripple20 is exploitable in any of a supplier’s current product versions.

So here’s the big question: Which of these use cases would the VEX capability in CycloneDX 1.4 be able to address? As far as I can see, it only addresses the first case. I believe the CDX VEX is intended to refer to (or even be part of) a particular SBOM; this means it can refer to only one version of one product.[iii] Since all of the other use cases deal with multiple versions of one product or with multiple products, I don’t think the CDX 1.4 VEX capability can address them.

Note 1/14: After I put this post on LinkedIn, Steve Springett commented that in fact CDX 1.4 can do all of the use cases above. He posted some examples for me on GitHub, and we had a long Zoom call later on. He convinced me that CDX 1.4 can in fact serve all of these use cases. And for the different approach to SBOMs that I discuss in the paragraphs below, I think CDX 1.4 with VEX would be the right format to use.

While it is certainly valuable for CDX 1.4 to offer the capability it does, the VEX concept itself – as outlined by the NTIA in this one-page paper – encompasses all of the above use cases (some people think it should handle even more complex use cases, although I think the cases listed above are complex enough, thank you very much). Suppliers (who will be the primary entities preparing VEXes) will need to have another VEX solution along with CDX 1.4, if they want to address use cases 2-7 above (as well as others not listed).

But there’s one other point: If a supplier wants to convey information about vulnerabilities in their SBOMs (which is only possible in CycloneDX at the moment. SPDX doesn’t now have that capability, although I believe that SPDX 3.0 will, when that version is available), they have to keep in mind that they will need to update their SBOMs much more regularly than if they don’t include vulnerability information.

This is because applicable vulnerabilities change much more rapidly than do product components. A new SBOM should be issued whenever any code in the product has changed, and especially when there has been some change in a component. However, those changes will undoubtedly be far less frequent than changes in the vulnerabilities applicable to the product. As I mentioned above, a product that has thousands of components might literally require a new SBOM every hour, if the SBOM includes information on vulnerabilities. This is because it will need to be updated whenever a new component vulnerability has appeared in, or been removed from, the NVD – as well as in the VEX case, where a component vulnerability that appears in the NVD has been determined not to be exploitable.

Of course, pushing a new SBOM out to customers multiple times in a day, or even daily or every couple of days, will be a big chore, even if the whole process is ultimately fully automated. But there’s another way to make vulnerability information available to customers: the supplier can post SBOMS for all versions of all products online (in a portal with controlled access). Moreover, they can constantly look up component vulnerability information in the NVD and post that information with the SBOMs (whether or not the information is included inside the SBOMs themselves. I would recommend it not be, but I don’t think it will make a lot of difference either way). Finally, they can use VEX information (which of course comes from the supplier anyway) to remove vulnerabilities that aren’t exploitable from the list for each product.

In other words, the supplier can provide a constantly-updated list of exploitable product vulnerabilities online, without having to send a single SBOM or VEX to a customer (the SBOMs and VEXes will of course be available for download, for any customer that wants to check the supplier’s work in identifying vulnerabilities). And if they don’t want to do this themselves, I’m sure there will be third parties that can provide this service to their customers in their place – the supplier will just need to provide the SBOMs and VEXes to the third party.

In this post, I pointed out that it should be the supplier’s responsibility – or that of a third party service provider, either chosen by the supplier or by an end user organization - to develop and maintain a list of exploitable component vulnerabilities for each of their software products (and in every version of every product, at least those that are still being supported). I gave reasons for saying this in that post, but I didn’t emphasize the most important reason: that the lack of a consumer tool that will ingest SBOMs and VEXes and constantly list exploitable vulnerabilities in a product currently serves as a roadblock to SBOM adoption, let alone VEX adoption[iv]. If no tool is needed and this service is provided online by the supplier or a third party, the roadblock disappears.

To get back to CycloneDX 1.4, I think it’s a great product, and for certain lightweight VEX use cases it’s quite appropriate. But I think Patrick and Steve are making a mistake by emphasizing that capability so much. I suspect that 6-12 months from now, the SaaSBOM capability will be seen as the huge innovation at the heart of CDX 1.4, with the VEX capability being a nice-to-have but not the primary reason for users to adopt v1.4. The CDX team might want to imagine the use cases that SaaSBOM opens up and make those the heart of their efforts to promote the new version.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they necessarily shared by CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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] Since Dependency Track was originally created to help software developers identify vulnerabilities in components (dependencies) that they’re incorporating into their own products, the fact that VEX isn’t available doesn’t pose a big problem. Developers want to ship products that are vulnerability-free, period – whether or not the vulnerability is actually exploitable. Software buyers will form their opinions on a product based on the number of vulnerabilities they see for it in the NVD, and the supplier won’t usually be given the chance to explain non-exploitable vulnerabilities.

[ii] Note that there’s no need for the VEX to refer to a particular component, as we’ll see in a moment. A VEX is simply an assertion of whether or not a particular vulnerability is exploitable in a particular product/version, period.

[iii] I readily admit I could be wrong about this. There are two JSON examples on GitHub, which I’ll admit I only partially understood. So if I am wrong, I hope someone will correct me.

[iv] There are at least two other such roadblocks. All three would be bypassed and cease to be roadblocks, were my proposal to be adopted. 

No comments:

Post a Comment