The SBOM Is Coming, with Allan Friedman

While the software bill of materials is nothing new, many people still wrongly assume that the SBOM is a recent creation. They struggle to define, implement, and scale this tool that’s become so crucial to both product security and software supply chain security. Since 2014, the IT industry has worked to scale the SBOM and make it an efficient approach to compliance. These early attempts were stymied, however, because no commonly accepted cross-sector approach to transparency existed in the software world.

Recent regulatory developments suggest that the SBOM will soon become a requirement. The Biden administration launched Executive Order 14028 in the wake of the 2020 SolarWinds attack. A year later, the Log4j attack vector pushed regulatory and legislative efforts even further. Both highlighted the importance of SBOMs in today’s cyber threatscape.

In this new episode of Finite State’s new podcast, “IoT: The Internet of Threats,” Senior Advisor and Strategist at CISA Allan Friedman offers us key insights about where the SBOM came from, where it’s going, and his take on common myths and misconceptions that have threatened to slow its acceptance and adoption.

During this 37-minute episode, Allan and Eric Greenwald, Head of Cybersecurity Policy, and General Counsel at Finite State, examine:

• The history of the SBOM
• The increasing adoption of the SBOM as a security practice
• How SBOMs may be mandated under federal rules
• Misconceptions and myths about the SBOM

All episodes of Finite State’s “The Internet of Threats” podcast can be heard on Spotify, Apple Podcasts, and Google Podcasts. Listen to this episode in its entirety below:

Episode Guest: Allan Friedman, Senior Advisor and Strategist at CISA

Bio: Prior to joining CISA as a Senior Advisor and Strategist, Allan served as the Director of Cybersecurity Initiatives at NTIA, and a Research Scientist at the Cyber Security Policy and Research Institute at George Washington University. Earlier in his career, he also served as a research director at The Brookings Institution and a research fellow at Harvard University.

Full Podcast Transcript:

Eric Greenwald: And now to this week's interview with Allan Friedman, who is the senior advisor and strategist at CISA. He is formerly the director of cybersecurity initiatives at NTIA and has been one of the central figures in bringing the software bill of materials into life in federal regulations. Allan, welcome.

Allan Friedman: Thanks so much, Eric, Happy to be here.

Eric Greenwald: Allan, I do want to spend most of our time today talking about the SBOM because it does play a central role in some of the regulations that are in play right now. And even some legislation that we're seeing starting to move forward on Capitol Hill. But what I'd like to start with is a better understanding about the history of the SBOM, because I think a lot of people believe that it's a recent creation, but its origins date back a bit farther, is that right?

Allan Friedman: Indeed. This is very much not a new idea. And also, I have to be very clear, I did not come up with it. It had been around for a while. It traces its origins, going back to sort of modern industry, the sort of postwar Toyota revolution. And I find it fascinating that a lot of what we think of around modern software, you know, the DevOps revolution also came from heavy industry and innovation. So, the ideas of efficiency and organizational effectiveness are cross-sector. People have been talking about, you know, tracking what you have, for a long time, in the, in the building of physical stuff, right, it's very hard to have an efficient organization of building widgets, if you don't know your inputs for the widgets. And the idea of SBOM has been around for a while people have been championing, like Josh Corman had been championing, for a while. And it also had a lot of requirements in tracking open-source licenses. So right, there are different types of open-source licenses, if you want to make sure that you comply, you need to understand which licenses you're using, which means you need to understand which types of things and folks like Kate Stewart at the Linux Foundation have been championing that for a while. Inside the national security community, people have been aware of it, folks like, you know, Duncan Sparrel who was at AT&T before he retired, were working to say, hey, we've got to track our underlying software components. So, the idea has been around for a while it was even proposed in legislation back in 2014. In a bill that would have required everything that DOD bought to have an SBOM. And this was not a popular bill. To put it frankly, the IT industry, we might use the term, nuked it from orbit. And I think there were some venal reasons for that, such as I don't know how many of even the most sophisticated organizations were really tracking all their open-source licenses and so no one really wanted to sort of admit that they had been inappropriate, or, you know, or were using out-of-date software. But, also I think there are we should be cautious about putting things into regulation that we don't know how to do at scale. And I think that was one of the challenges of early attempts to push for this in regulation is if we didn't have a commonly accepted cross-sector way of thinking about what transparency in the software world means it's very difficult to scale this and make it in an efficient approach to compliance.

