slsa v1.0 releases: Supply-chain Levels for Software Artifacts

by do son · Published August 11, 2021 · Updated April 18, 2023

SLSA: Supply-chain Levels for Software Artifacts

Supply-chain Levels for Software Artifacts (SLSA, pronounced salsa) is an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. The requirements are inspired by Google’s internal “Binary Authorization for Borg” which has been in use for the past 8+ years and that is mandatory for all of Google’s production workloads.

Overview

SLSA consists of:

Standards: (this doc) Industry consensus on the definition of a “secure” software supply chain. There may be multiple standards to represent multiple aspects of security.
Accreditation: Process for organizations to certify compliance with these standards.
Technical controls: To record provenance and detect or prevent non-compliance.

Ultimately, the software consumer decides whom to trust and what standards to enforce. In this light, accreditation is a means to transfer trust across organizational boundaries. For example, a company may internally “accredit” its in-house source and build systems while relying on OpenSSF to accredit third-party ones. Other organizations may trust other accreditation bodies.

This document only discusses the first part, Standards. We expect to develop an accreditation process and technical controls over time. In the interim, these levels can provide value as guidelines for how to secure a software supply chain.

Principles

SLSA focuses on the following two main principles:

Non-unilateral: No person can modify the software artifact anywhere in the software supply chain without explicit review and approval by at least one other “trusted person.”[^1] The purpose is prevention, deterrence, and/or early detection of risky/bad changes.
Auditable: The software artifact can be securely and transparently traced back to the original, human-readable sources and dependencies. The primary purpose is for automated analyses of sources and dependencies, as well as ad-hoc investigations.

Though not perfect, these two principles provide substantial mitigation for a wide range of tampering, confusion, and other supply chain attacks.

To measure how well protected a supply chain is according to the two principles above, we propose the SLSA levels. A higher level means it is better protected. SLSA 4 is the end goal but may take many years and significant investment for large organizations. SLSA 1 through SLSA 3 are stepping stones to recognize meaningful progress.

What sets SLSA 4 apart from simple best practices is its resilience against determined adversaries. That is, SLSA is a guarantee that these practices have been followed, though still not a guarantee that the software is “safe.”

Background

Why do we need SLSA?

SLSA addresses three issues:

Software producers want to secure their supply chains but don’t know exactly how.
Software consumers want to understand and limit their exposure to supply chain attacks but have no means of doing so.
Artifact signatures alone only prevent a subset of the attacks we care about.

At a minimum, SLSA can be used as a set of guiding principles for software producers and consumers. More importantly, SLSA allows us to talk about supply chain risks and mitigations in a common language. This allows us to communicate and act on those risks across organizational boundaries.

Numeric levels, in particular, are useful because they are simple. A decision-maker easily understands that SLSA 4 is better than SLSA 3 without understanding any of the details. That said, we are not committed to numeric levels and are open to other options.

Once SLSA is complete it will provide a mapping from requirements that the supply chain can implement to the attacks they can prevent. Software producers and consumers will be able to look at the SLSA level of a software artifact and know what attacks have been defended against in its production.