Google's SLSA Looks Good, But Is It Enough?

Today, open source is all around us—in nearly all proprietary codebases and community projects. For companies, the question isn't if you are or aren't using open source code—it's what open source code you're using. If you aren't aware of your software supply chain, a vulnerability in one of your dependencies can affect your product, making you susceptible to a possible breach. Here at OpenVPN, open source is at the heart of what we do — and the security therein is paramount.

Last month, Google introduced “Supply chain Levels for Software Artifacts” (SLSA), an end-to-end framework to ensure the integrity of software artifacts throughout the software supply chain. "The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats," says Kim Lewandowski and Mark Lodato in a Google blog post on the topic.

Understanding Software Supply Chains

To understand what SLSA does, it’s essential to understand what a software supply chain looks like. Now, in any industry, “supply chain” typically refers to every process that's needed to distribute your product, including all the materials used to make each component of that product. For a tub of ice cream you might buy at the grocery store, that includes everything in the list of ingredients, the source of nutritional information, the packaging, and maybe even the data source on production facilities or organic ingredients. But it doesn't end there: it's anything that can alter the delivery of that product, too. A tub of ice cream that isn't frozen as it travels through a hot climate, for instance, will affect the end product.

Switching from ice cream to codebase, a software supply chain is anything that goes into or affects the code, from development through the integration and delivery pipeline, until it gets deployed into production. It's everything that goes into the software, including code, binaries, other components, and where they originated. A software supply chain includes who wrote it, when they contributed it, the review process for security, known vulnerabilities, supported versions, license information—everything that touches it at any time.

SLSA Aims to Solve the Problem

"In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give "SLSA certification" to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today," writes Lewandowski and Lodato.

SLSA is a framework that performs a lockdown function on every element in the typical software application development team's software build chain. This results in a more efficient and streamlined software supply chain, from the source code to the package repository and dependencies.

Limitations of SLSA

Unlike product specifications and ISO standards, SLSA is not a universal set of specifications. SLSA merely defines a range of common practices that every company should follow. It does not have a proper mechanism to enforce compliance or even provide a context to it. It's simply a guideline — for now.

SBOM + SLSA Leading the Charge

Another path into securing the software supply chain is SBOM: the Software Bill of Materials.

"SLSA is a great stepping stone—however, it is just that (for now),” says Robert Weiss, Head of Information Security at OpenVPN. “SLSA is a framework proposed by one vendor and has no industry weight behind it (again, for now). It will likely positively contribute to the important discussion about standardizing the security of the software supply chain in the future. As a first step, product developers should implement SBOM, which seems to be an intermediary step required to get to a more comprehensive solution like SLSA."

SBOM is essentially a list of "ingredients" that make up software components. Many experts believe this is the first step into securing the software supply chain: establishing transparency behind what makes up that supply chain.

And experts seem optimistic about the progress towards that transparency. Recently, President Biden issued an Executive Order (EO) on Improving the Nation’s Cybersecurity, and said “the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is.” Duncan Sparrell, a contributor to the NTIA SBOM multistakeholder process and long-time SBOM advocate, agreed, saying “that quote says it all.”

Sparrell went on to say, “I believe history will eventually show the EO as a tipping point in both cybersecurity and software quality.” History is currently in the making and as of July 12th, 2021, The National Telecommunications and Information Administration (NTIA) released Minimum Elements for SBOM.

“The minimum elements as defined in the report are the essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency. These minimum elements comprise three broad, interrelated areas,” Allan Friedman writes in the blog post. The three areas outlined are: Data Fields, Automation Support, and Practices and Processes.

OpenVPN plans to move forward to implement SBOM soon, and looks forward to continuing to lead the open source community toward higher levels of security, compliance, and transparency regarding our products.

SBOM and SLSA are each just one piece of the puzzle, but as Friedman says in his keynote speech, The Journey To Securing Our Software Supply Chains with SBOM, let's crawl before we walk, and walk before we run. The SLSA framework contributes to the solution of securing the software supply chain, but what we really need is full industry consensus. SLSA provides an important step toward developing that consensus — but it is just one step.