Wednesday, October 28, 2020

What I’ve learned about SBOMs – part I


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