What Makes a Quality SBOM? It Depends on Who's Asking.
SBOM quality isn’t a fixed standard—it depends on who's requesting it and how it's being used. In this clip, Dario Lobozzo, GM of EMEA at Finite State, explains the multi-layered challenge of delivering “quality” SBOMs across internal teams and external suppliers.
•3:16•HD•0 views
What Makes a Quality SBOM? It Depends on Who's Asking.
Transcript
We come to the debate about quality SBOMs.
This is a really difficult question as it relates to who's asking.
Right? So who's asking for the question?
Let's take the most stringent asker, the FDA. The FDA stated, not only do we require you to attest to your vulnerability status, but we also are going to require you to provide an SBOM behind that and we want it to be a quality SBOM. It has to be something that we could actually look at in a human readable way or import into some other toolset and do an actual comparison on it.
Now we're at point two. Quality might not be fully at your discretion as a manufacturer. You have a supply chain. You likely have multiple components inside of your product that are not yours. Let's say you manufacture an MRI machine or some kind of centrifuge for medical devices, and you're buying some drives from some some some drive belts from some other manufacturer. You don't make drive belts. You make MRI imaging machines.
You're going to ask them for an SBOW. So you can include that as a component to your product.
How do you know that the SBOM they've provided you is indeed of any kind of quality that you can rely on? So without the trust and verify part of security, you don't. You don't really know. So it is important to kind of take a worst case scenario approach in building out an SBOM.
I think that third party components is a very difficult challenge for teams who are trying to build SBOMs and build quality SBOMs. And then maybe the third bit is, let's say you've got a quality SBOM from your supplier. Let's say you know your supplier is using finite state, so you can rely on their SBOM and you're using a reputable tool on your side as well. So you can rely on your SBOM.
But then you have another piece of the tool that's coming from a third team inside of your organization and they use no tools at all. They just want to give you an SBOM generated by their IDE or generated by their development team.
That often will have quite a lot of erroneous data in there because it doesn't actually get down to the final layer of what gets printed into the code.
So without, again, that kind of third I shouldn't use the word third party without that external assessment by technology, you are kind of running the risk of just believing what's been put in front of you. And that can be a real challenge for teams.
So quality really is at the discretion of kind of knowing what you're dealing with, knowing like what is actually inside of it and that you can rely on the tool that is developing that SBOM for