[00:00:00] DJ Schleen: 

A package of Twinkies is a permanent fixture on Allan Friedman’s desk, which he holds up to the screen during our conversation. A prime example of the underlying purpose of a Software Bill of Materials. The significance? The ingredient list on the package which lets you know what’s inside. 

I always use the can of beans analogy myself – but the Twinkie – well, this is the bad stuff. Seems obvious that it’s better to know what you’re going to consume, then assume you’re eating something healthy.

You can’t help but think of Allan when you think about Software Bill of Materials. He’s been advocating for the use of SBOMs to increase software supply chain transparency and enhance security for years. 

One of his beliefs – 

Organizations should not be using software without knowing what components are inside and any potential security risks. Particularly important in today’s world, where software is an integral part of almost every aspect of our lives, from our smartphones to our cars to our homes. 

It’s National Supply Chain Integrity month and in this episode, we’ll hear about some of the Government’s views on SBOMs, and why the topic is so important. 

Welcome back to daBom…

Hey everyone. I’m here with Allan Friedman. Allan, how are you doing? And, what’s new in the zoo? 

[00:01:19] Allan Friedman: 

Doing well. Thanks for having me on. Very excited about this podcast. I’ve been thinking about the broader topic of transparency for a while, and so super excited that you are pulling together a lot of experts on this.

[00:01:30] DJ Schleen: 

So, Allan, when I think of SBOM, I think of Allan Friedman. You’ve talked all over the world on this topic. If we check out, https://allan.friedmans.org/, I can see many papers, many talks. You’re all over YouTube. What was your first experience like talking about SBOMs? 

[00:01:51] Allan Friedman:

I’ve been talking about it, not because it’s my idea, but because it’s such an obvious idea, and it seems like something that is what we want government and cybersecurity policy to do. Which is to bring experts together to advance the ecosystem.

One of the first talks I gave was probably at RSAC, maybe 2018. The one story I’ll share about that is, there is a horror movie called I believe, Seven and it contains the line “What’s in the box?”, which is a truly horrific scene. But I hadn’t seen the movie at the time. I used the meme of Brad Pitt saying “What’s in the box?”, and half the audience was horrified that I had put that out there. So good rule of thumb that if you’re gonna use a meme, you should know what’s behind the meme. 

[00:02:41] DJ Schleen: 

How did you get to be involved in this SBOM industry and this SBOM conversation?

[00:02:49] Allan Friedman: 

Sure. I started off the world as a, failed academic, failed professor. I was one of the early people at the intersection of computer security and InfoSec, and public policy and economics. The idea of SBOM had been around for a while People have been talking about it. Academics floating the idea back in the nineties. Some folks like Jeff Williams at OWASP, Josh Corman has been talking about it for years. But we hadn’t made any progress. One of the reasons why, was that to really scale our model of software transparency had to apply to literally all software on the planet. We all used the same pieces of software. 

About seven or eight years ago, one of my mentors was at the White House at the time, said, “Hey, why don’t you try joining government?” I was at the Department of Commerce for a while, and now I’m at CISA, which is the Cybersecurity and Infrastructure Security Agency. Essentially we are one of the newest government agencies out there. and we lead the national effort to understand, manage and reduce risk, for cybersecurity and infrastructure.

 …a very brief plug. We’re always hiring. If anyone out there is interested in public service, love to chat more. At CISA our mission with respect to SBOM is to take it and help it scale both inside the US government and across the broader software ecosystem around the world.

How did I get started in SBOM? At Commerce we were interested in saying, “Hey, we want to help security markets.” That carries through in CISA’s mission as well, which is we know that the government can’t solve everything. How do we create market-based solutions? One of the things that we started at Commerce and now are continuing at CISA, is to say, let’s pull together the broad community to determine what we can do. How does it scale. And what are some of the obstacles to making progress. 

 That’s been very successful so far. Until recently, we didn’t have the ability to do this. Now there is an entire marketplace of folks that are helping build, BOM solutions. 

[00:04:54] DJ Schleen: 

Why is the government so interested in this? We have executive order coming out, 14 0 28. Now we have a strategy document improving the nation’s cybersecurity strategy. Why is software bill of materials and supply chain so important to the government?

[00:05:10] Allan Friedman: 

First I’ll say, frankly, it’s embarrassing that we don’t have this today. From a conceptual level, it’s pretty straightforward. I keep a pack of Twinkies on my desk. 

If I go to the store and I buy a Twinkie, it’s going to come with a list of ingredients. Why do we expect more transparency from a non-biodegradable snack than we do with the software that runs our government, that runs our critical infrastructure, that runs our national security systems? 

[00:05:43] DJ Schleen: I

 saw an open source, or supply chain conference, I think it was back in 2022, and you held up that, that Twinky packet.

