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