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