How a bill of materials prevents an agency from buying a bill of goods

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

SBOM. It sounds like a play on a word you can’t say, but it stands for software bill of materials. And that big executive order on cybersecurity from last May urged federal agencies to understand and use SBOMs as part of their risk management efforts. Joining me to explain exactly what a software bill of materials is, and how you can use it, the chief technologist for cyber and technology at the Foundation for the Defense of Democracies, Dr. Georgianna Shea spoke to Federal Drive with Tom Temin.

Interview transcript:

Tom Temin: Dr. Shea, good to have you on.

        We want to hear from federal technology leaders about how you are addressing current cyber demands and how your agency is making the most of its resources to improve its cyber posture. | Take our quick survey

Georgianna Shea: Thank you for having me.

Tom Temin: And let’s begin by discussing a little bit of your own background, because you’ve spent some serious time in the Defense Department on cyber issues, correct?

Georgianna Shea: Correct. I’ve spent over 20 years working in DoD, predominantly on cyber warfare related issues. So really trying to understand what the adversary is doing, how they’re doing it, and how we protect our systems.

Tom Temin: And they probably have SBOMs. So let’s begin at the beginning, then. What precisely is a software bill of materials?

Georgianna Shea: So just like in regular manufacturing, where you have a bill of materials for, let’s just say, manufacturing of a vehicle, it’s the identification — a list of all the parts that go into the product for software.

Tom Temin: I mean, software is made of lines of code, and then it’s compiled into a runtime application. So what can you say about it other than here’s 10,000 or 100,000 lines of code?

Georgianna Shea: Well, so code is reused just like tires on a vehicle. So when you get a vehicle from a manufacturer, they’re not going to make the tires themselves, they’re getting them from someplace else. That’s the same way software is developed. Over 75% of all software is open source. So even though you may be contracted with an organization to build software, they’re going out to open source repositories and pulling in already functional pieces of code into that larger package that you’re buying from them.

Tom Temin: So relative to say, 30-40 years ago, when things were hand coded by programmers in C, or Cobalt, or one of those earlier languages. Today, pretty much it’s an assemblage of open source objects, fair to say?

        Read more: Technology

Georgianna Shea: Correct.

Tom Temin: Alright, so the software bill of materials, then, lists what those objects are, and the sources of them?

Georgianna Shea: Yes, so the software bill of materials lists, you know, who developed it, where it came from, what particular software pieces are in there, the different fields. And this is one of the things that came out of the executive order — to go through and standardize what those fields are, because it hasn’t been one of those widely used standardized practices. So if I were to request an SBOM, I’m sort of picking the fields that I want, or someone’s giving me an SBOM and they’re giving me the fields that they want to give me. So now we’re trying to go through and make it more of a uniform practice that’s accepted universally.

Tom Temin: And if I buy a commercial product that I’m going to adapt for federal use, or DoD use, how many items are typically on a software bill of materials. Is it like 50? 10,000? 100 million? What kind of order of magnitude are we talking about?

Georgianna Shea: Well, it depends on the size of the software package that you’re buying. But I can tell you that I did a small pilot project with an SBOM. I took an open source publicly available module of code from GitHub online that is commonly used and incorporated into other types of software. And there were seven direct dependencies. So the S file might have been seven lists of ingredients or components and the details behind it. But then once we started to dig into those seven and did the analysis, we then found that there were 900 dependencies, and this was a relatively small code that we had used. So if this is something much larger, you can imagine exponentially how many different pieces of code and writers and contributors are then actually making up the entire software package.

Tom Temin: So each function, in other words, say the login function, or the data call to these five databases function that might be a standard function that exists as code, each one of those could have hundreds of possible dependencies that you would need to be aware of.

Georgianna Shea: If not thousands, or tens of thousands, depending on the size. Yes.

        Want to stay up to date with the latest federal news and information from all your devices? Download the revamped Federal News Network app

Tom Temin: And what form does the SBOM take? And such that one can make sense of what you’re looking at with 100,000 dependencies or a million dependencies?

Georgianna Shea: So what form does it take? There’s, I guess, I would say that in a generic sense that there’s the manual version of an SBOM. If you would require one I can go through and, you know, write something up in Excel or give you a list on a piece of paper. But that’s going to be pretty useless if I wanted to actually incorporate it into you know, machine readable processes, configuration management. So the recommendation that came out of the executive order and my recommendation after doing this pilot was definitely a machine readable format. And there’s a couple of different formats out there. The CycloneDX, the software package data exchange, SPDX and software identification tags.

Tom Temin: We’re speaking with Dr. Georgianna Shea, she’s chief technologist for the Center on Cyber and Technology Innovation at the Foundation for the Defense of Democracies. All right, then let’s presume that as an agency, as a buyer, I’m receiving a machine readable software bill of materials for my new whatever package. How do I then incorporate that into my risk management for purposes of cybersecurity and assurance that that software is not sending all my data to China?