Eric Greenwald: Well, there continues to be a reasonable amount of fear and loathing surrounding the SBOM. But my sense of it is that there has in the I guess it's now eight years since it was at least initially proposed in that legislation that you reference. There's been advancements that enable SBOM to be to operate at scale. Do you feel like the concern that people have about the SBOM is misplaced?

Allan Friedman: Well, there are a host of concerns that we can hopefully get into. But I think one of the things that we tried to do at NTIA was to create this shared vision of when I talk about SBOM and you talk about SBOM, are we talking about pretty similar things? And of course, there are going to be uniquenesses and that's one of the challenges of building out something that applies to literally all software is you need it to be harmonized enough because we all build on the same software, the same open-source material, but at the same time, there are real differences between, you know, a modern DevSecOps shop that's building containerized applications, and you know, critical infrastructure manufacturers that are still shipping very large, heavy pieces of equipment that go boom if something goes wrong, right, the cultures are different, the requirements are different. And, so, the vision is to create the shared vision. And then the other part is to make sure that there are some technical standards. And today, there are two data formats that we use.

Eric Greenwald: Is two data formats enough, given the variance that you've indicated in the needs and functions for an SBOM? Is it too many? Should there be only one?

Allan Friedman: There's certainly enough people who said, hey, wouldn't it be great if instead of two, we had one, they're both good. So, we're talking about SPDX, and CycloneDX, SPDX. Under the Linux Foundation, CycloneDX comes out of OWASP. They both have great communities. They're both open. Anyone can get involved and contribute. The benefits of having two standards is it means that we've got some natural competition, and some natural, which drives innovation, drives responsiveness. And the concern that a lot of people have is that it will say, I might get SBOMs in two different formats, and that's true, right? Any large organization, given the diversity of suppliers, you can't dictate everything to your supplier, it might be in both. Most of the tooling suppliers that I talked to say, well, we're just going to do it in both because, you know what, computers are good at handling well-structured data. And so right for the, there are certain features in each that aren't quite implemented in the other. But one, for the basics, we call the minimum elements of SBOM, both are just fine. And translation between them is something we're working to make sure holds as the field advances. The bigger picture, we're sort of trying to be honest, is we haven't quite mastered complete scale and operationalization. Right, there's no reason that organizations can't start generating and using SBOMs today. But one of these sort of remaining steps is really to demonstrate that, okay, two tools look at the same complex piece of software, and can produce similar enough SBOMs, that we have interoperability, and that the data as organizations get multiple SBOMs across their supply chains, they can actually integrate that data into their existing security tools, their existing risk posture. And that's one of our priorities here at CISA, is to advance the idea of tooling interoperability.

Eric Greenwald: I do want to talk a bit about the trend towards SBOM being a requirement. But you mentioned that companies are gravitating towards this. To what extent are you seeing adoption of the SBOM as a security practice, not even necessarily in anticipation of it being required, but because it represents a good security practice?

Allan Friedman: We are seeing it advance on its own merits in different corners of the ecosystem. And let's look so again, at some of the more modern side of things in the cloud-native world, people recognize that tracking your components is absolutely critical for thinking about security and supply chain risk management. And, you know, last fall, some folks built the SBOM of Kubernetes. So, we have, you know, that core piece of software. We now know what's in it, and that every time they update it, we update the SBOM. Very recently, we had an SBOM command in Docker. So now, you can actually, sort of, as you build your container, you can create your SBOM. So, we're seeing it in that space. We're also seeing it for security reasons and efficiency reasons in a number of other industries, right. And I think Log4j last December highlighted that, where organizations realized we need to quickly and easily understand: are we affected and where are we affected? And this is not just at sort of the scalar organizations; this is a pretty classic old-school problem. One of the leads in product security for Schneider Electric, a very important manufacturing and critical infrastructure supplier, said, you know, if we had SBOM across our product families, it would save us 1000s of hours a year. because whenever new risk does come out, they have a very good hard-working product security team. So, they need to figure out where they're affected. And, so, it's not just security. It's a dollars-and-cents issue as well.

