It’s once again time for the outrage generators on social media to ask if SBOMs have any value. This seems to happen a few times a year. Probably lines up with the pent up excitement while we wait for the McRib to return. I could dig up a few examples of these articles but I can’t be bothered, and it doesn’t matter. I’d rather spend my time searching for a McRib … I mean, writing this blog post.
I wanted to write down some thoughts, I’m sure it won’t change the constant complaining about how SBOMs are completely useless, and how important it is to tell everyone that, because it’s very normal to remind people about useless things and how useless they are. Nothing really enforces true uselessness like having to spend time explaining how useless something is.
Let’s answer the big question first. Are SBOMs useless? It depends really. If I’m a farmer waiting for my big McRib payoff, they might be. Although with all the right to repair and tractor hacking and all that, it’s possible they’re not totally useless. But like anything, SBOMs are good at certain things, but they’re not good at everything. It’s always good to temper expectations and be reasonable. And most importantly, if there’s something you don’t really like, you can just not use it. If something does suck, just ignore it. Your time has value you know.
OK, so that’s a bad start I suppose. Here’s maybe a better start. Much like rats in New York City. You’re never more than 6 feet from an SBOM. Wait, is that actually better? We started with McRib and now we’re talking about rats … the topic is SBOMs. But really, they drive a lot of modern software, but not quite in ways you realize. That package manager you just used to install a JSON library? That’s an SBOM. You run a vulnerability scanner? Also SBOM! Your car’s entertainment system, it probably lists all the open source it uses in a well hidden menu. Let’s call it a bill of materials, for software.
SBOMs are really just lists of software. I bet you could make a list of things that use lists of software. Package managers, app stores, top ten lists. It’s a pretty common idea.
“HOLD THE #%$& ON!” we hear from the back row, filled with manufactured outrage “THAT’S NOT WHAT ME MEAN AT ALL! We mean systems that manage SBOMs, in SPDX and/or CycloneDX format, can you show me that? That’s what I want to see. Let’s see it! Oh you can’t, WE KNEW IT, sweet sweet victory, we have proven the uselessness beyond a reasonable doubt!” Right about here I’d like to remind you your time has value, and it’s OK to ask for a hug sometimes. I mean, not from me though.
It’s also probably worth explaining such a system will never exist because SBOMs aren’t useful by themselves. SBOMs are tools used to solve other problems where having a list of software is the solution, or at least part of the solution.
You should compare this line of reasoning to going phone shopping and loudly complaining that a company making screws is failing at making devices that can look at memes on the internet. I mean, there are screws in the phones, but if you are measuring screws against their ability to look up memes on the internet, you will be very disappointed. Much like an SBOM, a screw is but a gear in a much larger machine (see what I did there).
The thing is, SBOMs aren’t something that should exist by themselves. They’re a tool, a part, in a larger system. The two SBOM formats that get much of the attention and complaints are SPDX and CycloneDX. But those are just two standards. There are formal definitions of SBOMs that tell us what sort of information they should contain - SPDX and CycloneDX meet those requirements, but it’s foolish to use such a narrow definition by itself, remember, it’s a tool. Standards are importantly for interoperability, but they aren’t necessarily important for solving problems.
Demanding to be shown a successful SBOM tool is the fallacy in this whole argument. Lots of tools use and create lists of software. Some of those can import and export SPDX or CycloneDX. But those formats aren’t necessarily useful by themselves. It’s time for an example.
Let’s say I have a vulnerability scanner. There are many vulnerability scanners in the world, commercial and open source. They have various levels of quality, some are great, some are horrid. Now, in order to scan something for vulnerabilities, I need to know what the software on the system is. This seems like an obvious first step. So the tool has some sort of software identification system built into it. You know what else that identification system can do? It can output the list of software it found, maybe in SPDX or CycloneDX format. More than one vulnerability scanner figured this out, and now they output SBOMs.
At this point the cynical of us would proclaim that while this is technically correct, you can only call it an SBOM if it’s generated in the correct region of France, otherwise it’s just a sparkling list. The reality of it all is complaining about SBOMs gets some attention, but it doesn’t really matter. The ideas behind SBOMs are used everywhere, and formats like SPDX and CycloneDX are just nice ways to communicate a list of software. If you can solve your problem with a list of software, that’s great, do that. Work in this space is progressing wonderfully and there are more tools to help than we’ve ever had before.
And the next time you see someone who seems unreasonably angry about SBOMs, maybe ask them if they need a hug. If you’re not a hugger, ask if they need a McRib.