00:00 — Chris Wright
Imagine walking into your favorite coffee shop, ready to order your usual cup of joe. Maybe you notice the tasty looking pastries on display. Now, if you're a regular, you know exactly what to expect from your coffee, but when it comes to the pastries, it's a different story. There's no obvious ingredients list or nutritional information to be found, so do we really know what's in that pastry?

In the realm of software it's not just about our personal consumption. It's a global affair. People from all over the world contribute to and consume the same software. And that raises a fundamental question. Who's actually responsible for security in our vast and interconnected software supply chain?

00:45 — INTRO ANIMATION 

00:54 — Chris Wright
Recent events such as Log4j and SolarWinds incidents have triggered a major shift in how we view software risk and trust. As we begin to answer the question of who is responsible for security, there's one essential piece that emerges to help fortify software supply chains, the SBOM. A software bill of materials is an itemized inventory that breaks down software into its component parts, including any libraries, dependencies, and metadata associated with an application. Essentially, the SBOM provides an ingredients list of what's in our software and where it comes from. SBOMs present a technical solution to a real world problem. Software vulnerabilities have an increasing impact on everyone's lives, and they serve as a foundational element within the broader context of software supply chain security, enhancing transparency and accountability throughout the software development and distribution process.

01:53 — Chris Wright
SBOMs provide a granular inventory of software components and dependencies, but data alone isn't enough to ensure a comprehensive approach to supply chain security, which we see with each new high profile security breach. We're seeing more emphasis on the concept of zero trust with software signing and Sigstore and the growing importance of resources such as CVEs, CVSS ratings, regulatory frameworks like CISA and FedRAMP, and platforms like the Vulnerability Exploitability eXchange, and that's just scratching the surface.

02:25 — Chris Wright
To explore this subject in greater detail, let's chat with Emily Fox, a Red Hat Software Engineering Lead, specializing in emerging technology and security.

02:35 — Chris Wright
Hey, Emily. Thanks for being here with us today.

02:37 — Emily Fox 
Hey, Chris, it's wonderful to see you again.

02:40 — Chris Wright
All right, let's jump right into it. Software supply chains. In this world, things like trust and transparency are key. And just as consumers rely on certifications and sourcing information for food choices, I feel like we can draw some parallels here. We've got things like certified organic and there there's an entire framework to become certified and organic. And in the software world we've got these assurance levels with SLSA. So how do you see these two things connecting?

03:13 — Emily Fox 
The nice thing about SLSA levels and even just some of the labeling and branding associated with food products, it makes it really easy for you to understand what went into it. With SLSA levels, the different levels one through four, they increase in the level of security assurance that you can get in the software that's labeled with that. The other nice thing about it is because of how the framework is constructed, it ensures some level of visibility and transparency so that you as a consumer can independently validate that. It allows you to make sure that you are getting software that meets your organization's needs. It allows you to make much simpler decisions. It also makes sure security team a lot happier too.

03:52 — Chris Wright 
Thinking of my security team, I'll skip the obligatory chips and salsa analogy and maybe go straight to that big picture of building a comprehensive software supply chain, combining an SBOM, software bill of materials, signatures and attestation, so we get this full provenance understanding the software that we have.

04:17— Emily Fox 
That's exactly right. And it's a lot of information. One of the things that we've done really well as an industry has been shifting security left and trying to make it more accessible and presentable to developers to be engaged in security design decisions and secure defaults. Because ultimately, if a software engineer is writing code that has a vulnerability in it, it's likely going to end up in production at some point. So we need to have mechanisms and capabilities to take the metadata produced to make it actionable for when we're monitoring our production environments and when the next Log4Shell happens. We're trying to simplify that process so that vulnerability remediation and management is much simpler, and in the event that an incident happens, we know where to go to find the information so we're not left stumped, scratching our heads as to how this got in here.

05:03 — Chris Wright 
I love that you brought up that production view. My experience of talking to customers and walking through what do we do with our Log4Shell exposure hit these two key issues. One was I didn't realize where I was pulling it in. It's an indirect dependency in software that we're writing. Okay, now I understand that I have it, even that it's relatively ubiquitous, but I have no idea where I've deployed it. And so it isn't enough to just say what your ingredients list is. There's this other bigger, broader picture of understanding that provenance through to production. I think this is a really important part of understanding that full software supply chain.

05:46 — Emily Fox 
And that's actually a conversation I end up having with a lot of community members and even adopters of software is a lot of folks end up focusing on where it's coming from, which makes a lot of sense, but a lot of organizations are doing their own software development on top of that. What they're not considering is what it is that they're producing or what it is that they're developing and where it shows up and keeping accurate inventories of that, because it's not just going to be the open source library that you pull in to allow you to do some really awesome stuff with your application or product. It's going to be the software development that happens on top of that library that pulled it in. What is the application that it's for? What is the service that it goes into? What are the sub components of that? And being able to track them all the way out into the environment where you deployed it in.

These are all important considerations, and if you don't have comprehensive visibility all the way across your stack, from outside of your door where you're consuming it, to when it shows up at your kitchen table, you're going to have a lot of problems.

06:46— Chris Wright 
I am sort of picturing the romaine lettuce in Salinas Valley and okay, now we know there's a problem, but where is it? Which restaurants do you avoid or which grocery stores do you avoid? So that whole picture I think is fundamental.

Now I'm curious, at Red Hat we've been working with software supply chain security from really early on, and we got involved with the inception of Sigstore and other projects around that, but we're starting to see the same kind of questions pop up in a different context around post quantum cryptography, so things like CBOMs. What do you see on the horizon for software supply chain security concerns over the next say five years?

07:28 — Emily Fox 
Well, I think one of the biggest successes that we've had out of Log4Shell and SolarWinds is this entire industry focusing on how do we do software supply chain security in a way that allows different organizations to take their considerations into effect. So we might need to make some tweaking and tailoring, but the processes overall they're identical and they're the same. So what works with SBOM will probably work with CBOM, but ultimately what will happen is we'll end up pushing these further down into the stack because these are one-time kind of long-term fire drills that we need to go through, and ultimately, once we have them solved, there'll be another fire drill that we're working on and this will become second nature.

08:09 — Chris Wright 
I love the vision of spreading the love and pushing this down into really our infrastructure and automation and changing the role of security from the security specialist job to really everybody's job and moving from that reactive view to that proactive view and having security be not about what you can't do, but ensuring you understand your risk in everything that you are doing. So what a cool vision for the future. Emily, thank you so much for joining us today.

08:41 — Emily Fox 
Thanks so much, Chris, for having me.

08:43 — Chris Wright 
While software supply chain security has evolved into a complex and multifaceted landscape, it's a collective responsibility that extends to both users and trusted vendors. As users and vendors work to uphold the principles and practices of software supply chain security, we can foster an environment where trust and transparency thrive. It's a shared commitment to protecting the digital realm and ensuring that software, like pastries at the coffee shop, can be enjoyed without reservation.

09:17 — OUTRO ANIMATION