What’s an ‘SBOM’ and what does it have to do with federal cybersecurity?

Best listening experience is on Chrome, Firefox or Safari. Subscribe to Federal Drive’s daily audio interviews on Apple Podcasts or PodcastOne.

Deep in the Biden administration’s executive order on cybersecurity is the idea of software bills of material (SBOMs). The order gave the Commerce Department the task of issuing guidelines for software supply chain security. One detail asked industry to provide comments to the National Telecom and Information Administration regarding SBOM. What is it and what’s it got to do with secure software? For some answers, Federal Drive with Tom Temin turned to the open source Linux Foundation. Kate Stewart is the foundation’s vice president of dependable embedded systems, and David Wheeler is the foundation’s director of open source supply chain security.

Interview transcript:

Tom Temin: Kate, good to have you on.

Kate Stewart: Thank you very much for inviting me.

Tom Temin: And David A. Wheeler is the foundation’s director of open source supply chain security. Mr. Wheeler, good to have you.

David A. Wheeler: Thank you very much. It’s great to be here.

Tom Temin: All right. So let’s begin with the beginning. What is an SBOM? I think a lot of buyers think software is mostly a bill of goods, but it’s actually a bill of materials. Miss Stewart?

Kate Stewart: Yeah. So a software build of materials is effectively a list of components. What’s in your software, where your ingredients? And then how do they relate to each other? There’s a lot of dependencies that are sitting in the supply chain right now. And being able to articulate the dependencies from one software component to another software component helps you understand the risk level. Now, this is all part of making software and what software you’re using more transparent, which has other use cases as well. So a software build of materials has actually been around for a long time in certain spaces. And it’s been mostly used in the licensing and procurement side. But the same transparency that’s been benefiting that part of the industry is very valuable here for the vulnerability side as well. So, this is where we’ve been coming at from a software build of materials perspective. And we’re trying to take and leverage some of the work that’s been done in other domains into security now.

Tom Temin: And given your title as vice president of dependable embedded systems, I guess this applies both to packaged software developed to do a function in run on a server somewhere, as it is in say, military-type systems where it is inherent in a black box on a platform somewhere.

Kate Stewart: Yeah. Software build of materials can be created for any type of software, be it open source, be it proprietary, be it fully open on its server somewhere, deeply embedded. In fact, one of the things I’m really excited about is one of the projects we do at the Linux Foundation, Zephyr, is for resource constrained devices, like sensors and actuators. And what we’re doing with that is in the last release, the [version] 2.6 release, you have now have the ability to on your build, generate a software bill of materials automatically as part of the build, and it will take it down to the source file level, which is where the vulnerabilities happen. The components are one thing, but how they’ve been built, how they’ve been configured, all that information is kind of key to understanding are you vulnerable or not? Can you be exploited or not? And so, seeing that we can get this automated, is really quite exciting. And there’s a proof out there. And then the Yocto Project, which is another Linux Foundation project, is doing effectively embedded distros that a lot of things depend on and focusing on figuring out how we can get this all automated as part of their builds.

        Read more: Cybersecurity

Tom Temin: And David, can you see into an SBOM when software is compiled? Or do you have to look at it at the component stage before it’s actually runtime ready, let’s say?

David A. Wheeler: I think the goal here is so that suppliers provide the SBOM information. It’s possible as a receiver to determine what the ingredients are in some ways, but it can be a challenge. And it’s not going to be nearly as good as having a supplier, for example, if they see the software before it gets compiled, you can get much more accurate information. But if I can add on a little follow-on, it’s important to know what those components are from a cybersecurity perspective, because some of those components may be older versions with known vulnerabilities. And without having visibility into that, it’s very, very easy for a recipient software is to have a lot of vulnerable components without realizing that these are old, obsolete components with known vulnerabilities. And I think, although there are other reasons to have SBOMs from a cybersecurity perspective, that I think is one of the key uses here.

Tom Temin: We’re speaking with David A. Wheeler, he’s the director of open source supply chain security, and with Kate Stewart, the vice president of dependable embedded systems, both with the Linux Foundation. And so who reads an SBOM and interprets it so that you know, great? Is it a contracting officer? Or is it someone in the program that is going to operate the software? It sounds like you need someone fairly technical to be able to make sense of it.

David A. Wheeler: It’s probably not the contracting officer. It’s someone who works for the program office or that sort of thing. Generally, you would use tools to read these things. A human certainly can read this data. But normally you would take this data and run into tools to answer questions like for example, are there known vulnerabilities? If you didn’t give me everything, what did you give me? What did you say I’m going to stop giving? Both of those answers can give you answers about risks. There’s other information too, such as, for example, what licenses does it contain? So that you can determine is that compatible with my use.

Tom Temin: And there is something called the Software Package Data Exchange (SPDX). And let’s go into a little bit more about that and how that can be useful to a buying agency.

Kate Stewart: Sure, so Software Package Data Exchange, or SPDX, has been around now for about 11 years, and has become effectively a de facto standard that we’re actually taking to be a formal standard. It’s in the last stages of becoming a standard with ISO right now. And, it lets you effectively describe those components and the relationships between components, and has standard ways of sharing information about the licensing, and links to things like the National Debt Vulnerability Database, by the CPE numbers, and so forth. It’s an evolving standard, though. The 2.2 version that’s out there right now satisfies the current guidance from NTIA on what a minimum SBOM consists of. So you can use what’s there today, and you can use the tooling that’s around it today, to help you with consumption and creation of these SBOMs. In fact, one of the things that I was just working on earlier this week is, Alan Friedman, Dr. Alan Friedman from NTIA was hosting our second Plugfest. So, I’m one of the co-chairs of the format’s and tooling workgroup in that effort. And, we’ve been encouraging tool vendors and open source projects to do tooling to come together and create SBOMs in certain reference applications, and then consume them and then compare the results in a collaborative fashion. And so we’re trying to do this so we can harden up and figure out best practices.

