Everything You Wanted To Know About Securing The Software Supply Chain

You know you need to secure your software supply chain. Everyone’s telling you that these days - your executives, your vendors, even the United States government. Your organization has an initiative to do so, or maybe they’ve brought in an expert to help you achieve this goal. But hold on a minute - do we have a shared understanding of what a software supply chain is, and what exactly makes it secure?

Hopefully, you were able to join the Linux Foundation webinar Cloudsmith hosted last week with Dan Lorenc, the founder and CEO of Chainguard. The focus was getting back to the basics of what a software supply chain is, and why it needs to be secure. If you weren’t able to attend, or if you want reference material to share with others, here’s our recap.

The webinar addressed the following topics:

• What is a software supply chain?
• Why are we securing them now?
• Why is this such a hard problem?
• What does a secure software supply chain look like?
• What are Cloudsmith and Chainguard doing to help solve this problem?

In the most basic terms, what is a software supply chain?

Simply put, a software supply chain includes literally everything that contributes to making your product - the source code, dependencies, systems, tooling, environments, processes, and even the users who contribute along the way.

Dan McKinney, Developer Relations at Cloudsmith, said that a good analogy for understanding the software supply chain is to look at another industry that also deals with supply chains - manufacturing. The manufacturing industry has a standardized way - a Bill of Materials - to detail all of the inputs into their final product. They need that because they need to ensure they have the materials required to build the physical product and that they have met safety and security standards along the way.

The software industry doesn’t have the same regulatory controls as manufacturing, though. There is no centralized authority ensuring provenance and traceability are enforced (though we may see this in the future). This gap has made space for the rise of many interesting projects designed to help make safety and security so easy, it becomes the default. Projects like Sigstore, The Update Framework, in-toto, and SLSA are just a few examples. We’ll touch more on these projects later in this post.

Why are we securing our supply chains now?

As Dan Lorenc said in the webinar, there have been voices advocating for securing software supply chains for years now. But a handful of events in the last 24 months have caused organizations to wonder why they’ve waited so long to get started.

The SolarWinds Hack

In the spring of 2020, SolarWinds unknowingly started to send out software updates that contained hacked code. This is the event that really got everyone talking about “software supply chains”.

SolarWinds is an IT management tools company that helps businesses manage their networks, systems, and infrastructure. In early 2020, threat actors found a way into the build system at SolarWinds and managed to add malicious code into one of its products, a performance monitoring platform called Orion. Subsequently, when Orion customers updated their installations, the malicious code was included in the update, giving the threat actors a backdoor they could use to install additional malicious software, exfiltrate sensitive data, or spy on the companies themselves.

Big organizations found themselves impacted - Microsoft and Intel for example. Overnight, everyone was talking about software supply chains and what needed to be done to secure them.

The Dependency Confusion Attack

In February 2021, security researcher Alex Birsan revealed that over 35 major companies were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

This type of attack is known as dependency confusion, as well as package namesquatting, and it relies on package management software to download the malicious version of a package being used as a dependency. The key is to create an external library with the same name as a private internal library that a particular company uses in its development pipeline. There are then several ways that a package manager can end up accessing the malicious external version of the library.

This incident shows why it is so important to make security so easy, it happens by default. It only takes one developer with a poorly configured system for the malicious library to gain entry to the organization.

Executive Order on Improving the Nation’s Cybersecurity

On May 12, 2021, President Joe Biden issued an executive order to begin creating federal standards for security of the software supply chain. The Executive Order on Improving the Nation’s Cybersecurity orders the Department of Commerce and the National Telecommunications and Information Administration to publish minimum requirements for a Software Bill of Materials (SBOM). The SBOM is a record of the components and packages used in building software, whether open-source or commercial, intended to help software end-users to analyze vulnerabilities or issues with the licenses.

NIST Special Publication 800-218

In February 2022, The National Institute of Standards and Technology released Special Publication (SP) 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. At the start of 2022, the White House brought together government employees, private sector stakeholders, and members of the open-source community to discuss how to improve the security of open-source software and software supply chains. This publication is the result of those discussions, and it recommends a core set of high-level secure software development practices called the SSDF that can be integrated into each SDLC implementation.

Why is this a hard problem for organizations to solve?

