I guess I understand it's basically an inventory? Maybe someone could chime in with what teams are expected to do with an SBOM. Do you do something with the output, or is it just an audit checkbox?
The classic example is an MRI machine at a hospital. You hear about a bug in the Java Spring library that must be patched asap. You need to do a complete inventory of everything in the hospital running software to decide if it is vulnerable or not.
When you get to the MRI machine: what OS does it run? Is it using Java and the affected component? Is the component an affected version?
Asking the manufacturer for everything for every security vulnerability is not scalable and may not result in accurate answers. By giving the consumer more info they are more empowered to act and make intelligent decesions.
I've seen a project https://backstage.io/ of which one if its features does something similar to what you're describing.
There's a cottage industry forming to do this sort of thing, mostly in the medical field, but it'll probably spread out.
A developer (or even administrator of a single computer system) is not the user of something like this, typically.
Here's an example:
A small manufacturing business may have a dozen different machines. Each one has a set of software to control it, running on a computer embedded in the machine. The business also has a website (developed by a contractor), a bunch of software packages purchased from different vendors for accounting, inventory, payroll and scheduling. They probably have some internal home-grown tools too.
1. A new remotely exploitable CVE is announced in a widely-used open source library. Is the company vulnerable to it? Anywhere?
If each one of the pieces of software was delivered with a SBOM along with the actual code, you can use tools like this to look at this globally. It starts to make more sense at the scale of "all the software in the business" is provided by tens to hundreds of different vendors or teams that not only don't communicate with each other but also don't even know that the others exist.
My client isn't exactly a "small manufacturing business", but they do subscribe to such a service, and they did have the Java issue in a parent process. They have a security guy who's the main one expected to look at these, but he's not the one operating anything directly, so he can't be expected to know every last random lib that's used.
So when the Log4j2 issue came up, for example, he was aware there was "a Java issue" but had no automated way of knowing which systems, if any, were affected.
> the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
I've spoken with dozens of companies and it was a very similar story: Writing a detection script and then SSH'ing into every box, applying a Helm chart to scan every running container, putting the script into every CI job... Which takes weeks to months of manual effort to deal with.
And that's not even dealing with the "once you found it, who goes in and patches it?" Which is it's own can of worms.
For context: I helped deal with the fallout of Log4Shell by writing a blog post about it (I gave it that name). Since then, we've been working on an Open Source SBOM database called LunaTrace[0] to help fix what I wrote above.
0: https://github.com/lunasec-io/lunasec/tree/master/lunatrace