Eric Greenwald: You mentioned Log4j. And I think we've seen that that is a factor that's been driving the industry towards the SBOM, and certainly has also been pushing regulatory and legislative efforts farther and faster. But if we look at the Biden administration’s Executive Order 14028, that was launched well before the Log4j vulnerability came to light, and in general, we think is considered to be in reaction to the SolarWinds attack, which is it fair to say that that also highlighted the need for the importance of SBOMs, even if not quite the same widespread way as Log4j. But, you know, in a way, that clearly shows the impact of software that, where if you don't know what's in it, you don't know what vulnerabilities may reside.

Allan Friedman: I think the attack against the company SolarWinds, the sunburst attack highlights an important consideration around SBOM, and indeed all Software Assurance, which is to say, hey, for a lot of these sophisticated, intentional attacks, there isn't going to be a single magical fix, right? So SBOM would not have prevented the SolarWinds attack. And it would not have even led to the direct detection. But all of the things that we know that would have prevented it and enabled its rapid detection required SBOM, right? So, it is the necessary, but not sufficient piece, similar to the other aspects of Executive Order 14028, which sort of lay the foundation for broader Software Assurance and broader supply chain visibility. And, so, the vision is to say, how do we promote an ecosystem? And I think the White House said, hey, SBOM is a good idea. There's momentum behind it, the next step is to use one of the lighter regulatory touches that we have in the policy world, which is to say, we're not going to dictate what industry must do, right? This is traditionally the regulatory tool for things that are the safety critical building. Instead, we're going to use the power of the purse, we're going to say all software that the US government buys must have the security features, including SBOM, and in case any of your listeners aren't familiar, the US government buys a lot. And, so, this is it is something that gets the attention of the major software suppliers. And also, given that SBOM isn't something that folks do unilaterally, right, that we need to look up the supply chain. It starts the ball rolling into the open-source world, into the software supplier world, the people who make sort of the intermediate components that are used in modern software.

Eric Greenwald: In the wake of Log4j, then, I think we’ve certainly seen an acceleration for, in the push for, adoption of SBOMs, whether as a matter of voluntary practice or in regulatory matters. The Patch Act is bipartisan legislation that was proposed on Capitol Hill in both the House and the Senate just recently, and it requires an SBOM for medical device manufacturers when they're going through their pre-market regulatory review process. I am curious to know whether you see this as part of a broader and accelerating trend that we are … that SBOMs are inevitable and that they're coming whether as a matter of mandated federal legislative or regulatory requirement, or through private party contractual provisions.

Allan Friedman: I think we are going to see it, I think the, you know, the SBOM is coming. And that's great. The form it takes is going to sort of move a little bit by different sectors. So, I'll give you an example of sort of some voluntary world, the automotive sector, car manufacturers, they get supply chain, right, there are very few sectors that have a sophisticated approach to a physical supply chain. And they're starting to appreciate that software is very much part of that. And, so, using the Auto ISAC, which is the Information Sharing and Analysis Center, that allows the industry to communicate amongst themselves without having to be public. They're saying, hey, let's understand what SBOM means for us. And so, by the time their regulators start to require it and SBOM is something that was acknowledged in voluntary guidance in the automotive sector, so, by the time the regulator gets around to enforcing it, they'll sort of already have it. I do want to call out the FDA, which regulates medical devices because they've been an early component in saying having supply chain visibility is very important. And there aren't too many places where the healthcare sector is really on the leading edge of cybersecurity. This is one of them. And part of that is due to the leadership of, you know, government experts at the FDA. Part of that is due to both the major hospitals and the medical device manufacturers who realized that the sector was far behind. This was an area where they could collaborate. And they've been working as an industry sector for the last few years to say, what does SBOM mean for us? Let's try it. Let's iterate. So, we'll start off very simply, and then we'll get more and more sophisticated as our understanding of SBOM matures.

Eric Greenwald: So, we discussed earlier, the fear and loathing that some entities have of the requirement to produce an SBOM. And there have been plenty of misconceptions and myths about the SBOM that have popped up over time. One of the concerns that I've certainly heard articulated is that once information is available in an SBOM that attackers will use it as a roadmap to, if not identify vulnerabilities to at least identify where those vulnerabilities are resident and then target their attacks on those pieces of software. What is your response to those concerns?