Georgianna Shea: Well, there’s a couple different ways you can use the SBOM. One is for risk management. Most organizations are following the NIST cybersecurity framework. And that starts with identifying. So it’s identify, protect, detect, respond, restore. And a lot of attention gets put on the protect piece, what kind of protections do you put into your system, but little attention really gets put into the identify piece of it? What are you protecting, how big is your enterprise, what’s within your systems? So within the identify aspect of their framework, your asset management, your business environment, your governments, your risk assessment management strategy, it’s understanding what’s included in your software, and then developing that risk management plan accordingly. But if you don’t know where it’s coming from, then you really don’t know if it’s secure. So you should plan accordingly.

Tom Temin: Well, are there some sets of whitelists, for example, out there that you can compare against your SBOM, and find out where the modules that you might be worried about are located within this package, and where the ones you can trust are?

Georgianna Shea: I don’t know of an essential SBOM repository yet. But, you know, I kind of see that emerging on the horizon. Once we kind of get this standardized and people start using it, then you can compare that. Once SBOMs are, you know, continuously monitored, and you can look at what the risks are associated with those different modules, then people can pull from those type of resources which aren’t established. But yeah, just to touch on what that means that, you know, the whitelisting or the vulnerabilities, when software is typically looked at right now to determine is this secure, there will be a scan or review of the software to determine if it has any known common vulnerabilities or exposures — the CVEs. And those are the known vulnerabilities in software, like the Solar Winds, for example. Last year in 2020, there was not an associated CVE with the Solar Winds Orion platform, because we didn’t know about it. But that didn’t stop the backdoor from being there. It was still there. However, in 2021 now, when you look at Solar Winds, there is a CVE associated with it, and there is a backdoor. So now we can say, oh, if we see that CVE, we don’t want to use that software. What the continuous monitoring allows you to do when you have an SBOM, you can dig into those components of the software, and do that analysis and look at those early lead risk factors that may lead to a vulnerability identification. You know, one being that maybe the person who’s committing the code on the off premises repository that you’re pulling it from has a following from the Chinese offensive cyber organization, maybe that’s the guy that you don’t want to get code from, maybe we don’t want his little time function module in your code, or the fact that there’s not a lot of maintenance time put into the software, or there’s license issues between the different modules that you’re seeing. There’s a lot of other factors in software that can lead to issues that become vulnerabilities and could compromise the integrity of the overall software package. So it’s difficult when you say, you know, whitelisting, because we can only go through and whitelist identify what we know. And we don’t know until we discover something like a backdoor in Solar Winds.

Tom Temin: Yeah, those pesky unknown knowns, or known unknowns, whatever they call them. So for example then, you could also tell, though, that if the Solar Winds components are in there, if it’s 4.5.1 — I’m making this up — it should be 4.5.2, which is post breach, and you could at least find out and say to the vendor, well, can we insert 4.5.2 here, and then we’ll be okay? .

Georgianna Shea: Right, so that’s a great example. Or another example, Huawei is on the list of OFAC — the Office of Foreign Asset Control –as a sanctioned entity that we don’t want to use their technology. So maybe there’s some Huawei libraries floating around and some of this open source code or modules that you’re ingesting, and you don’t know that so now you’re actually having legal issues that this is discovered, but it wasn’t reviewed, and you don’t really know where this is coming from.

Tom Temin: And in receiving an SBOM, who should receive it, what function in an agency should be responsible for using it for risk management? Is it the chief information security officer, is it the contracting officer? Who should really assume the ownership of the SBOM?

Georgianna Shea: Well, I don’t know about ownership. And I think that would depend across different organizations. But I do want to kind of pull on what you just said about the contracting officer. So we’re talking about security and the risk management process with SBOM as a tool, but there’s also a compliance piece of this as well. So if I’m purchasing software from an organization, I’m going to have requirements with that software. I want it to be secure. I want it to not have Huawei Technologies. I want it to meet certain requirements. Like I want it to be maintained, I want it to be updated, all those kind of things. But there’s really not a way to go through and ensure that compliance. But with an SBOM, if you’re conducting continuous monitoring on that SBOM, you can see what’s happening to those software dependencies that software package as it’s being developed and once it gets delivered, so you can actually then go through and ensure compliance. So from the contracting standpoint, it’s a vital tool. From the CISO, the security officer, it’s also a vital tool because you can then incorporate it into your defensive cyber operations. You know, I talked about the identity function of the NIST cybersecurity framework. If, you know, the news came out tomorrow about the Solar Winds hack and the Orion platform being breached, I don’t know if I have Orion platform in my network. Maybe I know I have Solar Winds, but I don’t know Orion. I don’t know that word. But if I have an SBOM that lists all of those different things, as the threat model that I’m following is being updated with new discoveries of vulnerabilities, I can quickly go through and assess what’s vulnerable within my own enterprise.

