As I made clear in this recent post, I no longer think it makes any sense for the
end user of a software product or intelligent device to bear the responsibility
for analyzing SBOM and VEX information to identify exploitable component
vulnerabilities in a product they use. Instead, the supplier should bear this
responsibility for five main reasons:
1.
The supplier chose to
include the components in the product. They did this because utilizing
pre-built components is now the only realistic way to create software, due to
the huge savings of money and developer time that result from this practice. While
some of the economic benefits of using components accrue to the end users of
software because of the overall lower level of software prices that results
from this widespread practice, it is hard to deny (at least for me) that the
greater part of the benefits of using components accrues to the supplier. This
is due to the savings that developers realize through accelerated development
time and lower overall development costs.
2.
Currently, there are
no tools available to software end users (which I define as consumers of
software that are not utilizing the software they acquire to create downstream
products, but instead utilize it to fulfill the mission of their organization)
that are a) free or low-cost, b) commercially supported, c) easy to use, and d)
complete[i]. By a “complete” tool, I
mean one that:
i.
Ingests an SBOM for a
particular software product and version, for example version 1.5 of product ABC;
ii.
Resolves any component
naming issues, meaning it identifies a valid CPE or purl
identifier for every component listed in the SBOM. Learning just the common
name for a component is close to useless for a user concerned about component
vulnerabilities in the software they use. Identifying a valid CPE for a component
requires manual searching, fuzzy logic, dumb luck, etc. Identifying a purl for
an open source component should be straightforward if the repository or package
manager is known, along with the product name and version string registered in
that repository. However, these should always be verified by the product supplier
before including them in an SBOM);
iii.
Looks up each component
CPE or purl in a vulnerability database like the NVD or OSS Index
and includes every identified component vulnerability in a list of vulnerabilities
found in ABC v1.5. Each vulnerability on the list is initially assigned an
exploitability status of “under investigation”;
iv.
Repeats these lookups
at least daily, adding any newly identified component vulnerabilities to the
list with the “under investigation” status;
v.
Receives VEX
information from a supplier, either in the form of machine-readable documents
or using an API that retrieves the information from a VEX server. VEX information consists of a) exploitability status for
every vulnerability in the list for ABC v1.5 (“affected”, “not affected”,
“fixed” or “under investigation”), b) a status
justification for every “not affected” status
designation, and c) mitigation information (e.g. patch or upgrade information)
for every “affected” status designation;
vi.
Continually uses new
VEX information to update the vulnerability list for ABC v1.5;
vii.
On demand from the
user of the tool, provides a list of exploitable component vulnerabilities
(i.e., those with “affected” status) in ABC v1.5, as well as mitigation
information for each one (which is also retrieved from the VEX server)[ii]. The list can be provided
in either a generic format or in a format required by a particular
vulnerability or configuration management tool; and
viii.
Continues this process
for ABC v1.5 until the user upgrades or removes the product from their network.
If the user upgrades to ABC v1.6, the process will start over with step 1 above.
If the user still has any instances of ABC v1.5 running, the tool will maintain
the component vulnerability lists for both v1.5 and v1.6. Of course, the tool
will be able to maintain vulnerability lists for many different products/versions
from many suppliers.
3.
Despite the SBOM
Forum’s recent incremental progress in getting NIST (which runs the NVD) to recognize the
importance of addressing the NVD’s problems with CPEs, the naming problem is hardly solved. This means that,
unless suppliers take it upon themselves to do the work required to identify a
CPE or purl for as many components as possible, SBOMs (especially those created
through an automated process) will continue to be mostly useless for the
purpose of vulnerability management.
4. VEX information is
essential for the component vulnerability management use case, yet suppliers
aren’t producing VEX documents for their customers. I know of only one
supplier, Red Hat™, that makes documents called VEX available to customers now.
However, much though I admire the great work Red Hat does in the area of
vulnerability management and reporting (and the work that Pete Allor, Red Hat’s
Director of Product Security, does as a member of the CVE.org board), because Red
Hat has such a unique business model, the type of VEX documents they now
produce would be of limited usefulness to the customers of any other supplier.[iii] Note that, if the
supplier were doing the SBOM analysis themselves, they wouldn’t need to produce
VEXes, since the exploitability information could just be passed – in any
desired format, or even just as a list in an email - from the department that
produces it to the department that uses it.
5. Most importantly, it
makes no sense to require that every customer, in order to learn about
exploitable component vulnerabilities, perform exactly the same analysis on
their own that the supplier should already be performing for themselves. Isn’t
the supplier the one that needs to know first about exploitable component
vulnerabilities – so they can patch them as soon as possible? Given that they
have this information (or should have it), why can’t they just share it
with their customers, rather than requiring each one of them to derive exactly
the same information on their own?
Fortunately, I think that software
users will start requiring that their suppliers perform this analysis and make
the results available to them for free – just like they do for patches (suppliers
initially resisted the idea of distributing security patches for free as well.
That resistance quickly faded when they realized they would end up with exactly
zero customers if they didn’t do it).
The suppliers will provide the
analysis, although, unlike with patching, this work can be accomplished much
more efficiently by third party service providers. Those providers will utilize
tooling they have developed for their own use (and not for end users, which
means it doesn’t have to be made foolproof or user-friendly. Given some big issues
that need to be addressed, such as the naming problem, this is currently the
only way to develop such tooling. My guess is it will be years before there
will be any true consumer tools available for tracking software component vulnerability
status). They will make the results (lists of exploitable vulnerabilities) available
to the supplier’s customers for free, while charging the suppliers for their
services.
Will the end users need to perform
any component vulnerability analysis on their own? They will need to in cases
where:
a.
The supplier simply
refuses to pay a third party to perform the analysis, but cannot or will not perform
it themselves; or
b.
The organization doesn’t
trust the third party service provider to perform the analysis properly and
wishes to do it themselves; or
c.
Someone at the user organization
simply enjoys performing the analysis on their own (maybe utilizing open source
tools they’ve chained together).
Thus, the “professionals” in the software
component vulnerability analysis world will be the third parties that specialize
in performing these services for suppliers. The organizations that perform the
services on their own will be “keeping score at home” (not that there’s anything
wrong with that, of course).
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] Steve Springett, the leader of the Dependency-Track project (as well as the CycloneDX project), showed me this week that D-T has all the capabilities required to be a complete tool, but they aren’t explicitly tied together to do that. I will work with him to explain the use case I have in mind, so D-T (which is already used 10 million-plus times per day to look up vulnerabilities for components listed in an SBOM) can truly be the first complete SBOM/VEX analysis tool.
Steve and the CycloneDX project team are also working
on a format-agnostic BOM exchange API called Project
Koala. I believe (and hope) that this API will also ingest VEX information
retrieved from a VEX server,
since I no longer believe that VEX information will ever be shared in any
quantity through machine-readable VEX documents, at least for software component
vulnerability management purposes.
[ii] Of
course, the tool will track the status of every component vulnerability listed
for the product, not just those with “affected” status. The user will be able
to obtain the complete list at any time, including component vulnerabilities
with “not affected” status.
[iii] They
are only producing one VEX document a year for a product, usually around July
1. However, to be truly useful, VEX information has to be updated at least daily,
which is why I am pushing the idea of the VEX server.
No comments:
Post a Comment