What is an SBOM and how can it help?
By Patrick Miller
An SBOM is a software bill of materials and it can be a crucial tool in critical infrastructure cybersecurity. In this video, Ampere's Patrick C. Miller talks about how it works.
Keysight Sr. Industrial Solutions Manager Gail Ow interviews Ampere CEO Patrick Miller about supply chain security. Interview edited for length and clarity
GAIL:
During our last time getting together, we talked about something called the SBOM as a part of supply chain security. I was wondering if we could start with an initial definition of 'What is an SBOM?'
PATRICK:
An SBOM is a 'software a bill of materials.' That's the list of things that is in your software.
I think probably the better analogy is soup. If you look at a can of soup or you look at soup, sometimes you can see what's in there. But if you had a list of ingredients, you would know what's in there. You can't look at software and see what's inside software.
What you do with the software bill of materials is, for example, like the soup analogy: if I'm allergic to garlic or I'm allergic to soy, I need to know that before I eat that soup. Similarly with the software, if there is a problem with one of the components of that software, I need to know that so I'll know what to do about it.
GAIL:
Well, that makes sense about soup and food allergies. I happen to be allergic to some things and so I understand that concept. Why do we need an SBOM for software? And what does it do for us?
PATRICK:
This is so you know what you're getting. This is so you know what you're actually purchasing.
With software, it's not written by one person somewhere at a desk, it's written by people all over the place, over a long span of time. Developers will write libraries and those libraries will get reused by other software packages, and code gets embedded inside other code that gets embedded inside other code.
It's this kind of mishmash of things that ultimately gets put together into something. You click and then something else happens. That bill of materials tells you that these libraries are in there, those components are in there, that scripting engine is in there. That way, if there are problems with those things, then you know what to do. You can basically look up vulnerabilities on them. If they are vulnerable, you can either patch them, if that's available, or you can, for example, isolate the machinery in some way that makes it more difficult to have that vulnerability become a problem.
GAIL:
Are they required and who creates them?
PATRICK:
They're not required right now, per se. There are some requirements that are just now coming out. In the past, it has been kind of a nice-to-have thing. It's a definite line in the sand going forward, though.
The Executive Order 14028 has, I think, SBOM in there like 14 times or more. It's really about how the federal government is purchasing software. But that's a pretty big customer. So if you're selling software to the federal government, you will need an SBOM.
It's also beginning to show up in things like NERC CIP. It's not specific in NERC CIP, but it's being used as part of the supply chain risk management framework there. Same thing in TSA for gas, and it's in chemical and water as kind of a 'you should be doing these things' as well. If it's not required, it's about to be.
Who should be using these? It's the critical infrastructure companies. So if you are chemical, water, gas, electric, transportation, all of those areas, you need to be paying attention to this because these are critical components. And they cause problems and could even cause things like loss of life or extended duration of missing water or electricity, gas, any of those components.
If that happens, and there's a supply chain failure, and you didn't do things like follow an SBOM, ask for one, know what to do with it when you got it, that's going to become a problem going forward.
GAIL:
How do we get one? Who creates these things?
PATRICK:
The manufacturers create the SBOM. If they're in the critical infrastructure already, they probably have something like a software development lifecycle. And they've got some management around how their code is checked in, checked out, certificates, hashing, all of these great things.
That makes it a little bit easier to pull together an SBOM. The manufacturers make these and then the other side of it is the organizations that are asking for these, like the utilities, the manufacturing companies, the chemical refineries, the gas companies. They ask for the SBOM.
Effectively what happens is they take what they get from the manufacturer, they use a tool to compare the two, and they know what's in there. They can say, 'Yes, all the things we expect are in there and nothing else is in there. They didn't insert garlic into my soup and now I'm going to get sick,' for example.
GAIL:
As part of the critical infrastructure, I ask for the SBOM, the manufacturer produces an SBOM, I run my tool against what they've given me, and it comes back a little different. What happens then?
PATRICK:
Well, that's when you have a you have a risk. You have to have the conversation with the vendor to find out: did you actually get what you expected?
In some cases, there are things like file integrity and certificates that can go a long way to helping this. In some cases, it may just be that there's a mismatch in the tools. But that's an interesting conversation for you to have with your vendor and should be the first thing you do if things don't match up. You need to talk to your vendor right away, because things should line up.
GAIL:
Can you give me an example of where an SBOM might have helped somebody figure out what was going on?
PATRICK:
Probably the best one, a recent one, is the BlackBerry QNX issue.
Microsoft found a component that was called BadAlloc. Blackberry, for a long time, denied that they had a problem with this. And turns out that they actually did. Had you actually received an SBOM from Blackberry, you would have known that this component was in the software and it was vulnerable. You could have begun to take action. There's different things you need to do, whether it's isolate or protect in some way. Without knowledge of that, you could have gone however long thinking that there was no problem, when in reality you had a terribly vulnerable component in your software.
This is not like just everyday stuff. This is in medical machines, it's in cars, it's all over the place. These are things we need to know because, again, it's critical infrastructure. There are problems if this kind of software is vulnerable and we don't know about it. The only way we could have checked is validating that against an SBOM.
GAIL:
The next bonus question is: how far along are we on this whole thing?
PATRICK:
I would say we're probably about, on a scale of one to 10, maybe a five to seven. We do have a ways to go. But we've made a lot of good progress. And I think it's gaining steam.
I think, in general, most organizations know if you're going to be in this space, you need these things. I think fewer and fewer of them are resisting it. And more and more of them are aligning with it and participating in the forums.
There's some great work happening under NTIA and other government branches as well. I'm seeing a lot more push. And I think that, you know, we may be only five to seven now, but the speed is building and we will be getting there relatively soon, especially with the Executive Order.
We're even seeing some elements of cyber insurance asking for this as well. So it's going to be a bottom line issue if it's not a directive in some some cases.
GAIL:
That's a good point. That's a very good point. Patrick, as usual, I have thoroughly enjoyed having this opportunity to talk to you. Thank you for joining us.
PATRICK:
Thanks for having me.
Gail Ow’s Keysight Technologies companion blog for this video