Podcast Transcript

Introduction:
You're listening to the RSA Conference podcast, where the world talks security.

Kacy Zurkus:
Hello listeners. Welcome again to this edition of our RSAC 365 podcast series. Thank you so much for tuning in. I'm your host, Kacy Zurkus, content strategist with RSA Conference and today I am joined by my guest Allan Friedman, who will be discussing the trending topic of the Software Bill of Materials known widely as SBOM. Allan will be looking beyond the buzz to see where we've come from and where we're going. Before, I turn it over to Allan to introduce himself, I want to remind our listeners that here at RSAC we host podcast twice a month, and I encourage you to subscribe, rate and review us on your preferred podcast app, so you can be notified when new tracks are posted. And now I'd like to ask Allan to take a moment to tell us who he is before we dive into today's topic. Allan?

Allan Friedman:
Thanks so much, Kacy. I'm basically a failed professor who got talked in joining government about six years ago. My background is in information security and economics, and a lot of what we've been doing in the government. First, I was at small agency called NTIA and now I'm at the cybersecurity and infrastructure security agency. And a lot of our work is to sort of think about how the government can help catalyze better markets for security. Sometimes we talk about a market failure in security, and so a lot of my attention is focused on saying, "What can we do to bring private sector together to find solutions that scale and help fix and make key security problems that we all face?"

Kacy Zurkus:
Fantastic. Allan, we're thrilled to have you here and one thing that Allan didn't mention about himself in his intro there is that he has been a RSA Conference program committee member and last year you had shared the DevSecOps and software integrity track. So, you come with a [wealth 00:02:05] of experience and we rely on your wisdom and expertise to sort of guide our listeners through what they need to know and what they can learn from you. So, I want to start with looking at where we've come from and maybe give our listeners and the understanding of how did we arrive at this Software Bill of Materials or the SBOM that many are just starting to hear about and understand.

Allan Friedman:
So some question, because if you're trying to make progress, you need to understand where we came from and first I want to be clear, this is not a new idea and I also need to be very clear that this is not my idea. The idea of understanding what's in our or supply chain goes back to some of the early advances in the middle of the 20th century about improving industry and manufacturing, which is to say you can't do much to improve your process if you don't understand what the inputs of your process are. These are the foundation of a lot of the great work, the Toyota revolution, and the [Deming 00:03:04] revolution in the middle of the 20th century. And people have been talking about how to apply this for software. In fact, the DevOps revolution really was built around applying some lessons from manufacturing to modern software development.

Allan Friedman:
And a lot of folks have been talking about how we can apply this to software and, you know I want call out folks like Jeff Williams and Josh Corman who've been championing this idea for a while. It was even proposed in legislation back in 2014, there was an idea that said, "Hey, we should require things to have a SBOM" and unfortunately it was not very popular at the time. It met a lot of strong opposition and some of that opposition makes sense. We should be worried about requiring things in legislation or regulation if we don't know how to do them at scale. And that's really what we've tried to do over the last few years is to sort frame out the basics of what a SBOM is. So, what is a SBOM?

Allan Friedman:
It is essentially a list of ingredients for software, right? We know that modern software isn't written byte by byte and line by line. It's assembled and it's assembled from lots of other pieces, which in turn use their own dependency. And a SBOM is a scalable way of communicating that dependency model, that supply chain model at a machine readable way. And the vision is to create a shared approach of how we're going to solve it because if we all do it differently, then we're going to have a bad time. It won't scale and we also need to have a common approach across sectors, right? We know that there are real differences in how we think about software in, say industrial control systems, which is modern applications. But if we're looking across the supply chain, we all use the same underlying software. So we need a shared vision and a shared approach.

Kacy Zurkus:
And this idea of transparency right, is sort of the essence of the SBOM, but it's also true that transparency won't solve all of our problems. So, how can SBOMs help across the software ecosystem?

Allan Friedman:
So, let's use the analogy of a list of ingredients. So, it's not a perfect analogy, but I think it's quite powerful. So if you go to the store and buy a [twinkie 00:05:15] from this listing ingredients, one of the core questions I have is, "Hey, shouldn't we expect that same level of transparency in the software that's running on our critical infrastructure and the software that our businesses depend on, that our governments depend on?" So first we just want that basic level of transparency, but also it's important to acknowledge that the listing ingredients won't magically solve all of their problems, right? If you're trying to protect your family from an allergy, or if you're trying to keep to a diet, or if you're trying to follow a dietary restriction, the list of ingredients, won't magically do that for you. You still need to apply and map that to your processes.

Allan Friedman:
So, we can think about an SBOM as a foundational data layer that helps us across the life cycle of software as we add to it. So I think it can make a huge difference for the folks who build software or develop software, folks who buy software or select software and it can help folks who operate software, maintain software. Let's look at each of those roles because we can follow the ecosystem. The model of developers, it's very hard to claim that you've got a secure development process and you have a true DevSecOps process, if you aren't tracking your components and once you have that data in your system, it allows allow listing and denial listing. It allows you to better understand future maintenance. It can make things more efficient down the road, as you sort of plan your processes once you know that, say a given component is going to be end of life or end of supported.

Allan Friedman:
So, having that visibility really can improve the development process, not just from a security perspective, but from a quality perspective as well, and a cost perspective. So, those of us who select software, buy software, we need to know a little more about the risk that we're getting into and having transparency in the supply chain is really helpful. Often when we're selecting a piece of software, there won't necessarily be a CBE in that piece, right? CBEs are common. They're getting more frequent for smaller software vendors. But if you really want to know what's under the hood, you need that Software Bill of Materials. You need that transparency to be able to do that risk analysis and do that supply chain analysis. Is this software, does it have a lot of the freshest and highest quality ingredients, or is it made up of out of date ingredients? And you may still choose to purchase it, but it helps an organization either purchase or select in the case of open source, what they're going to use.

Allan Friedman:
And then all lastly, we have the folks who sort of are operating software. It's on my network. It's part of my day to day operation and I need to know what's in there so that when a new vulnerability does come out, I can respond quickly and efficiently. And by the way, that's not just about waiting for [practice 00:07:54], right. This to be, if there's a risk to my software, even if it's just a potential risk, I can still take other actions if I don't have the direct support from the software supplier. I can tune my intrusion injection system. I can segment my network. I can work with my threat Intel provider to say, "I'm going to leave this up or I'm going to leave my data in this cloud provider. But the second that we know that there's an attack in the wild I'll hit the kill switch." So there's a lot of it can really drive a bunch of different actions that we need to take.

Kacy Zurkus:
So, I want to follow that twinkie analogy. What do you do in those circumstances where I'm looking at these ingredients yet for some, or even several of them I have no idea what that is? And I'm going to eat it anyway.

Allan Friedman:
I think there are a lot of cases where just as how people approach their not favorite non biodegradable snack, they just say, I'm going to accept that risk. What we want to do is to make sure that there is the ability to understand it and you're right. We don't always have a clear understanding of what's in a list of ingredients. Say for example, Twinkies contain tallow, which means that they are not vegetarian, but you only know that if you understand that tallow is another word for beef fat, right? It's an animal product. So we do need to have some ability to manage that data. The value here that the core here is to make sure that we can link this to other sources of intelligence. A data plane is a necessary, but not sufficient step. One of the analogies I like is CVE, Common Vulnerability Enumeration, right? This is the practice giving a set of identifiers to a vulnerability.

Allan Friedman:
Now, giving a numerical string, CDE 2020/3472, or what have you... That doesn't magically fix anything, right? The vulnerability's still there. Still put my network at risk, still put my customer at risk. But when we have that data at a shared platform and a shared frame of reference, then we can build tools to help support that. And that's really what we're trying to drive is a set of innovative platforms to be able to map my SBOM or the simplest thing is to map from my SBOM to a vulnerability database. So I can see okay. I have these things, are there vulnerabilities in any of them? But it can also be used to do so much more. If I'm worried about a supply chain attack, I can watch open source projects that are critical to a product that I bought to see, okay, does it look like there's been some interference so I can watch?

Allan Friedman:
For example, patterns of commits to see, is there a brand new developer key that started to push a lot of code that's a little suspect? Or if I'm more sophisticated, I can say, let me do the social graph of the developer commits so that I can track, "Hey, it's kind of strange that this 5G open source project suddenly had a bunch of commits from a developer key that's only ever worked on Ruby projects before so maybe that suspect and then an organization can take the appropriate risk based behavior. So it won't solve our problems, but it allows us to have a better and more informed risk based posture.

