It’s no exaggeration to say that
almost the entire focus of the SBOM literature so far has been on production of
SBOMs: that is, describing what software suppliers need to know in order to
produce usable SBOMs, including of course a lot of discussion of formats.
This is in retrospect not too
surprising, since when the NTIA Software Component Transparency Initiative
started in 2018, there wasn’t much awareness of SBOMs among either software
suppliers or software users. Today, in large part due to the good work of the
Initiative (which ended last year) and the documents
they produced, suppliers are both aware of and using SBOMs; that trend will
continue.
However, suppliers are producing SBOMs
almost exclusively for their own use. That is, they’re producing them so they
can be aware of cybersecurity risks to the products they develop, which are due
to the components they include in their products. The supplier needs to learn
about the level of risk posed by each component in the product in order to
determine, for example, whether a component has any serious unpatched
vulnerabilities that warrant removing the component and replacing it with a
less risky one. Having SBOMs for their products is important for a supplier in
achieving that goal.
Of course, it’s a good thing that
suppliers are making use of their own SBOMs. It means that the software we all
use is becoming less risky. But SBOMs have been touted all along (including in
this blog, to be sure) as a way for end user organizations to learn
about the risks posed by components in the software they use. To do that, those
organizations (i.e., any organization, private sector or governmental, that
uses software) need to receive SBOMs from their software (and intelligent
device) suppliers. Except in rare cases, that simply isn’t happening now.
Why aren’t the users receiving SBOMs
from their suppliers? As I just said, it’s likely that most larger suppliers
have SBOMs for their products now; and if they don’t, it’s almost trivially
easy for them to start producing them. In fact, given the advantages of having
SBOMs for their own use now, you have to wonder about any supplier who tells
you they don’t have them today.
The reason why suppliers aren’t
distributing SBOMs is that their customers aren’t asking for them. So why
aren’t the customers asking for them? Now we’re getting to the heart of the
problem. There are two important things that users need, which they don’t have
now.
The first thing users lack is one
I’ve mentioned before: low-cost or open source automated tools or third-party
services, that will ingest SBOMs (and VEX
documents) provided by software suppliers. Those
tools or services will then produce for the user organization a list of exploitable
vulnerabilities that are due to components included in the software they employ
to run their business. There is some progress being made addressing this
problem, but I’ll admit it’s coming slowly – far too slowly for a lot of our
tastes.
But the second thing is just as
important as the first: users need documentation that provides a coherent
narrative (at a high level, of course) of all the steps they need to take in
order to use SBOMs and VEX documents to mitigate their software supply chain
cyber risks. More importantly, the documentation needs to be written for a
software user that doesn’t already have a good understanding of software
development and SBOMs.
This latter point is especially
important. During its three years of existence, the NTIA Initiative produced
good documents about SBOMs, some of which touched on how they should be
used. But all of those were written from the point of view of software developers
(suppliers). And they mostly use language that developers understand, which is
foreign to a lot of end users. This isn’t surprising, since the great majority
of participants in the meetings were either developers or consultants to
developers.
This is why I’m quite pleased to
announce that there’s now a document available that provides a comprehensive
narrative of what an end user organization needs to do to obtain SBOMs and VEX documents
and use them for the purpose of reducing the cybersecurity risks their
organization faces – specifically risks due to components found in the software
they utilize to achieve their mission. Fortress Information Security[i] has just released a white
paper titled “Software Bills of Materials Consumer Use Cases”. It’s available here.[ii]
Two caveats about this paper:
1.
While the paper
provides a good picture of how SBOMs can be obtained and used now, this is
still early in the SBOM “game” and there are bound to be lots of changes over
the coming few years. I hope Fortress will update the document regularly.
2.
Even based just on
what’s understood today, there is undoubtedly a lot more that could be added to
this paper – for example, regarding VEX documents. So there might well be
further white papers addressing specific topics on the consumption spectrum.
I hope you’ll enjoy the paper! If
you have comments or questions about it, please drop them to tturner@fortressinfosec.com – and if you don’t mind copying me, I’d love to see them
as well.
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