I’ve wanted to have this talk with
you for a long time, but I’ll admit I’ve been putting it off. However, there
are some important things you need to know about VEX, and I’d rather you hear them from me than from someone
else (such as one of your friends):
1.
There are now two VEX
formats. They’re very different, although they have the same purpose. The first
is based on the new CSAF
version 2 vulnerability reporting standard from
OASIS (it uses a subset of the capabilities in that standard, called a profile).
The other is based on the
OWASP CycloneDX SBOM format, although any
SBOMs referred to in the VEX can be in either CycloneDX or SPDX format.
2.
There is no direct
connection between SBOMS and VEX documents. Even though the VEX format was developed
to address the issue of non-exploitable vulnerabilities identified using SBOMs,
the VEX itself doesn’t need to refer to an SBOM or to a component. The question
of the exploitability of a vulnerability, that is found in a particular
component, only applies to the product as a whole: Is the vulnerability
exploitable in the product or not?
3.
There’s no way to do a
direct translation between the two formats; by that I mean not only that there
aren’t translation tools, but that I don’t even see a good way to do a direct
translation, other than to extract the data from one format and create a new
VEX in the other.
4.
Currently, there
aren’t any automated tools to create VEXes[i] in either format. This
recently approved document from the CISA VEX committee provides links to JSON
code for various use cases, in both VEX formats.
5.
However, unlike with
SBOMs, where the format used should be a concern for end users, end users
really shouldn’t care in what format a VEX is provided, as long as the tool or
third-party service they are using to track vulnerabilities in software
components can interpret it. This is because a VEX document, even though it’s comprehensible
to a human who wants to invest some time learning about the format it’s written
in, will always be created with machine readability in mind.
6.
Suppliers are already
providing vulnerability notifications to their users in various ways now – in emailed
PDFs, website postings, etc. So, VEXes don’t give them a new capability (as
SBOMs do)[ii]. When suppliers start
providing VEXes, they’ll be expressly intended to be read by machines; the user
will seldom read a VEX themselves. If they do, it will probably be to satisfy
their curiosity about what the VEX looks like, not actually to absorb
information.
7.
And speaking of
machine readability, what tools or third party services are currently available
to utilize VEX documents? The tool will need to do more than ingest VEXes,
since VEXes alone won’t usually provide any useful information. Instead, a tool
will need to do all of the following:
a.
Ingest an SBOM about a
particular software product (or intelligent device) – say, product A - and
retrieve all the component information from it;
b.
Using the NVD or
another vulnerability database like OSS Index, create
a list of vulnerabilities currently applicable to components listed in the SBOM
for A;
c.
Ingest a VEX document
or documents that apply to A;
d.
Based on the
information in the VEX documents, remove from the list of vulnerabilities
applicable to A all vulnerabilities that aren’t exploitable in A; and
e.
Repeat this process
daily, if not more often.
8.
As VEXes are received,
the list will be whittled down so that it contains only exploitable vulnerabilities.
Thus, the user is much less likely to waste their time trying to identify and
patch non-exploitable vulnerabilities, than they would be if they didn’t
receive VEXes at all.
9.
Currently, there are
no tools or subscription-based third-party services that perform steps a. to e.
above. However, I know that the Dependency-Track
open source tool will soon be able to ingest CycloneDX VEXes (it can create
VEXes now, in the CycloneDX VEX format). Dependency-Track has for at least ten
years been able to read SBOMs (in the CycloneDX format) and look up
vulnerabilities in the NVD or OSS Index. It is now getting a huge
amount of use from developers who want to learn about vulnerabilities affecting
components in a software product they’re developing. The VEX ingestion
capability (which I’ve seen demonstrated) should be available soon.[iii]
10.
Even with the current
lack of tools for utilizing VEXes by end-users, I’m optimistic that the tools
and the VEXes will be available before long. This is because software suppliers
are the main drivers behind the VEX format. Two very large suppliers were the most
interested in getting work on the format started in 2020 and are still heavily
involved with that work today. Both of these suppliers – as well as many more –
are very concerned about the heavy load that will be placed on their help desks
if customers start calling in about the large number of vulnerabilities that
will be found in the NVD for components of their products. The customers will
naturally think of all these vulnerabilities as exploitable – when in fact only
a small percentage of them are. One of the two large suppliers said they
expected that producing VEXes along with SBOMs will end up saving them
thousands of false positive help desk calls every month.
11.
In this
post, I suggested that suppliers should take responsibility for a) looking up
components vulnerabilities in the NVD every day, and b) “whittling down” the
list of vulnerabilities so that only exploitable ones are left on it. This
would confer the added advantage that VEX documents would never have to be sent
outside the supplier (or outside the third party that the supplier engaged to
perform this work for them), and end users wouldn’t have to look up component
vulnerabilities themselves.
12.
If you think about it,
it’s somewhat silly that, if a supplier has for example 10,000 customers, every
one of those customers should have to look up the same components in the NVD
and get the same list of vulnerabilities, vs. the supplier just doing it once
for all of them. Following the five steps listed above, the supplier would provide
their customers a continually updated list of exploitable vulnerabilities in particular
versions of their product or device (whichever versions the customer is using).
I think this idea makes a lot of sense and will probably be realized one of these
days, just due to market pressures.
13.
Another thing I would
like to see happen is what I call “real-time
VEX”. These are simple VEX documents focused on only one product (although perhaps
multiple versions of that product), that simply list non-exploitable component
vulnerabilities in the product. Because they are so simple, the supplier would
put one out as soon as they discover that a particular component vulnerability
or vulnerabilities isn’t exploitable in the product. Receiving these right away
will allow end users to avoid what could be a lot of wasted effort looking for
vulnerabilities that simply aren’t there – as opposed to waiting a week or more
to receive that information.
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.
[i] By “automated tool for producing VEXes”, I mean a tool that will ask the user (typically a supplier producing a VEX for their product) the specific questions that need to be answered in a VEX, including “What is the product?” “What is the vulnerability?” “What is the status of that vulnerability in each of the versions that you wish to report on?” etc. With the answers to those questions, the tool will produce a VEX in one of the formats (CSAF-based or CycloneDX-based). I don’t think it will be hard to develop such tools (at least as far as one of the formats is concerned), and I’m sure some will be developed soon.
[ii] VEX was developed specifically to provide a “negative vulnerability notification”. The normal “positive” notification that we’ve all seen from software suppliers usually says something like “This vulnerability (CVE-2022-12345) is exploitable in our product. Please apply patch XYZ or upgrade to version XX.XX.” However, a negative notification essentially says, “This vulnerability is not exploitable in our product. You don’t have to do anything about it.” Negative notifications have always been an option, but they were not often needed until SBOMs started becoming available. However, since there’s agreement in the software community that a majority of vulnerabilities found in software components aren’t exploitable in the product itself, the advent of SBOMs suddenly created an immediate need for machine-readable negative notifications. Of course, both VEX formats can produce positive notifications as well.
[iii] Fairly
soon, there will also be a subscription-based third-party service that will ingest
both SBOMs and VEXes and provide users with a continually updated list of
exploitable component vulnerabilities in products of concern.
No comments:
Post a Comment