Allan Friedman: Well, you know, it's 2022. So we don't just talk about attacks, we … talk about threats, we threat model. And, so, let's start by looking at sophisticated adversaries who are determined to move forward. And they don't need SBOMs, right? Source composition analysis tools are pretty straightforward. And you know, JIRA is free, or Git is free, excuse me. So, you know, anyone who wants to know what's in a piece of software can find out with some basic resources. At the other end of the spectrum, right, we've got our distributed automated attacks, right? … The … ransomware gangs that are spraying and praying, and they don't care about what's in a given piece of software. They just want any toehold. The people that need the roadmap are the defenders to say, well, I've got my asset management, but now I still need to understand what's under the hood. Because someone could still find network purchase based on you know, an underlying component rather than a piece of software that may not have a CVE in it by itself. So, is there possibly some space between with residual risk? There may well be, but I think the benefits to helping the defender understand what's at risk are much higher.

Eric Greenwald: So, I guess to summarize, it's … the SBOM is absolutely essential for the defender, but attackers don't actually need it.

Allan Friedman: I haven't seen a lot of evidence of that case. Now, if we take all of our SBOMs and put them in one pile, defenders really want that. Because we need to know where we need to be investing, right? Especially, you know, what are the most important pieces of software that we don't know are important? So that we can start to have more Software Assurance, we can understand the risks if there's, you know, only one maintainer, etcetera. But that also is going to be of interest to the attacker. And, so, if we do collect this data, we need to understand how we're going to use it and how we're going to protect it and make sure that the defenders are moving quickly with that information.

Eric Greenwald: This is another area of concern that I've heard highlighted, and that is the notion that information contained within SBOMs becomes publicly available. But do I take it from what you're saying is that any individual SBOM becoming public, not such a big threat, every single SBOM becoming public, much bigger threat?

Allan Friedman: Well, and again, every single SBOM becoming public, or at least having some visibility from sort of the, you know, the, whether it's the Open Source Security Foundation, or you know, a government, there's power there to sort of make sure that we can target our defensive aspects. But also, there's no requirement that a given SBOM is public. So, right, we know that there are gonna be organizations, especially the beginning. And so I'll share with my customer because I have to. But that's different than saying, I'm going to broadcast that around the world. The one thing that we do need to make sure that we have thought through is what is that? What is scalable access control look like so that you have a large manufacturer, hundreds or thousands of customers, they're still going to need to get that data to their customers. And that's not really a solved problem today.

Eric Greenwald: Well, and I guess this gets to the point that you were making early on about the importance of only implementing an SBOM and regulations once we're in a position that it can be done in a scalable, reliable, and repeatable way. Is that right?

Allan Friedman: You said it much more succinctly than I did. We are always trying to understand what are the parts of this that we don't know how to do so that we as a community can help move things forward. This isn't something that the US government can really unilaterally solve, we want to bring the different parts of that community together to say, what are the common solutions? And what's going to scale? So right now, we can do SBOM generation. Is, right, we know how to do it at scale, there are tools to do it at build time. There are tools to do it after build with binary analysis and source composition analysis. One of the things that more broadly we're going to have to figure out is how do we move security metadata around? And at a certain point, a lot of cybersecurity problems just devolve to data management problems, say, How do I get it down the supply chain? And then once I have it inside my organization, how do I manage it and connect it? That's plumbing. [It] doesn't mean it's not a hard problem, doesn't mean it's not an important problem. But it's the sort of thing that different organizations are going to try to solve differently. Some of them will just say, I can roll the scripts myself, some of them will say, hey, this doesn't make sense for me to do myself. Let me turn to some of my suppliers that are already thinking about this.

Eric Greenwald: Well, Allan, thank you very much for your time talking about this. I am hoping that we'll be able to have you back sometime soon to talk more about the SBOM. I think it's going to be a recurring topic of conversation. And I've even had a separate conversation with Josh Corman to see if we can have the two of you on together to chat a bit and do a little compare and contrast of your respective views. I do thank you very much for working with us on the podcast and hope to have you back soon.

Allan Friedman: Great to chat Eric. Thanks so much.