Tom Temin: So would a best practice roughly consists of let’s say, the buying agencies specifying to contractors, that the SBOM shall be part of this acquisition, and that it shall conform to the standard as defined in, there’s an ISO standard, there is the SPDX standard. And then following that, are there commercial tools that can verify that indeed, this SBOM does all the things that you’ve asked it to do, including conformance to standards, but also revealing all the possible security vulnerabilities and dependencies?

        Sign up for our daily newsletter so you never miss a beat on all things federal

Kate Stewart: Well, it will basically reveal all the software right now. The vulnerabilities are a matter of being able to look up to other databases, but the key is having a clear way of having the components identified, and knowing whether it’s been tampered with or not, and what you’re working with. And once you have that, then you can use the additional information to augment the knowledge base effectively, and […]

Tom Temin: And are there open source tools that you can use that can help you build this verification system, because trust is great with suppliers, but most agencies want to verify?

Kate Stewart: Yeah, the SPDX project has actually created an online free verification tool. So if you wanted to put an SBOM into it, that’s conforming to the SPDX format, it should tell you whether it’s valid or not. Now that doesn’t tell you whether the information inside it is as quality that you want. And realistically, the information that we need to use….some information at this point in time is better than none, which is sometimes the state we have. And the analogy that I really like is it’s all diamonds, and there’s different grades. In the sense that an industrial diamond still useful, it may not be as good as the one you want to have on your engagement ring. But we need to get to the stage where people are able to consume and produce these seamlessly behind the scenes, it doesn’t have to be a special effort. And so open source tooling and open source projects are very much working in this direction. The automated compliance tooling group that’s an umbrella project in the Lynx Foundation has five projects under it right now that are all agreeing to work together to facilitate these workflows. And so there’s projects like OSS Review Toolkit that can be used in a build infrastructure The SPDX tools project itself, which has libraries that people’s proprietary tools as well as the open source tools can use, to make sure they can write the formats and so forth. There’s also Turn, which takes in….we’ll look at a container and try to understand what the contents are. So we actually have three places where there’s types of SBOMs. There is the ones that are prebuild. And that’s just the straight sources. There’s the SBOMs that are created from a build which have the probably the most rich information. And then there is, “oh, I’ve been given this blob, I want to try to figure out what I know about it.” So the post built. So pre, during and post are the three types of SBOMs you can find out there today.

Tom Temin: Okay, yeah, take the flavor you need, I guess for the project. And, David, is your sense that the government is doing this already, or is it way behind industry in using SBOMs as a way to make sure software is good?

David A. Wheeler: I think there are nascent efforts, and I’ll note that you, within certain ecosystems, there’s some software build of materials information already that are used primarily for automating installation. But the problem is that they’re unique to one ecosystem. Many systems are built with many different kinds of software, possibly different programming languages. And those kinds of tools and systems don’t work very well once you start scaling. So it’s not that it’s not happening, but it’s not at the scale. Once you get larger, I think it gets more difficult, and in general lost. I think it’s fair to say that larger, many, many larger projects, I have some idea, but don’t really have a strong clear information on all the components that are within their system. They’ll typically know for example, their lead contractors. Here’s my prime. They might have an idea of the subcontractors within. As soon as you say, “well, what’s all the software within my larger piece of software,” they’ll give you blank stares.

Tom Temin: So we’re gonna need an SBOM of SBOMs.

David A. Wheeler: Well, it’s really just an SBOM. It’s a software bill of materials. Yes, there it’s derived from the bill of materials of some of those suppliers. But that’s okay. A car includes the screw that’s in the engine. And if the screw fails, the car might fail too. So when you’re dealing with the whole system, you need to know about those components, because you want to know about the risks before you deploy them.

Kate Stewart: And to build on that. One of the things is you need to be able to sort of have an SBOM for a system and be able to refer to it from another SBOM. So you don’t try to put it all within one big blob, effectively. So being able to sort of chain through various SBOMs when relevant information is available is probably our way for scaling. But, David brings up a good point in the sense that there’s different levels of knowledge out there about this. And one of the things we’re doing at the Linux Foundation is we’re launching a survey this week, where we’re looking at, okay, what is the state of the industry, be it government, be it commercial, and so forth? Be it worldwide. And so, trying to figure out, and asking….if people are interested in participating, we would certainly welcome their input as to how much they actually know or not know, because right now we’ve got a lot of anecdotes coming from different angles. We want to see if we can put some numbers and some metrics around it to understand where quite frankly, we’ve got the gaps that we need to fill.

Tom Temin: Kate Stewart is vice president of dependable embedded systems. Thanks so much for joining me.

Kate Stewart: You’re welcome. Thank you for your interest.

Tom Temin: And David Wheeler is the director of open source supply chain security. Thank you so much.

David A. Wheeler: Thank you very, very much.

Tom Temin: Both are with the Linux Foundation.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.