Have I mentioned that SBOMs are a good thing to have?

We keep getting more reminders of why SBOMs are needed. One of the big reasons for having SBOMs is that, when a serious vulnerability is found in a software component that’s widely used, the first task of most organizations is figuring where this component is actually found in their environment – remember Ripple20? This can be a very time-consuming exercise, plus you’re not likely to have 100% - or even 25 or 50% - success. Having SBOMs for at least some of the software on your network could significantly reduce the amount of time you have to spend talking with your suppliers, scanning all your systems since you have no better way to find the vulnerability, etc.

Coincidentally, the Ripple20 vulnerabilities were announced a little more than a year ago. Then in December, Forescout Technologies announced the Amnesia:33 vulnerabilities. One big similarity between Ripple and Amnesia is they they’re both vulnerabilities in IP stacks that were developed a long time ago (the Ripple20 vulnerabilities were in an IP stack developed by Treck, a company still operating in Cincinnati, in the 1990s). So the vulnerable components have had plenty of time to be embodied in software or embedded devices that were later incorporated into other products, which were later incorporated into still other products, etc. The result is that, in many cases, the maker of a device that contains the vulnerability has no idea that the component is even included in their device – this knowledge has passed out of the collective memory, just like the identity of the person who wrote the book of Genesis.

This week, Forescout (with JFrog) again announced serious vulnerabilities in an IP stack released in the mid-1990s, although this time the stack is used in a lot of OT systems (thanks to Kevin Perry for forwarding me the story); Forescout has named these vulnerabilities “Infra:Halt”. The original developer of the vulnerable software component, called NicheStack, was a company called InterNiche; this company is now part of HCC Embedded, although the product isn’t nowadays sold as a standalone component.

Of course, to truly learn about every instance of any software in your network, no matter how deeply embedded it is in other products, you would need a multi-level SBOM for every intelligent device or “standalone” software product on your network. When will you have this? Probably never, to be honest. In fact, if in three years you have just a one-level SBOM (i.e. a list of the components directly included in the software or device) for the great majority of the software you operate, I’ll consider that to be a big achievement (I also think it’s achievable).

However, here’s the thing about SBOMs: their benefits are entirely incremental. Having an SBOM for just one product is better than having none; having them for ten products is a lot better than having just one; etc. The way things are moving today (partly as a result of the May Executive Order), you’ll definitely be able to have a lot more SBOMs for products you use in one year, than you do now.

How can you take the first step into the world of SBOMs? You can join the Energy SBOM Proof of Concept, jointly sponsored by the National Technology and Information Administration (NTIA) and Idaho National Labs. Moreover, you can join our next biweekly meeting, on Wednesday August 11 at noon Eastern Time. To get an invitation and receive our mailings, drop an email to sbomenergypoc@inl.gov. See you then!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.