And I’m thinking, okay, if we’re looking at Twinkies for the software bill of materials analogy, it shows you what you shouldn’t eat in that twinky when you look at the preservatives, right? Those things could probably be around for years. So where did you get the Twinkie idea? 

[00:06:07] Allan Friedman: 

The list of ingredients metaphor isn’t perfect, but it’s been around for a while.

The Twinkie itself I think maybe came from, a woman named Audra Hatch, who’s been involved in the medical device, world for a while, but what I also like about that list of ingredients metaphor is that the list of ingredients by itself doesn’t solve any of your problems. If there’s someone in your family who’s got a serious allergy, that list of ingredients won’t stop them from eating something they’re allergic to. Won’t buy itself, keep you on a diet, it won’t buy itself, a light of a plant-based or religious diet. But good luck doing any of those things without that list of ingredients. 

That’s been very powerful as we explain what an SBOM does and doesn’t do, because I keep having to explain. That the SB in SBOM does not stand for Silver Bullet. It is a data layer on which we’re going to have a lot of great risk tools. 

 In terms of how the government thinks about this we just want to know what’s on our network. The government is attacked a lot. One of the reasons that supply chain attacks have increased and by just about any metric, whether it’s an industry report or government report, we are seeing more people attacking supply chain.

Why? Because we’ve gotten a little better at software security. That means that the attackers, whether they’re criminals, or nation state adversaries are coming after the soft underbelly. The first step of thinking about addressing the software supply chain threat is to know what we have.

[00:07:47] DJ Schleen: 

The government is really setting the standard right with the EO and then NTIA came out with the minimum, fields. Yes. Elements in the software materials. 

[00:07:57] Allan Friedman: 

So how has this been manifest?

 There have been a number of areas where we’ve seen it happen. The executive order came out, 14 0 28. said, Hey, we should have an espon. How do we do that? 

The first step is to say, we need to define what we mean by an SBOM. In 2021, the Department of Commerce publish what they mean by minimums. Now this was pretty basic, because it was something that had to be feasible in 2021. 

Looking forward, memo 22-18 gives CISA the authority to say, when we need to update that CISA will update that. That’s one of the things we also try to communicate is, hey, these minimum elements are very basic that are published today. We’re probably going to have, more enhancement in the future. 

[00:08:45] DJ Schleen: That makes total sense. when you think about some of those requirements, like licensing’s not even in there, but that’s more of a business thing.

It’s not necessarily a security thing, it’s a privacy and IP kind of play on that. but there’s no chance of dependency requirements. It’s only those top level dependencies. And I’ve heard a lot of people asking about those and saying,the government came out with this and it’s These are the minimum requirements. You could put more in there. it’s a start, right? It’s a stake in the ground saying these are the things that you really need to exchange. 

[00:09:14] Allan Friedman: 

The requirement, it says you need to have all of the top level dependencies with enough information to find out who to ask to get more.

The challenge of building out a technical standard says, how deep do you go? Because different software is different depth. Ideally, we’d like all of it, but even that, as you get into different types and nuances of software, gets quite complicated. 

For example, what about runtime dependencies?

Those may be important. Or you may say, you know what, I’m interested open source risk, so maybe I don’t need those runtime dependencies. So there’s going to be some variation. 

One of the key tensions that we deal with in policy is to say, what’s the difference between harmonization, everyone has to follow the same rule, and that’s great for companies and then flexibility, because different sectors have different needs, different technical ecosystems have different needs. 

What’s next in the government, actually implementing this executive order and what those requirements are going to be? Today government agencies can start to ask for SBOMS from their software suppliers, and some are, and also we’re seeing regulators get in. The FDA, which regulates medical devices, has publicly said. that we are going to require every new medical device before it can get on to the market, you have to give them an SBOM and that is going to go into effect in October of this year.

[00:10:46] DJ Schleen: 

So there’s a lot of information you can infer from an SBOM. 

Talk to me about vulnerability exchange. Is there any government advice to transmitting vulnerability information with bill of materials?

And the second one is, how many bill of materials do we need to actually describe a problem? 

[00:11:04] Allan Friedman: 

Those are fun questions that get at the core of what we’re trying to do as we think about broader supply chain risk. Because again, there’s a lot of supply chain risk out there. and here’s where I give a quick plug…

April is actually supply chain integrity month. and there’s a lot of great things happening there. cisa.gov/supply-chain-integrity-month with little hyphens between them. One of those core pieces, and perhaps the most immediate and obvious is software vulnerabilities, right? We don’t want to be buying things that are vulnerable off the bat.

Anyone who’s been around security and software for a while knows that existence of CVE is not the same thing as to hackers are going to eat my lunch. There are many steps in between the existence of a vulnerability and an actual bad incident. One of the challenges is that not all vulnerabilities are exploitable.

