Technically Speaking (E22): A new software supply chain security recipe

Introduction

Imagine walking into your favorite coffee shop, ready to order your usual cup of joe. Maybe you notice the tasty pastries on display. As 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, raising a fundamental question: who’s actually responsible for security in our vast and interconnected software supply chain?

Recent events such as the Log4J and SolarWinds incidents have triggered a major shift in how we view software risk and trust. To answer the question of who is responsible for security, one essential piece emerges to help fortify software supply chains: the SBOM.

A Software Bill of Materials (SBOM) 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 SBOMs serve as a foundational element within the broader context of software supply chain security. They enhance transparency and accountability throughout the software development and distribution process. Although SBOMs provide a granular inventory of software components and dependencies, data alone isn't enough to ensure a comprehensive approach to supply chain security.

With each new high-profile security breach, we see more emphasis on the concept of zero trust, software signing with 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. However, this is just scratching the surface.

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.

Chris: Hey Emily, thanks for being here with us today.

Emily: Hey Chris, it’s wonderful to see you again.

Chris: Alright, let’s jump right into it. In the world of software supply chains, things like trust and transparency are key. 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’s an entire framework to become certified organic. In the software world, we’ve got these assurance levels with SALSA. How do you see these two things connecting?

Emily: The nice thing about SALSA levels and even just some of the labeling and branding associated with food products is that it makes it really easy for you to understand what went into it. With SALSA levels, ranging from 1 through 4, 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 that 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, simplifies decision-making, and makes your security team happier too.

Chris: 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 building materials, signatures, and attestation gives us this full provenance understanding of the software that we have.

Emily: 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, making it more accessible and presentable to developers so they're engaged in security design decisions and secure defaults. Because ultimately, if a software engineer is writing code with a vulnerability, it’s likely going to end up in production at some point. We need mechanisms and capabilities to take the metadata produced and make it actionable for when we’re monitoring our production environments.

So, if the next Log4Shell happens, we’re trying to simplify that process so vulnerability remediation and management are much simpler. In the event of an incident, 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.

Chris: I love that you brought up that production view. In my experience, talking to customers and walking through what to do with our Log4Shell exposure hit two key issues. One was, "I didn’t realize where I was pulling it in." It could be an indirect dependency in software that we're writing. Okay, now I understand that I have it and that it’s relatively ubiquitous, but I have no idea where I’ve deployed it.

So, it isn’t enough to just say what your ingredients list is. There’s this broader picture of understanding that provenance all the way through to production. This is an important part of understanding that full software supply chain.

Emily: That’s actually a conversation I end up having with a lot of community members and adopters of software. Many folks focus on where it’s coming from, which makes a lot of sense. However, a lot of organizations are doing their own software development on top of that. What they're not considering is what they are producing, developing, and where it's deployed.

Keeping accurate inventories of that is essential. It’s not just going to be the open-source library that you pull in to enable awesome functionality in your application. It’s the subsequent software development on top of that library—down to what application it is for, which service it goes into, and what the subcomponents are. Keeping track of them all the way out into the deployed environment is crucial. Without comprehensive visibility across the entire stack, you’re going to have a lot of problems.

Chris: I’m picturing the romaine lettuce recall—tracing it back to the Salinas Valley and figuring out which restaurants or grocery stores to avoid. That complete visibility is fundamental. Red Hat has been working with software supply chain security from early on. We’ve been involved with projects like Sigstore. Now, we’re seeing similar questions arise with post-quantum cryptography, such as C-BOMs. What do you see on the horizon for software supply chain security over the next five years?

Emily: One significant success from incidents like Log4Shell and SolarWinds is the entire industry focusing on comprehensive software supply chain security. Processes that work with SBOM will likely work with C-BOM as well. Ultimately, these will push further down the stack. Once we solve these long-term fire drills, we'll face new challenges, but these processes will become second nature.

Chris: I love the vision of integrating these practices into our infrastructure and automation, changing security from a specialist task to everybody’s job. Moving from a reactive to a proactive stance on security ensures an understanding of risk in everything we're doing. It’s a cool vision for the future.

Emily: Thanks so much, Chris, for having me.

While software supply chain security has evolved into a complex and multifaceted landscape, it’s a collective responsibility extending to both users and trusted vendors. As users and vendors work together to uphold the principles of software supply chain security, they can foster an environment where trust and transparency thrive. This shared commitment protects the digital realm and ensures that software, like those delicious pastries at your favorite coffee shop, can be enjoyed without reservation.

Keywords

Software Bill of Materials (SBOM)
Software supply chain security
SolarWinds incident
Log4J vulnerability
Transparency
Accountability
SALSA assurance levels
Zero trust
Sigstore
Post-quantum cryptography (C-BOM)

FAQ

Q1: What is an SBOM? A: An SBOM (Software Bill of Materials) is an itemized inventory that breaks down software into its component parts, including libraries, dependencies, and metadata associated with an application.

Q2: Why is transparency important in software supply chains? A: Transparency is crucial for ensuring that all stakeholders—developers, companies, and users—understand what goes into the software. It helps in tracking dependencies, mitigating vulnerabilities, and fostering trust.

Q3: What are SALSA levels? A: SALSA levels are a framework that provides varying levels of security assurance for software, ranging from levels 1 through 4, with increasing levels of security verification and transparency.

Q4: How does shifting security left benefit software development? A: Shifting security left integrates security practices early in the software development lifecycle, making developers aware of security issues from the start. This prevents vulnerabilities from making it to production and simplifies remediation.

Q5: What future trends in software supply chain security should we look out for? A: Future trends include extending existing security strategies to post-quantum cryptography (C-BOMs) and integrating security practices deeply into automated infrastructure. The aim is to shift security responsibilities from specialists to a more general, proactive role across all roles in software development and deployment.