universal security Commons: 4/5

Supply chain Levels for Software Artifacts (SLSA)

Also known as:

1. Overview

Supply chain Levels for Software Artifacts (SLSA) is a pattern for building resilient value creation systems.

Problem: A Software Bill of Materials (SBOM) tells you what is in your software, but it doesn’t tell you how it was built. Your software supply chain can be tampered with at any point: a developer’s machine could be compromised, the source code repository could be modified, or the build system could be attacked to inject malicious code. You have no way to be sure that the software you are running is the software that was intended to be built.

Context: You are responsible for the security of a software development and deployment pipeline. You need a framework to progressively improve the security and integrity of your software supply chain and to provide verifiable evidence that your software has not been tampered with.

2. Core Principles

Adopt the Supply chain Levels for Software Artifacts (SLSA) framework, a set of incrementally adoptable security guidelines that create a common language for supply chain integrity. SLSA (pronounced “salsa”) defines four levels of assurance (SLSA 1 through 4), each requiring progressively stronger security controls for the build process.

  • SLSA 1: Requires that the build process is fully scripted/automated and generates provenance (metadata about how the software was built).
  • SLSA 2: Requires using version control and a hosted build service that generates authenticated provenance.
  • SLSA 3: Requires that the build platform is hardened and that the provenance is more detailed and trustworthy.
  • SLSA 4: Requires a two-person review of all changes and a hermetic, reproducible build process.

The key output of a SLSA-compliant pipeline is provenance, a verifiable and authenticated metadata file that describes where the software came from, how it was built, and what its dependencies are.

3. Rationale

SLSA provides a clear roadmap for securing the software supply chain. It:

  • Protects Against Tampering: Provides strong guarantees that the software you are using is exactly what it claims to be.
  • Is Incrementally Adoptable: The levels provide a clear path for organizations to improve their security posture over time.
  • Provides Verifiable Guarantees: The provenance generated by a SLSA-compliant pipeline provides verifiable evidence of supply chain integrity.

4. Consequences

  • Positive:
    • A significant improvement in the security and integrity of the software supply chain.
    • A clear framework for communicating and achieving security goals.
    • Increased trust and confidence in the software you produce and consume.
  • Negative:
    • Reaching the higher SLSA levels can be very challenging and requires a significant investment in build infrastructure and process.
    • The tooling and ecosystem around SLSA are still maturing.
    • Can add friction to the development process if not implemented carefully.

5. Application Context

Best Used For:

  • Value creation systems requiring strong privacy and security foundations
  • Organizations operating in regulated environments
  • Systems handling sensitive data or requiring high trust

6. Known Uses

  • Google: SLSA originated at Google and is used internally to secure their own software supply chain.
  • Open Source Security Foundation (OpenSSF): SLSA is now a project of the OpenSSF, which is driving its adoption across the industry.
  • Google Cloud Build: Can generate SLSA-compliant provenance for builds.