The CISA SBOM-a-rama last week was quite good; I attended it virtually. The meeting started with presentations by three people leading SBOM programs in their industries: Jon Meadows of Citi (financial), Jennings Aske of NY Presbyterian Hospital (healthcare), and Charlie Hart of Hitachi Automotive (autos). They all discussed their industry’s experience with SBOMs and expressed a lot of confidence that SBOMs will help make their software more secure, given some time (speaking of time, there was general agreement that all three of them should have been given more of it for their presentations. I’m sure they – and maybe others – will have more time in the next SBOM-a-rama, which might be this fall).
However, there was something else
that all three of them had in common: none of them pointed to any actual use of
SBOMs in their industry. And even though all three of them are in leadership
positions for proofs of concept in their industry, none of the proofs of
concept is currently actively exchanging SBOMs (the healthcare PoC started
exchanging SBOMs in 2018. There was a second healthcare PoC in 2020 and 2021.
The third PoC started this year and is on a temporary hiatus but promises to
return).
So, what was different about the
three presenters? Both Jon and Jennings had a positive attitude, yet were clearly
disappointed that they are encountering serious problems in their PoCs. In
Jon’s case, the problems have to do with the “quality” of the SBOMs they’ve
received as well as the naming problem, which is serious but may be on the road
to at least a
partial solution. In Jennings’ case, the problems
are uncertainty about how to approach VEX, and issues regarding how to integrate
SBOM and VEX data with existing asset and vulnerability management systems.
But Charlie was very different. He
was quite upbeat, and he was – dare I say it? – clearly having fun. The
autos PoC, which he runs, isn’t exchanging SBOMs between suppliers and
customers any more than the other two are. However, the industry as a whole (or
at least a significant percentage of the companies) is conducting tabletop
exercises, where representatives from automotive suppliers and OEMs get
together in one place, throw a bunch of SBOMs on the table (which don’t relate directly
to products made by any of the suppliers, thus avoiding any legal issues) and
discuss them – why they’re good, why they’re bad, etc. If a supplier doesn’t get
something right – and it’s almost guaranteed that something won’t be
right – everyone can learn from their mistake, and nobody has to feel bad about
it.
What allows this to happen? I
haven’t talked with Charlie about this specifically, but my guess is the Autos
PoC had both suppliers and end users sign an NDA that says something like (in
legal language, of course), “We’re entering into this exercise with the clear
understanding that we’re all learning about something new. There are still many
unknowns about SBOMs and VEX information, as well as the policies and procedures
that need to surround them. If we pretend any of this is well-understood
practice, we’re simply fooling ourselves. More importantly, we’ll spend all our
time trying not to make a mistake and we won’t learn anything. Therefore, we’re
going to jointly examine publicly available SBOMs for a variety of products and
see what we can learn about creating and utilizing them”.
In listening to Charlie, it
occurred to me (although not for the first time) that we ought to apply the
approach of the Autos PoC[i] to the whole software
community (at least in the US. I’m not competent to decide what other countries
should do). We ought to agree (in NDAs between suppliers and their customers.
This might be a standard form or a customized one) that we’ll treat SBOMs as a
big tabletop exercise, where suppliers promise customers they’ll do their best
to produce usable SBOMs (perhaps for legacy products, in order not to reveal information about current products that they may not want revealed, for competitive or security reasons) and the customers promise not only not to sue the suppliers
for mistakes, but to provide feedback to them that will help them improve. In a
year, suppliers and their customers will decide together how this is going, and
whether they want to continue the “exercise” or start moving toward an approach
based more on legal guarantees.
What’s the alternative to taking
this course? It’s the state we’re in now, where I don’t know of a single
software or intelligent device supplier in the US (other than in the military
realm, into which I have no visibility) that is providing SBOMs to its
customers (who aren’t themselves developers) on a regular basis (which I define
as with at least every major new version). At the moment, we’re learning almost
nothing about SBOMs, because only experience can settle most of the big
questions. Could learning at least something, and having fun while doing
so, be all that bad? It would certainly be a change of pace…
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]
I’m sure both the Financial and Healthcare PoCs have similar NDAs in place. Given
the huge uncertainty regarding the details of SBOMs and VEX now, any supplier that
didn’t require end users to sign an agreement like what I just described would
be asking for trouble.
No comments:
Post a Comment