Tom Temin: So over time, then you could almost build an inventory of SBOMs of your entire software inventory. And that might, I would imagine, help guide not only risk management, but also the continuous process of pruning applications that you just don’t need anymore. And agencies are always dealing with, what do I do with all these applications that, you know, maybe one small group still uses after 20 years.

Georgianna Shea: Correct.

Tom Temin: And what’s your sense of industry best practice at this point with respect to the use of software bills of material?

Georgianna Shea: So industry practice right now, the software bill of materials from the developer could be closely integrated with the configuration management process of software development. So for them, it’s a tool to go through and track what’s being developed, where it’s coming from, when it’s getting changed, the integrity of each new update, and then that same list of information could be handed off to the customer, which then, you know, as I mentioned, is great for compliance, great for risk management, great for your defensive cyber operations capabilities.

Tom Temin: All right, and what about the agile methodology that companies and industry and government are so wildly embracing, as you develop these short scrum related modules of functionality every two weeks or every two months? Should a software bill of materials be generated along with those, so that even though you’re not buying a commercial package, you’re doing development in modules? Should each module have an SBOM that you can refer to later on, maybe two years from now when you’ve got a great big piece of software finished?

Georgianna Shea: Well, I like things being recorded, like accountability. I like provenance of software. So I would say yes, and when you talk about agile, there’s been a lot of agile development, a lot of move towards DevSecOps, your development security operations, software development. So it is that, you know, CI/CD pipeline, your continuous integration, continuous development of little pieces of code coming out and producing different functionality. That’s what they’re doing in-house. Actual developers, they’re still going through and adding on that the open source, so that might not be going through their pipeline of development. So what they’re doing in-house and what they’re taking from out of the house to augment that pipeline, you know, should definitely be captured in their SBOM. And there’s, you know, different ways you can do this. One of the things I talked about in the pilot was incorporating some type of, you know, blockchain capability where, you know, each addition becomes a block, and then you have that chain of custody, like, you know, block-to-block assurance of, you know, what was done and what’s there. So you know what you’re getting at the end for the delivery

Tom Temin: Got it. So that means that some part of the metadata there could even point to the specific developer that worked on a module. Yeah, absolutely. All right. And the other question I had was with respect to cloud applications. A lot of agencies are saying they are — in many of them are, in fact — moving to software as a service, using commercial providers for various software functions. Should you be able to demand from the cloud provider or the owner of that software that you’re not buying, but you’re really using on a per user/per hour whatever basis, should you be able to get an SBOM for those packages?

Georgianna Shea: I believe if you’re paying somebody for something, you have the right to demand whatever you want. So I don’t know if they will comply with that. But that’s my personal philosophy. And if I’m going to integrate their services or their software into my system, and it’s going to go through and extend my attack surface area, then I’m taking on a risk that I’m responsible for, so I’m going to try to mitigate that the best way I can.

Tom Temin: And the other big thing that everyone’s talking about in that may executive order on cybersecurity is zero trust. And what’s the bridge between SBOMs and zero trust?

Georgianna Shea: Well, NIST has a document out on zero trust and what the tenants are on zero trust. And I was going through reading these, and, you know, there’s one in particular and I’ll read it: It’s “the enterprise monitors and measures the integrity and security posture of all owned and associated assets.” So you when you ask how to zero trust work with the SBOM, the software is your asset. That’s the lifeblood of your organization, your enterprise, your systems. So if you don’t know the security posture of your software, then you’re fundamentally failing from the very start. So zero trust is a concept that can apply there, you know, and enabled through the SBOM. One of the other tenants for zero trust: “the enterprise collects as much information as possible about the current state of the assets, network infrastructure and communication and uses it to improve the security posture.” Well, again, you know, the software is an asset of your enterprise and of your system. So you should be collecting as much information as possible. And when I say as much information as possible, you know, I’ve already talked about how the CVEs are a point in time and we may not know what those vulnerabilities are yet. So there’s a number of different other types of attributes within the software that give indication that this may be a shady, high-risk software that you don’t want to incorporate into your low risk tolerance system.

Tom Temin: Alright, so then the message for agencies is get on top of your software bills of material so you don’t get software bills of goods.

Georgianna Shea: Yes.

Tom Temin: All right. Dr. Georgianna Shea is chief technologist for the Center on Cyber and Technology Innovation at the Foundation for the Defense of Democracies. Thanks so much for joining me.

Georgianna Shea: Thank you for having me.

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