On GitHub, Dependabot reminds you of a million different out of date libraries that are in your software. The art and science, and a lot of the great vulnerability management products out there is how do we prioritize.

One of the things we want to do is allow someone to say, hey, this is in my SBOM, but it doesn’t affect my product. Let’s use old example. OpenSSL, Heartblead. Depending on how you measure it, they’re between 600 and a thousand different function calls you can make in OpenSSL, 0.9. Two of them allowed the attacker to read from arbitrary memory.

So if your product, if the compiler strips out everything, but say this pseudo number generator, then you are simply the thing that’s on your customer’s network isn’t going to be effected. So what are we doing about that? 

We’re doing something called the Vulnerability Exploitability Exchange or VEX. It’s separate from SBOM, but it allows someone who’s responsible for a piece of software, whether commercial or proprietary, or open source to communicate, “You don’t have to worry about this.” Whether you trust them or not, that’s a different question. It’s an assertion. You can say, this vendor we don’t trust, but this open source project we do. The last piece here is we want to keep this as fairly independent of the SBOM.

Why? Because as the data is crossing organizational boundaries, there’s no guarantee that vulnerability data is going to be valid. An SBOM is static. It refers to a piece of software as built. If the software hasn’t changed, the SBOM shouldn’t change. 

But the world changes. We discover new vulnerabilities all the time. By keeping this data separate and linking it, then an organization can manage their risk and start to integrate all this data into tools that help ’em do things at scale. 

[00:14:09] DJ Schleen: 

That makes sense. I never really thought of that. Is the mutateability of vulnerabilities, right? Because a lot of folks are gonna sign their SBOMs, they’re going to say, there’s providence and integrity in this, and this is tied to this version. so the documents end up getting tied together. But you’re only as good as your last vulnerability scan. So that vulnerability information could change.

[00:14:29] Allan Friedman: 

One of the ideas I love around this is when a big company says, we are not affected by this vulnerability, they can back that up with a $10,000 bug bounty. Then if a security researcher says, aha, I found a way that you can actually make this happen, then the company will issue an update.

 The world will change and so that’s why we need to build infrastructure that allows us to update these systems rather than locking things in. 

[00:14:57] DJ Schleen: 

Makes total sense. 

 When we talk about that VEX information, the document format, and the document itself, any potential guidance coming out from CISA in that?

[00:15:09] Allan Friedman: 

When we first started having the conversation about VEX, integrated quite nicely into another CISA priority, which is the need for machine readable security advisories. So this is big picture vulnerability world. Today even very mature companies, all of their security advisories look different, but some are in text, some are in pdf, some are in html and it’s very hard to manage that at scale. 

We wanted to move forward on this, CISA has really gotten behind something called the Common Security Advisory Framework. That’s an international standard published by OASIS. and it’s where we’re trying to drive things, especially in critical infrastructure, where we need to build this into tools for less mature organizations. 

Then, CycloneDX, which is a one of the two main, SBOM data formats that we can do this too. It’s great. Once you’ve got more than two implementations, you might as well have ‘N’. And we know that S P DX is also going to be implementing us down the road. There’s a new standard that’s aimed in the the cloud native world called Open Vex. 

CISA’s interest is just making sure they’re all interoperable. We have a a basic vision of what a VEX should be. That wasn’t developed by CISA, that was developed by the community in a way that, the community participated in, CISA convened it. So we know what’s in a basic VEX. People can implement it however they want. That’s the difference between what’s the architecture, versus what’s the actual thing. As long as there’s interoperability between them. You know what computers are good at? Parsing well-structured data. It’s just json at the end of the day. The goal is to say, Hey, we know that people are going to be getting data from different sources. What we want to make sure they can do is they can throw them all in a tool or all in a database and not care about the data format. 

[00:17:03] DJ Schleen: 

iBOMs, infrastructure BOMs, SAS BOMs, xBOMs, *bombs. What’s going on with all that? What’s your take on all these different formats?

[00:17:14] Allan Friedman: 

This is a good sign that there are people saying, let’s have BOMs for many things. One, It means that the idea of the SBOM is taken off and everyone wants to adapt the idea of transparency to their corner of the world. 

 What we need to do is understand what’s the nuance, why is hardware different from software? And there are very real differences. I try to avoid making very broad, sweeping generalizations, but I will posit to say that almost no one can do a general purpose hardware BOM today.

Why? Because when I have a piece of software, I can take the hash so you and I can be confident in the same piece of hash. You can’t take a hash of a DIM. Today, companies that ship hardware actually are decades ahead of us on thinking about the actual hardware that they use. Because you can’t build something without having the inventory to put things together.

But often that is really built around internal SKUs.

What we don’t want to do is tightly bind all of this data because as people innovate and as we develop new ways of thinking about SBOM we want to make sure that we can link it so we need to sort of track all of that and align it. But we need to be very careful about saying, let’s apriori put this in one thing.

 [00:18:34] DJ Schleen: 