Kacy Zurkus:
I love that. So Log4j is certainly a vulnerability that many point to, as evidents of the risks and open source software what you just mentioned. Can you speak to this concern as well as maybe share how SBOMs will lay a foundation for resilience?

Allan Friedman:
In case you use the magical word, which is resilience, it allows us to respond more quickly and Log4j certainly was an example where a lot of folks realized the value of understanding what was many layers down in their software. The listeners certainly know everyone spent a lot of December trying to figure out what was in their software and there were a lot of challenges, folks scrambled to both fix it and to communicate that there wasn't at risk and we'll talk about that in a moment. The SBOMs allows folks to see what they have, and if they have a complete SBOM, which is to say, you have your dependencies of your dependencies of your dependencies, then you can actually assert that you can prove the negative. You can say, "We don't have Log4j, we don't need to fix this." And when we do have it, you can say, "You know what, I've I have it."

Allan Friedman:
And in fact, I've even heard from some organizations that did have a SBOM. They said, "Well, one of the things we were able to do is we able to show that we were using a version of Log4j that was so old that it wasn't affected by this vulnerability, but it certainly was affected by some others and so again, that visibility is important. The last thing that I think in terms of a lesson from Log4j is it helped us appreciate the importance of having the dependency graph go down many layers. So if you think of an SBOM as a tree, the top layer, my top level dependencies, and then each of those has dependencies in turn. One of the common questions we get around SBOM is, "Hey, how many layers deep do we need to go? Can we just have our top layer? Is that enough to start?"

Allan Friedman:
And certainly that top layer is better than nothing, but for a lot of the things that we're going to care about moving forward for the next Log4j you really need to have some depth or the tools to get to that depth as quickly as possible, to be able to show where we are at risk and equally importantly, where we're not at risk. And the last thing I want to flag is an issue that is related to SBOM, but it's subtly different, which is that not all vulnerable dependencies actually put users at risk. Lots of software libraries are very large and we all know that compilers are dark arts and so it's entirely possible that the way I use a vulnerable piece of software in my project doesn't actually affect the security of the final product.

Allan Friedman:
So, it's not exploitable it doesn't affect. To help communicate that we're developing something called the vulnerability exploitability exchange or VEX and I apologize that terrible name is my fault. I used it as a place in name. I never quite thought of it. So we've heard all of the vexing jokes about that line, but it is going very important part. You can think of it as a negative security advisory. We know security advisories, where people announce that their products are affected by vulnerabilities. The goal of VEX is to be a machine readable model to communicate that it is not affected. So you can think of SBOM as turning on the dashboard lights, where might I be at risk? And VEX allows you to turn off those lights say, there's an attestation or an assertion from the supplier that says that they are not affected by it.

Kacy Zurkus:
That's great. And to be clear, being able to provide a SBOM is what is going to sort of align with one's ability to work with federal government agencies as part of this zero trust architecture, correct?

Allan Friedman:
Last year's cybersecurity executive order came out last May had a bunch of different pieces where the vision was to use the federal government's purchasing power to drive some change in software to say, "Hey, you need to be this [high 00:15:15] to ride to sort of have your work be purchased or used by the government." And there are a number of pieces there. [Zero 00:15:24] Trust is a big part of that and another part is some basics around software assurance and software security include SBOM. The relationship between Zero Trust and SBOM is an entire another approach, but essentially both of them are built around the idea of transparency and data to inform decision making and automated policy implementation and so that's the vision there.

Kacy Zurkus:
Great. Allen, can you talk to our listeners about the future of SBOMs? Specifically, I want you to help people understand where are the gaps.

Allan Friedman:
We're now in March of 2022, in the state of SBOM is that this is a developing technology, but it is probably not a mature technology. So there is no reason why an organization should not start producing SBOMs for their software. There are lots of tools out there and organizations that start asking for SBOMs and thinking about how they're going to integrate SBOMs into their broader security posture, right. Asset management, development, security, and things like that. However, I also want to acknowledge that we cannot assume full interoperability across the entire implementation model and that's really one of our high level priorities is to emphasize how do we scale this? How do we operationalize it? So that as organizations get more SBOMs from different sources, we can think about the data management layer and the integration across different sets of tools. So, that's where we want to go.

