The CISA SBOM “listening sessions” kicked off this week, and they were all good – and very well attended. There are still two more next week, so you might want to check them out, if you’re at all interested in SBOMs. No registration is required, and you can get the times and connection information here.
One thing that struck me during
the conversations is how many people spoke very knowledgably about VEX
documents – and had completely the wrong idea about them. They were not only
wrong, but they were 180 degrees wrong.
However, I don’t blame them for
this. Until a few months ago, the only official publication on VEX was a
one-page document published by the NTIA last fall. Having prepared the first
draft of that document, I thought it was very good, but it’s now very much out
of date and shouldn’t be relied on. There are now two good documents – one of
which came out yesterday – that are useful for particular topics, but neither
one constitutes a comprehensive introduction to VEX and how VEX documents can
be produced and used. The two documents are both available at the first link
above. I also have produced a number of posts on VEX, which you can find by searching
on the term in the search bar at the top left.
The problem with what these people
said is that they think VEX is a vulnerability report – a list of
vulnerabilities that apply to components found in an SBOM, or maybe
vulnerabilities in the product itself. What’s confusing is that a VEX can be
exactly that. It can say (in JSON), “This component included in product X
version Y is affected by CVE-2022-12345.” Or perhaps, “Product X version Y
itself is affected by CVE-2022-12345.” Given the dearth of official information
on VEX, it is quite understandable that people think this must be the purpose
of a VEX. After all, they’re used to receiving notifications like that from
their software suppliers now.
However, if that were the purpose
of VEX, there would have been no need to invent the format (actually “formats”,
since there are two, although they’re very different from each other). Yes, VEX
is machine readable, and most of us are only used to seeing human readable
vulnerability notifications in the form of emailed PDFs or web page notices.
But machine-readable vulnerability notifications have been around for at least
seven years. In fact, one of the two VEX formats is based on the CSAF
vulnerability reporting format, which gives the supplier a huge range of
options for reporting vulnerabilities. However, that VEX format itself just
utilizes a small percentage of the available fields in CSAF. If your aim is to
make the type of vulnerability reports that you’re used to seeing in PDFs, you
would be much better off using the full set of CSAF fields, not the VEX subset.
VEX was developed because there
was a need for a machine-readable format that said the exact opposite of what a
traditional vulnerability report says. Instead of saying, “Product X version Y
is affected by CVE-2022-12345”, a VEX says “Product X version Y is not affected
by CVE-2022-12345”. At first glance, that might seem like a strange thing to
say. After all, there are already more than 20,000 CVEs in the CVE database,
and more are added all the time. Assuming a product is currently affected by
ten vulnerabilities, does that mean the supplier needs to put out both a
traditional notification that the product is affected by those ten CVEs, and t
a VEX that lists the 19,990+ vulnerabilities it’s not affected by?
Fortunately, that’s not what VEX
was developed for. VEX was developed to deal with the problem that, when you
receive an SBOM and look up (in the NVD or another vulnerability database) the
vulnerabilities applicable to the components, for every 20 vulnerabilities you
identify, usually 18 or 19 of them (maybe 20 in some cases) will not be
exploitable[i] in the product – meaning you
wouldn’t find those vulnerabilities if you scanned the product with a
vulnerability scanner, and a hacker wouldn’t be able to utilize them to attack
the product. You don’t have to take any further action regarding the
non-exploitable vulnerabilities.
Now you probably think I’m crazy
(and there would be some merit to that diagnosis, I’ll admit). Why is it a “problem”
if it turns out that 19 out of every 20 vulnerabilities identified in components
of a product aren’t exploitable in the product itself? After all, you’ve just
reduced your vulnerability management workload to 5% of what it would have been
otherwise.
It’s a problem because, after you find
those vulnerabilities in the NVD, you have no way of knowing which are one of
the 19 non-exploitable vulnerabilities, and which is the exploitable one. You
need to look for all of them on your network and then you need to call up and interrogate
your supplier’s help desk staff about when they’re going to fix all 20
vulnerabilities.
But if you do harass the supplier
about all 20 CVEs, the tired help desk person is going to tell you, for 19 of
them, “Yes, I understand that CVE applies to component A in our product, but
actually – as I’ve already told 245 people today – the CVE isn’t exploitable in
the product, so you don’t need to worry about it anymore.
And then you’ll feel like an idiot,
both for wasting the help desk person’s time and, most importantly, wasting
your own time. Wouldn’t it be great if you could have learned about the
non-exploitable vulnerabilities before you started pursuing them?
This is the problem that VEX was
invented to solve. After you receive an SBOM, you’ll receive VEXes as the
supplier realizes that certain vulnerabilities aren’t exploitable in their
product, even though they are listed in the NVD for a component of the product.
You will sleep better at night and the supplier will sleep much better, knowing
they don’t have to hire another 50 help desk people to handle all the calls
about vulnerabilities that turn out to be non-exploitable (in fact, one of the two
huge suppliers that sparked the development of VEX in 2020 estimated that they
would get thousands of false positive help desk calls for exactly this reason,
if there weren’t some way of notifying users about non-exploitable vulnerabilities).
Of course, VEXes can be used to
create positive vulnerability notifications as well – i.e., “normal” ones. And
there are uses for positive notifications in VEX, usually in combination with
negative notifications. For example, when a supplier has patched a serious
vulnerability and wants to let their customers know about the status of the
vulnerability in all versions of their product – i.e. whether each version is vulnerable
or not vulnerable - they can issue a VEX that provides all this information in
one place, in a machine-readable format. This post
discusses that use case.
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