Red Hat came out with their new
VEX format this week and described it in this blog post (Pete Allor of Red Hat also discussed it in today's OWASP SBOM Forum meeting). You might say that VEX is on a roll lately,
with Cisco having announced their VEX format in September. Also, Oracle is publishing
VEX documents, but I haven’t seen a description of their format yet. However,
it’s clear that all three of these formats differ from each other.
Is it a problem that they’re different
formats, all carrying the name VEX? There’s certainly no trademark on the VEX
name (any more than there’s a trademark on “SBOM”). Moreover, the only published
definition of VEX is in the CISA “VEX Use Cases” document. It reads, “A VEX
document is a binding of product information, vulnerability information, and
the relevant status details relating them.” In other words, any document that
mentions a product, a vulnerability, and the “status details relating them”
(with status being undefined, so it could mean almost anything) can be called a
VEX document. All these documents, as well as OpenVEX documents and probably
anything else that’s ever been called VEX, easily meet that low bar.
However, there’s a much higher bar
that needs to be met, and I know of no VEX format in use today that can clear it.
That bar includes three parts:
1.
There must be a
defined use case for the document, and it must be a machine-readable use
case. In other words, simply “providing information on vulnerabilities that
affect/don’t affect Product A” isn’t a machine-readable use case. If that’s
your goal, I can save you a lot of time and effort: You can enter that
information into a PDF document and email it to your customers. Only if the document
you produce is machine readable and intended to be utilized as part of a larger
automated use case – e.g., “allowing customers of Product A Version 2.3 to automatically
remove from their list of component vulnerabilities those that have been
determined by the supplier not to be exploitable in that product/version”[i] – is it worthwhile to
produce VEX documents.
2.
There must be a tightly-constrained
specification for the format; specifically, it needs to address only one use
case[ii]. Even if the VEX document
“sits on top of” a more general vulnerability reporting format like CSAF or
CycloneDX, that fact alone doesn’t constitute a specification (and by the way,
there will never be a single VEX specification applicable to all the different platforms
that currently form the base for documents called VEX – CSAF, CycloneDX, and OpenVEX.
They are just too diverse. For that matter, there is no single SBOM
specification that encompasses both CycloneDX and SPDX SBOMs; they are too
diverse as well).
3.
The specification
needs to be tightly enough constrained, that it will be possible to develop two
completely interoperable tools. The first is a VEX production tool that allows
a supplier to produce a VEX simply by asking a set of questions that can be
answered without prior knowledge of the format (e.g., “Which
vulnerability/vulnerabilities will be addressed in the document?”).[iii] The second is a VEX
consumption tool[iv]
that is limited to reading documents produced in the tightly constrained format
on which the production tool is based.
As I’ve already advertised, the OWASP SBOM Forum has formed a sub-group, now meeting
bi-weekly, that is going to produce a VEX format that meets all three of the
above criteria. Our first step is to produce a detailed use case for VEX, which
is in progress in this Google Doc. You are invited not only to review the
document, but to add comments or suggest changes. No permission is required to
do that.
We plan to finalize the use case
document within a few weeks and move on to developing the specification. Since
we have decided that a CSAF specification is more urgently needed, we will
develop that specification, and one of our members might develop prototype
tools to produce and consume VEX documents that follow that specification.
Then, we’ll start with the
specification based on the CycloneDX platform, and probably produce tools for
that format as well (since there are already lots of tools that produce and
consume documents using the base CycloneDX format – which underlies CDX SBOM
and a number of other BOMs, as well as VEX and VDR documents – and since we
will have learned a lot in developing the CSAF specification), we expect the
CDX VEX tools will be much easier to produce. In fact, there are already tools
that produce and read “VEX” documents based on the CDX platform, but none of
these are likely to follow the VEX specification we will develop.
What is the use case we will base
our VEX specifications on? I’ll be honest that I want it to be the one laid out
in the Google Doc, which can be summarized in this quotation from the only
document on VEX produced by the NTIA VEX working group:
The primary use cases for VEX are to provide users
(e.g., operators, developers, and services providers) additional information on
whether a product is impacted by a specific vulnerability in an included
component and, if affected, whether there are actions recommended to remediate.
Why do I want this use case?
Having attended most VEX working group meetings from the second meeting under
NTIA until recently, I can attest that this was the only use case even
discussed for at least the first year of the group’s existence. VEX was driven
by a few very large software (and device) suppliers that were quite concerned
that their help desks would be overwhelmed with calls from frantic customers,
once they started receiving SBOMs and looking up the components in the NVD.
The great majority of component
vulnerabilities they learn about will be false positives, meaning they only
affect the component if tested independently; they won’t affect the product
itself. The VEX will be ingested by a vulnerability management tool that first ingests
an SBOM and then guides the organization’s response to the vulnerabilities
identified through that SBOM. Ideally, the VEX will reduce that list to include
only exploitable vulnerabilities.
It will be years before there are
true end-user tools (licensed commercially so the user organization has just
one throat to choke when problems arise) for this purpose, but – as discussed
in the use case document – third party service providers should quickly arise
to address this use case. But that is unlikely to happen until there is a
single agreed-upon VEX specification, although with two variants (CSAF and
CycloneDX).
But there’s an even more important
reason for this to happen: As I’ve said many times before, there are a small
number of “showstopper” problems that are preventing SBOMs from being used to
any significant degree by organizations whose primary business isn’t software
development. I used to think the naming problem was the number one showstopper,
but more recently I’ve come to realize that VEX is number one. I’ve heard a
number of suppliers say that they won’t put out SBOMs to their customers with
any regularity, until they’re sure they’ll be able to identify for their
customers – in a machine-readable fashion – which of the component
vulnerabilities they learn about aren’t exploitable in the product itself, and
therefore can be safely ignored.
The existence of this tightly
constrained spec, as well as at least one service provider that is willing to
prototype the service described in the “VEX Use Cases” document, should be
enough to at least have a real proof of concept for production and utilization
of machine readable SBOM and VEX documents. at that point, it will be much more
possible to at least frame the remaining issues. Those issues will have much
more to do with practices and processes, not with technical specifications.
Since those issues will be much more amenable to being addressed through jointly
agreed upon guidelines, we should be able to make much more progress toward widespread
use of SBOMs themselves at that point. Perhaps there’s light at the end of the
tunnel after all!
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 lead the OWASP SBOM Forum. If you would like to learn more about what that group does, please go here.
[i]
This was the original use case for VEX under the NTIA. However, it was never
explicitly articulated, with the result that we find ourselves today in the situation
where VEX can be anything and is therefore nothing.
[ii] This isn’t to say there’s only one use case
for VEX; there are already a number of them. But it is to say that each of
those use cases needs to be addressed in a different specification, and therefore
using different tools. If that isn’t done, we immediately get into the
situation where it becomes impossible to develop tools, as described in this
post. I’m sure that in the future, there will be tools that can create or
consume multiple VEX formats; but it’s useless to concern ourselves with them now.
[iii]
This is especially important for VEX documents in CSAF, which has a
tremendously complex specification.
Very few software developers have the resources or time available to learn that
spec well enough to create documents on their own, and even fewer end users
could learn it well enough to create a useful consumption tool on their own.
[iv]
This will always be part of a larger tool, since, as already discussed, simply
reading the information in a VEX document doesn’t constitute a use case for
VEX. A PDF attached to an email is a much better way to address that use case.
No comments:
Post a Comment