Allan Friedman:
There are some important gaps that we do need to address, and that we at CISA are going to be prioritizing through some public discussions. One of them is around cloud and SaaS. A lot of the benefits around SBOM from the downstream user are around OnPrem software. Now, Kacy, very few people have come to me over the last few years and say, you know the future of software is OnPrem. Even in say the industrial control system space or the medical device space, we're seeing more and more organizations saying, "Well, yes, there're some pieces that are going to be on premise or embedded or device based, but we are seeing more and more attention around application in cloud-based management." So one thing we need to tell better stories around is what does an SBOM mean for software as a service for containers and containerized software and we want to sort of help the community build out some common practices, which in turn will feed into better tools.

Allan Friedman:
Another area that we need to address is how we're going to move this data around? So you can imagine an independent software vendor that has thousands of customers and then you can imagine a software customer that has thousands of suppliers. We need to make sure that we have a good way to move this data around, especially for suppliers that don't want to make their SBOMs public. They just say, I will share it with my customer, but I won't publish it and so this is sort of the SBOM transport question that we need to develop. And then the last thing which ties into the first point about scaling is we want to continue to work with tool providers to make sure that we have interoperability and integration.

Kacy Zurkus:
And I would imagine that automation is going to play a big role in its ability to integrate SBOM into the broader vulnerability and security data ecosystem. How can automation help?

Allan Friedman:
So in 2022, if we're talking about security and we're not talking about automation, we're doing it wrong. Even if you try to sort of say, one question get, "Hey, can you give me a SBOM? Can you show me an SBOM so I can see it?" And you just realize very quickly that these are things that cannot be human readable. So machine generated and machine consumed. On the generation side, the place that makes sense is to build SBOM production indirectly into our tooling, right? So this is something that at the moment of build, just have it spit out since the build process has access to everything that's there at the time, you can sort of [introduce 00:19:29] your SBOM through tools, and there are number of open source tools in this place and there are more and more commercial tools that are coming in targeted specific sectors. Some specific technologies last year, some really smart folks developed the first SBOM for Kubernetes and so now there's... That's a model. So we see automation, really come at generation side of things.

Allan Friedman:
And then on the consumption side, we are starting to see more progress as well. The consumption [lags 00:19:59], because there haven't been as many SBOMs floating around, but there are more and more organizations that are saying, well, how can I build out management tools so that we can track all of this data that's fitting on our networks and then ultimately integrate it into vulnerability management, asset management, CMDB and of course, feeding it back into the development process, a core aspect of DevSecOps is making sure that we have that feedback loop and if you're interested in learning more about the progress of SBOM tools.

Allan Friedman:
I will be giving a talk at June's RSA Conference with [inaudible 00:20:34] from [Lennox 00:20:34] foundation, where we'll be talking about the range of tools out there. What's available today, what we need and the last pitch I'll make is for those of you who are interested in thinking about your own startup. I think there's incredible opportunity. More and more organizations are going to be needing to generate SBOMs and consuming SBOs and to manage this kind of data and so if you're looking for an opportunity, I think there's some great potential.

Kacy Zurkus:
Absolutely. Yeah and we'd love to see those on the innovation showcase someday, right? Allan, thank you so much for joining us today. Before we part, do you have any last words of wisdom for our listeners?

Allan Friedman:
So, if you're interested in the idea of SBOM, we work very hard to make sure that this is a community led effort. This isn't something the government can solve, but the government sort of looks around and say, "We need to make sure that we have the perspective of modern developers and legacy technology and customers and developers and so this is something that interests you, please reach out to us at sbom@cisa.dhs.gov. We'd love to have you involved in helping shape the future of this effort.

Kacy Zurkus:
That's fantastic. Thank you so much again, so appreciate your joining us today, listeners, thank you for tuning in. To find products and solutions related to DevSecOps and software integrity, we invite you to visit rsaconference.com/marketplace. Here, you'll find an entire ecosystem of cybersecurity vendors and service providers who can assist with your specific needs. Please keep the conversation going on your social channels, using the hashtag RSAC, and be sure to visit rsaconference.com for new content posted year round. Thank you all so much.