In last week’s meeting of the SBOM
Forum, toward the end of the meeting we somehow got onto the topic of whether
SBOMs are succeeding in the software world – that is, whether they’re being
used in volume. Whenever this topic comes up, I always point out that there are
two SBOM “markets”. One is the market for SBOM use by software developers. The
developers use SBOMs to learn about vulnerabilities in their products as
they’re developing them. The second market is the rest of us: organizations
whose primary business isn’t software development. It’s safe to say that the
second market is potentially hundreds or thousands of times larger worldwide
than the first.
The first market is doing very
well, in no small part because the NTIA Software Component Transparency
Initiative was composed almost entirely of developers or consultants to
developers. The best indication of this fact is that Dependency Track is used over ten million
times a day to look up vulnerabilities for
components in an SBOM.
However, Steve Springett, who
developed Dependency Track more than ten years ago and who leads the OWASP
Dependency Track, CycloneDX and Software Component Verification Standard (SCVS)
projects, has admitted to me that the great majority of those ten million daily
lookups are due to developers trying to learn about vulnerabilities in their
products (he bases this statement on the inquiries he’s seen on the CycloneDX
Slack channel, which has over 1,000 subscribers). And even though I admit that
one factoid doesn’t constitute proof in this case, I will assert (and I did on
Friday) that there is very little distribution and use of SBOMs by
organizations worldwide, whose primary business is not software development.
In the meeting, my opinion on this
matter was universally shared by…me (with one or two others seemingly on the
fence, unless they’d just fallen asleep). I’m used to this reaction, since even
today, most of the people involved in discussions about SBOMs are developers. They’re
not lying when they assert that there’s already substantial use of SBOMs for cyber
risk management purposes: They hear discussions of SBOMs and see them being
used all the time. Moreover, they’ve all seen a huge increase in SBOM usage in
the last 4-5 years. But this is in the software developer community, not in the
software user community, which is…just about every public and private
organization on the planet today (even one-person companies in poor countries
use cell phones, although software risk management is quite different in those
cases).
It doesn’t bother me that I’m often
out on my own limb in the SBOM Forum meetings. This is because I know I have the last word, since I
write up the meeting
notes after the meeting and since I can always write
a blog post about the meeting (as I’m doing now).
So here’s my last word. Since
there are no data available on worldwide use of SBOMs, these are observations that
I consider to be good indicators that support my position. If anybody knows of
contra-indications to these, please let me know:
·
I know of only one
industry in which SBOMs are being heavily used by “non-developer” organizations
(a huge percentage of private and public sector organizations either develop
some software or have it developed for them. But if their primary business isn’t
developing software, I don’t call them developers). That is the major German
auto makers (referred to as OEMs), who receive SBOMS regularly from their major
suppliers like Bosch, for the intelligent devices produced by those suppliers. The
OEMs need these to comply with tough German regulations regarding open source software
component licensing. I believe the OEMs are not currently using SBOMs for cyber
risk management purposes.[i]
·
I know of no software
developer of any size that is regularly distributing SBOMs for more than
a handful of products. By “regularly”, I mean the developer produces a new SBOM
with every major and minor release of a product; this is important, since it’s almost
certain that an SBOM for any version of a software product will no longer provide
a reliable description of even the next minor version of the product (if the
user has upgraded to the new version, of course). Many developers have distributed
(usually on a customer web portal) a small number of SBOMs for some of their
products, usually because of pressure due to Executive Order 14028 – although there
is still no “requirement” to produce SBOMs under that EO. However, as soon as a
customer has upgraded to another version of the product, they might as well
discard any previous SBOMs for the product.
·
I have asked several
major developers (or intelligent device manufacturers) who use SBOMs heavily on
the development side of their organization whether the business side of the
organization is making regular use of SBOMs to manage risk posed by
components in the software they use to conduct their daily business (this requires
receiving SBOMs regularly from the suppliers of the software and devices they
utilize, of course). I have only received one answer of “Yes” to this question,
and that was qualified by a statement that very few software suppliers to the
business side of the organization were providing SBOMs at all regularly.
·
I know of no low or no
cost, commercially-supported software tools that ingest SBOMs, look up
component vulnerabilities in the NVD or other vulnerability database(s), ingest
VEX documents to identify the over 90% of component vulnerabilities that aren’t
exploitable in the product itself, and make the output available in
machine-readable form to vulnerability or asset management tools – and do this
throughout the organization’s use of a product, meaning tracking
vulnerabilities separately for different versions of the product and updating
each version’s vulnerability list whenever a VEX indicates a change in the
exploitability status of a vulnerability (see this draft use
case from the OWASP SBOM Forum). I know there are open source tools like
Dependency Track and Daggerboard that perform parts of this process, but I know
of no single tool, especially a commercially supported one, that performs the
whole process.
·
However, the lack of
consumer tools doesn’t mean there will be no large-scale – or even medium-scale
– use of SBOMs until such tools are available. This is because third party
services can (and will) appear that will be able to develop their own tooling
(including stringing together various open source products) and spread the cost
of designing, developing and operating that tooling (especially the cost of finding
people knowledgeable enough to facilitate all of this) across a potentially
large customer base. I believe these services could be developed very quickly
once the next problem is addressed.
·
Speaking of VEX, I
know of no VEX documents that are being produced and used today in the use case
just referenced – although the SBOM Forum is working now
on specifications for that use case (which we consider to be the most important
one) on both the CSAF and CycloneDX platforms. Once we have done that, it will
be possible to fully automate production and consumption of VEX documents (with
allowance for the fact that the naming
problem is still an issue, and may require manual adjustments to the output
of the automatic process). No supplier is going to distribute a VEX to users of
a product, knowing that over 90% of the vulnerabilities applicable to components
in the SBOM will not be exploitable – which will lead to large numbers of users
tying up their help desk with calls and emails about non-exploitable component
vulnerabilities.
To summarize, SBOMs are still a
long way from where they should be. But this can’t be shrugged off by developers
who say, “Well, we’re making progress…” Sure, “we” – meaning developers – are making
progress in using SBOMs to manage vulnerabilities in their products. And this
fact alone is benefiting their customers.
However, just about everything that’s
been said in the public realm (including in EO 14028) about SBOMs is based on
the assuming that non-developer organizations will start benefiting very soon
from being able to use SBOMs to learn about vulnerabilities and other risks in the
software they utilize every day. That isn’t happening yet, but it’s achievable through
focused effort like what the OWASP SBOM Forum is doing. It’s not achievable through
congratulating everybody about moving to the next square on the 1,000-square
chessboard. It’s like we’re on a driving journey from New York City to LA. We’ve
crossed the Hudson River and we’re now in Hoboken, NJ. That’s incremental
progress, but we’re not going to reach LA in our lifetimes that way.
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 or contribute to our group, please go here.
[i] There
is also a very unique arrangement in place that facilities the development, exchange
and use of SBOMs between the OEMs and the suppliers, which, based on the little
information I have about the arrangement, would probably never pass antitrust
muster in the US.
No comments:
Post a Comment