What the heck is an SBOM?

In this episode, Matt uses the analogy of America’s beloved boxed mac n’ cheese to define what a software bill of materials (SBOM) is and should be. He then points out that when making SBOMs, organizations should look to approved and standardized SBOM formats for them to be as clear and transparent as possible.

Keep learning
• Podcast: Don't Sleep on SBOMS
• Report: Why NIST is Driving SBOM Evolution
• Special: The State of Supply Chain Security

Episode Transcript

MATT ROSE: Hi everyone. Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs. Today's episode is called WTF is an SBOM? SBOM (software bill of materials) is one of the hottest topics in the industry these days. Everybody's talking about SBOMs. It's even going to the highest level of government with the President in the Executive Order about SBOMs, self attestation of what's in your software.

But not all SBOMs are created equal. I'm gonna use a visual here just to help everybody out. So really what I think an SBOM is a ingredients list, like food products. Who doesn't love Kraft mac and cheese? Kraft mac and cheese been around forever. Staple of every kid's diet. But again, who doesn't love powdered cheese?

The thing about an ingredients list is it needs to include everything in that box. So if  you're looking at a lot of the SBOMs that competitors or companies are creating, they're just providing an SBOM of the mac, not the cheese. What if you're allergic to cheese or wheat or gluten or whatever it is in there?

You need to know all the ingredients... that extrapolates and maps directly to a software bill of materials for an application or a piece of software. So, SCA, other vendors that are producing a component, just the open source code, just the homegrown code, just the APIs as a bill of materials.

That's only a piece. That's just the mac, but not the cheese. So we'll get rid of our little graphic here and our favorite mac and cheese lunch as a kid, to think about what is a proper SBOM. A proper SBOM has to be comprehensive for the entire piece of software, the entire application. And there's really three major formats or approved formats that are people are looking to provide an SBOM in a consistent format or a consistent way.

We have Cyclone DX from OWAST. We have SPDX and SPDX Light from the Linux Foundation. And then we have SWID from, where are they from? NIST, sorry, little bit of a brain cramp there. These are appropriate formats of an SBOM. They basically are consistent, they're repeatable, and they basically don't leave anything to the imagination.

As I said, SBOM is like Oprah, where you get a car, you get a car, you get a car. Every vendor's saying you get an SBOM and you get an SBOM and you get an SBOM. But the SBOM, a lot of times people are just creating their own format and just providing you with a list of a few pieces of the application where there's a whole lot more, like the mac and the cheese.

We need all the components: homegrown code, third party code, open source code, all that basically references to technology in the package itself. So when you're thinking about WTF is an SBOM, a software bill of materials, it has to be complete. It has to have all the components of that piece of software or that application to be effective, and it has to be in a format that is acceptable and recognized by the industry.

So if you're thinking about SBOMs, always ask what format is that SBOM in? If it's just a made up magical SBOM format that nobody's ever heard of before. Probably not comprehensive, probably not effective. But if it's in Cyclone DX, SPDX, or SWID, you have an SBOM that is recognized in a proper format.

I'm Matt Rose. Hope you enjoyed the episode. SBOM is the world. Take care everyone.