If you’re an organization, small, medium, large, doesn’t really matter, and you’re thinking, okay, I’m hearing a lot about SBOMs. What do you tell those people where to start? 

[00:18:44] Allan Friedman: 

So first, great resource we have on the CISO webpage, cisa.gov/sbom.

Two, the easiest thing you can do is start asking your upstream suppliers for SBOMs, It’s free to ask if you run an organization where you’re concerned about security and supply chain, and if they’re listening to DJ’s podcasts, they probably are, the easiest thing to start asking for it. And what else you’re gonna give me, right? If you don’t know what’s in your software, maybe my total cost of ownership goes up. So maybe I’m going to ask for a discount. The second piece is to start to explore what tools are out there for your own software process. There are plugins in everything from Maven Central, to Jenkins. There’s a docker command called SBOM. GitHub just rolled out a free automatic tool that for a given source repo will just give you the SBOM. So there are a lot of great ways to start thinking about this.

 The last piece is, and this is the more ambitious, which is once we have SBOMs, what are we going to do with it? And there’s some simple work to manage for, vulnerabilities. grep is your friend When the next log4j happens. There’s one open source project that a hospital built, just scan SBOMs, just looking against the NVD.

And then the last piece is gonna be integrating this into the stuff you already have. We don’t want people to go out and buy new tools. We want them to use the existing tools. Down the road, this is going to be integrated into vul-management, asset management, CMDB, DataLake, all these things. 

[00:20:18] DJ Schleen: 

What’s next for SBOM? 

[00:20:20] Allan Friedman: We’re starting to see it incorporated in higher level policies. For example, SBAM, is explicitly called out, not once, but twice, and the US government’s cybersecurity strategy that came out a few weeks ago from the White House. It’s a key part of our agenda. We’re starting to see our friends around the world, start to use this. This is not an American issue. We’ve had, international participation from folks around the world from the beginning. and we’re seeing it mentioned in things like the Cyber Resilience Act that’s come out of the European Commission.

 As we continue to integrate it at the government level, we want to make sure that we’re all on the same page. 

CISA is doing this in a way that explicitly is built around industry and community leadership. We’ve got five public working groups that anyone can join that are tackling questions like, “What is the future of VEX? What does SBOM even mean for cloud?”A lot of the value that’s come up has been around on-prem software. What does it mean for SaaS? What does it mean for services? 

We’re talking about how do we get the message out. There’s a working group that’s devoted to how do we communicate SBOM, and how do we enhance and refine the tools. Going from “this is an SBOM” to “here are different types of SBOMS”, here’s ways that people can ask for certain features. 

 There’s a lot of work to be done that the government is doing. And there’s also a lot of work where the government has said, Hey, we shouldn’t be the ones defining this, but we need to be defined. And so we’re, facilitating and convening that conversation. 

[00:21:51] DJ Schleen: 

These working groups that you mentioned, how do we get involved? Where do we go for more information on that?

[00:21:56] Allan Friedman: 

cisa.gov/sbom. Or send us an email to sbom@cisa.dhs.gov. 

[00:22:07] DJ Schleen: 

Perfect. I would love our listeners to take note of that and jump on that and participate, especially if they’re interested in SBOM and also shaping where this goes because we’re in our infancy with this. Where do you think we are? Are we walking? Are we crawling? Are we running yet? 

[00:22:22] Allan Friedman: 

There is such huge diversity, but one of the things that I really love is the number of companies and startups that are really focused on making this a reality. It started off with scanning tools and now we’re working into scaling for modern software DevSecOps processes.

 The two areas that I’m really excited about that are new and there are a lot of great companies that are just starting, are focusing on saying, one, what do I do with this data? Or very specific use cases, right? I’m in the national security world. I’m in the open source world. I’m, worried about, quality or I’m worried about cost of ownership and tech debt.

 The last piece is managing this data. How do I take all this data and integrate it and actually turn it from data to intelligence to action. We’re past the crawl stage. We’re definitely not at mature stage. but we’re in an area where people are starting to say, okay, how do we scale this?

And that’s where we are. 

[00:23:20] DJ Schleen: 

This episode of daBOM was created by me, DJ Schleen, with help from sound engineer Pokie Huang and Executive Producer Mark Miller. This show is recorded in Golden, Colorado, and is part of the Sourced Podcast Network. We use Captivate.fm as our distribution platform and Descript for spoken text editing.

You can subscribe to daBom on your favorite podcast platform. We’re going to be releasing a new episode every Tuesday at 9:00 AM. I’ll see you next week as we continue to diffuse daBOM.

CycloneDX Project
SPEX Project
Dependency Tracker
OWASP
Sonatype