Shift Up Your Software Bill of Materials
Keep learning
-Related: SBOMs: Your Software Ingredient List
-Report: How and Why NIST is Driving SBOM Evolution
-Report: 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 and your host for this glass board series. Today's episode, as you can see, it's always across the top, is Shift Up Your SBOM. This is a continuation of my previous episode.
That talked about shift up your software supply chain security initiative's programs. So first of all, let's level set: SBOM or software bill of materials is a hot topic. Everybody's talking about this self attestation, having everything in the piece of software that you're selling or your allowing your customers to use.
The two main formats that I like to talk about are Cyclone DX and SPDX, a little squeaky today. So Cyclone DX stands for data exchange and SPDX is software package data exchange. These are both formats that are recognized in the industry for consistency for a way to deliver information that's expected, if you will.
But the thing is a lot of organizations are talking about SBOMs and they're creating their own format. One of the biggest things is thinking about using an SBOM for just a component. And this is where you gotta shift up your SBOM. SBOM associated with software supply chain security has to be complete.
It has to be holistic. So the way I like to think about this is, why don't we think about an SBOM or a proper SBOM as like a satellite above the earth looking down, seeing the whole side of the earth, that it's actually focused on, a whole continent, a whole country. So thinking about an SBOM to be effective has to be in one of these two formats or other recognized formats and has to have the whole picture, not just a piece of the puzzle.
The one of the problems that people do is they, I got a prop here for you today, they look at SBOMs or the information in an SBOM through a very finite lens. So here I am, I have my binoculars. If I'm looking through my binoculars, you like my prop today, looking through my binoculars, I'm gonna see something very small.
I'm gonna see a branch of a tree, I'm gonna see a boat on a lake, but I'm not gonna see the whole landscape, all the things around it. And that's what you have to think about with SBOMs. A satellite above the earth, looking at the whole picture, shifting up in terms of not the complexity, but the completeness of the program itself.
The binoculars are looking at a small piece, which is very similar to a lot of the SBOMs that are being created out there where let's just say you have open source code. And you have an SCA solution. That SCA solution, here let me get my prop back, is going to just basically stare down that open source code.
It's not looking at the first party code, the code you're developing, or the dependencies, or the third party packages and libraries you're including in your application. If you're using that type of approach, you're using binoculars, you're not using a satellite above the whole ecosystem. That way you have full risk.
Cuz last thing we want to do is work busy, work harder to basically create a bunch of SBOMs on a specific component of an application or a compiled package, whatever that is, and then have to put 'em all together. And you may miss something in the copy pasting, formatting, whatever it is. An SBOM needs to be the entire package inclusive of all the things.
It needs to be the satellite above the planet, looking down on the components to provide a Cyclone DX and SPDX, or other industry format for SBOMs. Food for thought. Hope you like the props. I'm Matt Rose. This is ReversingGlass. Thanks for joining.
