The OWASP SBOM Forum was
formed in early 2022 for the purpose of exploring the reasons why software
bills of material are not being used in any significant way among public and
private organizations whose primary activity is not software development (they’re
being heavily used by software companies, as well as by the software
development arms of other companies; moreover, the rate at which they’re being
adopted by those organizations is accelerating).
Early on, we identified the two
most important reasons for this situation: the naming problem and uncertainty
around VEX. More than a year ago, we put out a paper
that set out our position on the biggest component (no pun intended) of the
naming problem: how to move the NVD beyond the many issues that make it
difficult to find a CPE name for a software component listed in an SBOM. We
continue to discuss this issue.
This fall, we decided to tackle
the issue with VEX:
1.
The concept of VEX
(which stands for Vulnerability Exploitability Exchange) was developed by the
NTIA Software Component Transparency Initiative in 2020 to address a specific
use case. That use case was described this way in the only document
on VEX published by the NTIA: “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. In many cases, a vulnerability in an upstream component will not be
“exploitable” in the final product for various reasons (e.g., the affected code
is not loaded by the compiler, or some inline protections exist elsewhere in
the software).”
2.
After the SBOM effort
moved under CISA in 2022, many more use cases for VEX were entertained by the
VEX working group. In fact, the only definition published by the CISA VEX group
(in this
document on page 2) is “A VEX document is a binding of product information,
vulnerability information, and the relevant status details relating them.” In
other words, any document that ties vulnerabilities to products in any way is a
VEX. Of course, this includes any vulnerability notification ever issued,
machine readable or not, as well as any vulnerability notification that will
ever be issued.
Leaving aside the question of what
value there is in having such a broad definition, what we noticed was that this
makes it impossible to have a consumer tool that can even parse a VEX document,
let alone utilize the information from the document to advance an organization’s
software vulnerability management efforts. The developer would need to address
a huge (approaching astronomical)
number of use cases, variations on those use cases, and combinations of all the
use cases and variations; no developer is interested in devoting the rest of their
life to developing a single product, no matter how needed. To quote Frederick
the Great, “He who protects everything protects nothing.”
Once you state the problem this
way, the solution becomes clear: Focus on just one use case and develop a specification
that can be used to design proof of concept tooling for both production and
consumption of documents based on that use case. Then build and test the tools,
to make sure the production tooling can build documents that will always be
readable by the consumption tooling, and that the consumption tooling will be
able to read any document produced by the production tooling.
Even though there are a few tools
that purport to produce or consume “VEX documents” today, there are certainly
none that meet the above test. Once the initial use case has been addressed in
this way, it will be possible to repeat that effort for other use cases. This follows
the sage advice embodied in the answer to the question of how to eat an elephant:
One bite at a time.
For the first VEX use case we’ll
address, we chose the one we think is by far the most important: notifying software
users that certain component vulnerabilities they may have discovered by
running the supplier’s most recent SBOM through a tool like Dependency Track or
Daggerboard are not exploitable in the product, even though they’re exploitable
in the component considered as a standalone product. This means they pose no
danger to the user organization. The fact that there is currently no completely
automated way to provide this information to users is inhibiting many suppliers
from producing SBOMs at all.
If it were sufficient just to put
the VEX information in a PDF and email it to their customers, there would be no
need for a supplier to provide the information in a machine readable document. However,
given that trying to manage component vulnerabilities “by hand” – e.g., by
using spreadsheets – would quickly turn into a nightmare, and that SBOMs
themselves are machine readable, the VEX must be machine readable as well.
However, that’s hardly all that’s
required. The information from the VEX document must be utilized as part of an
automated toolchain that a) starts with ingesting an SBOM and looking up component
vulnerabilities like Dependency Track does, b) continuously updates the
exploitability status of the component vulnerabilities as new VEX documents are
received, and c) on request from the user, provides a recently (at least daily)
updated list of the exploitable component vulnerabilities in a format needed to
ingest the list into a vulnerability or patch management tool.
Currently no such tools or toolchains
exist, and it will be years before they’ll exist in a form that can be utilized
by an end user organization. This is probably due to the need to work around
the naming problem and some other issues (suppliers producing SBOMs work around
these issues every day. They have to). However, we’re sure that third party
service providers will become interested in operating one of these tools as a
service to end users, who will just download the data provided in step c) above
and not have to worry about steps a) and b) at all.
These service providers will need to
benefit from full automation of the above three steps; otherwise, they might
not be profitable. This is why having a standard, constrained VEX format is so
important; only if VEXes are produced in that exact format, and the consumption
tool can be built to expect that format and no other, will it be possible to
have true automation.
But standardizing the format alone
isn’t enough. The processes followed by the supplier need to be strictly
constrained as well. For example, many or most of the components found in an
SBOM produced by fully automatic means will probably not have a CPE or purl
identifier, yet at the same time, no major vulnerability database is based on any
other type of software identifier. This means the supplier should include a CPE
or purl for every component listed in the SBOM.
However, that is easier said than
done, since in many cases it will not be possible to locate a CPE for a
proprietary component[i]. What should the supplier
do when they can’t find a CPE for a proprietary component? Should they leave
the component out of the SBOM altogether? Should they leave it in, but enter “not
available” as the identifier? Should they simply enter whatever identifier they
have for the component, in the hope that a user who’s really concerned about looking
up vulnerabilities for every component will at least have something to search
on?
All three of those answers would
probably be acceptable, at least for certain users. There are other questions
like this as well. However, we need to answer each of those questions in some
way, if we want to make production and consumption of VEX documents a
completely automated process.
This is where Henry Ford comes in.
In 1908, after having produced fancier (and non-standardized) automobiles for
five years, he dropped all previous models and introduced
the Model T, a “simple, inexpensive car most people could own.” Initially, the
Model T was available in multiple colors. However, in 1914 he introduced a huge
gain in efficiency by going to a moving production line. One tradeoff for that
was he needed to limit the color options to one (to avoid having to clean the
line between producing models with different colors).
In his autobiography published in
1922, he quoted himself as having said in an internal meeting, “Any customer
can have a car painted any color that he wants so long as it is black.” There’s
no way to prove he actually said that, but the lesson is clear: Automating a
process often requires making a seemingly arbitrary choice among equally valid
options. You need to stop deliberating and simply Choose One.
That’s how our group can achieve
its goal of designing tooling for a completely automated process of delivering
and utilizing both SBOMs and VEX documents. While there are many options available
for both types of documents (in terms of use cases and variants on those use cases),
we need to Choose One and move forward.
It's time to bring SBOM production
and usage into the Model T era!
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 join or contribute to our group, please go here, or email me with any questions.
[i] Because
purl doesn’t
require a central database, the supplier should usually be able to create a
purl for an open source component.
No comments:
Post a Comment