One challenge is that open-source software is foundational to software development, and so for an organization to secure their supply chain, they will need all open-source software they use to also be secure. Realistically, open-source code is in every supply chain. Now, it’s important to note that the way to solve this problem is not to remove open-source software from your supply chain. In fact, open-source software can often be more secure than proprietary software as its widespread use means it’s usually well tested. The challenge is in how to make adhering to security best practices so easy, they are not burdensome for the open-source community to adopt.

Along the same lines, for one organization’s software supply chain to be secure, the supply chain of any vendor they use also needs to be secure. You need provenance from top to bottom. To quote Paddy Carey, Senior Staff Engineer, Cloudsmith, “it’s turtles all the way down.” And if no one is requiring you to adopt secure software development practices, and it’s overly burdensome to do so, what’s your motivation? So again, designing standards, tools, and solutions that make it easy to be secure will be key to the widespread adoption of secure software development practices.

As Dan Lorenc said, it will be slow until the first person adopts these practices, but then we’ll see it ripple across the industry.

What does a secure software supply chain look like?

First, it’s important to acknowledge that there is no one thing you can do to secure your supply chain. There are many best practices that come together to create a secure software supply chain. But it’s also important not to let that overwhelm you.

One project that is designed to help organizations understand what makes a supply chain secure and provide guidance on how to get started is SLSA. It’s a security framework, a checklist of standards and controls to secure packages and infrastructure in your organization. And there are SLSA levels - Level 1 is designed to be easy to achieve to help motivate folks to start the process of securing their supply chain.

NIST organizes the Secure Software Development Framework practices into four groups:

• Prepare the Organization: Ensure that the organization’s people, processes, and technology are prepared to perform secure software development.
• Protect the Software: Protect all components of the software from tampering and unauthorized access.
• Produce Well-Secured Software: Produce well-secured software with minimal security vulnerabilities in its releases.
• Respond to Vulnerabilities: Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Both the SLSA framework and NIST’s SSDF are good starting points for organizations on the journey to a secure software supply chain. And if you want the tl;dr on NIST’s SSDF, Dan Lorenc read NIST 800-218 so you don’t have to.

What are Cloudsmith and Chainguard doing to help solve this problem?

Chainguard

Chainguard was founded in 2021 with the mission to make the software supply chains secure by default. The team is working on this goal with a strong commitment to open-source projects and communities, and a willingness to take on large-scale industry-wide changes. Some key projects they are involved in:

SLSA

As mentioned earlier, SLSA is a checklist of standards and controls to secure packages and infrastructure within an organization. SLSA levels are a common language to talk about how secure software, supply chains, and their components really are. From source to system, the levels blend together best practices to create four compliance levels of increasing assurance.

Sigstore

A new standard for signing, verifying, and protecting software, sigstore automates how you digitally sign and check components, for a safer chain of custody tracing software back to the source, removing the effort, time, and risk of error this usually comes with this.

Cloudsmith

As Dan McKinney said, Cloudsmith is excited that securing the software supply chain is now at the forefront of people’s minds, as it’s been close to our hearts for a while now. We believe that continuous packaging - the strategy of ensuring all packages produced or consumed are scanned, verified and isolated from untrusted sources - improves security through isolation, automation, and universal hosting. Our platform enables organizations to add continuous packaging to their modern software development workflow.

Provide a single source of truth of software assets

Cloudsmith is a universal package repository with support for over 28 formats, allowing organizations to manage packages across languages and formats in one place. This centralized source of truth provides visibility, control and management consistently for all packages produced or consumed by the build process, and gives organizations a single checkpoint that all packages pass through.

Provenance

The goal of provenance is an unbroken chain of traceability, all the way back to the host machine that built the package. And we want to meet our users where they are when it comes to provenance. We will implement support for the signatures and attestations that our customers are adopting across all the formats we support, including but not limited to sigstore, cosign, in-toto, The Update Framework and more.

Isolation

With Cloudsmith, users can cache their open-source packages away from public upstreams. By caching packages from public upstream repositories and other external sources, you can protect yourself from issues with package availability, license changes, and emerging vulnerabilities.

Securing our own software supply chain

First and foremost, we must acknowledge that we are a chain in our customers’ software supply chains. We are taking steps to ensure that we employ high-level secure software development practices, and exposing that information to our customers to prove to them that we are secure. Customers need to be able to trust, and verify, that their providers are securing their software supply chains, too.

Hopefully, that helps demystify software supply chains and why securing them is paramount to the software industry as a whole, and why the time to do so is now.

We’d also like to thank Dan Lorenc, the founder and CEO of Chainguard for joining us for the webinar.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet