If you're looking for my pandemic posts, go here.
I’ve written about seven posts that touched on various
aspects of software bills of materials, but the only post in which I’ve tried
to set out the case for SBOMs is this
one from late August. However, I can now say I know a lot more about SBOMs than
I did in August. This is because since that time I have been able to become
involved with the Software
Transparency Initiative led by Dr. Allan Friedman of the National
Telecommunications and Information Administration (part of the Dept. of Commerce), working
for a client that would like to see SBOMs become widely used in the electric
power industry[i].
Thanks to that client, I can now say I have a much better
understanding of SBOMs than I did in August, including a lot of important
nuances that I had no idea about then. It would be nice if there were a single
book that you could pick up to learn everything there is to know about SBOMs,
but that simply isn’t the case now and I’m not sure it will ever be the case.
If you really want to learn about SBOMs, there’s no substitute for getting
involved (preferably at least a couple of hours a week) in the weekly meetings
conducted by the NTIA, and reading the documents that are being produced by
this initiative.
You can read about NTIA’s mission here. They help foster new technologies
having to do with among other things the internet and cybersecurity. They don’t
do this by publishing regulations or even guidelines, but by convening
“multistakeholder processes” that include people from industries affected by
the new technology (of course, every industry is affected by the
internet and cybersecurity). These people meet and decide among themselves how
they can best move forward the technology in question.
As an aside, I want to point out that NTIA has often been
very successful in accomplishing their missions. One example is something you
use every day (in fact, often every waking hour of every day since you use it
whenever you use the internet in any way): DNS. NTIA didn’t develop DNS, but
they did get it operating and functional at scale, and turned its operation
over to the Internet Assigned Numbers Authority (IANA) in the late 1990s.
In the case of SBOMs, what’s most needed now is for software
suppliers (which includes open source communities, since 9/10 of software
components are open source) to understand how and why to produce SBOMs, and for
organizations that use software (i.e. just about every organization on the
planet) to understand how they can use SBOMs to increase their security.
Most people, when they think of a government-affiliated
organization that’s trying to foster a new technology, will immediately understand
that to mean the organization is developing standards or guidelines (mandatory
or not). That’s how I understood the NTIA Software Transparency Initiative when
I wrote the August post linked at the top of this post. However, that’s
definitely not what this group is doing! They have decided (perhaps implicitly)
that the best way to accomplish their goal is to foster proofs of concept
(PoCs) in particular industries.
I believe that the reason they’ve done this is because the
needs of different industries can differ a lot, so the formats and procedures
agreed on for one industry won’t necessarily be usable for another industry.
Even more importantly, the PoC itself will be the best way to achieve the twin
goals of having suppliers provide SBOMs and software users ask for (or even
demand) them. These are actually two sides of the same coin: No supplier is
going to waste their time producing SBOMs (and there will be a lot of work
required, as I’ll discuss in future posts) if none of their customers are
asking for them. And until those customers have some sort of concrete
demonstration of how they can use SBOMs and benefit from them, they won’t ask
for them.
The first (and so far the only) industry that has done an
SBOM proof of concept is healthcare. In 2018, a group of medical device makers
and hospitals (about five of each) started meeting regularly. Their initial
goals were:
1.
To determine how suppliers would produce SBOMs -
i.e. in what format. There are three primary formats currently, none of which
is a “standard” or “endorsed” (in fact, I’ve already found one vendor that says
their SBOM-related service is “endorsed by the NTIA”. There ain’t no such
thing), all of which the group considered. The group also considered the option
of altering one of those formats to address specific industry needs. They ended
up choosing the “vanilla” SPDX format for the first PoC, but for their current
PoC (which is really their third, although they consider this the second
iteration of their second PoC), they are considering the other two formats as
well, and also considering making industry-specific additions to whatever
format they choose.
2.
To determine the most important use for SBOMs in
the hospitals, and what would be required for them to achieve positive results.
This has perhaps been the easiest part of the PoC to define: The primary
purpose of having SBOMs is to be able to track vulnerabilities that are
identified in software components of a medical device (like an infusion pump)
in use at the hospital.
So far, the only PoCs that have been started are the three
(or two, depending on who’s counting) PoCs that apply to medical devices used
in hospitals. However, a PoC for the auto industry (of course, tracking all of
the software components that are included in your car’s engine) is supposed to
begin soon. I’m waiting for stickers in auto showrooms to show, right under
miles per gallon, statistics like “Number of software component vulnerabilities
currently unpatched”. I’m sure that will be the deciding factor in a lot of purchase
decisions. After all, who cares whether the car has a sunroof as long as there
aren’t many unpatched component vulnerabilities?
But this is a power industry blog, and you may be wondering
when a power industry PoC will start. Up until a couple weeks ago, I would have
told you “It will be a while.” Now I’d say it’s something that you’ll at least
hear about this year, although my guess is it won’t start until next year. I’m
hoping there might be something to announce[ii]
in a few weeks, although that might be over-optimistic.
I have decided that I’m going to be posting quite regularly
what I’ve learned (and am learning) about SBOMs, since they will be getting a
lot more attention from the power industry next year. You’ve been warned.
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 also now involved with another organization, the DBOM Consortium, that is pursuing a complementary technology path called Distributed Bill of Materials. I’ll discuss them in another post in the future.
[ii] It’s
actually much more certain that a power industry PoC will start soon for the
DBOM consortium, which would be complementary – and perhaps coordinated with –
the SBOM PoC for the industry; there is already a group meeting to discuss and
frame this PoC. If you’re interested in participating in this group, send me an
email and I’ll connect you to the people running it.
No comments:
Post a Comment