This is a working draft. This document may be modified, replaced, or discarded at any time.

For the latest release candidate or approved version, please use the version selector.

Version 1.0 is the current version. See the Version 1.0 documentation.

Security levels

SLSA is organized into a series of levels that provide increasing supply chain security guarantees. This gives you confidence that software hasn’t been tampered with and can be securely traced back to its source.

This page is a descriptive overview of the SLSA levels and tracks, describing their intent. For the prescriptive requirements for each level, see Requirements. For a general overview of SLSA, see About SLSA.

Levels and tracks

SLSA levels are split into tracks. Each track has its own set of levels that measure a particular aspect of supply chain security. The purpose of tracks is to recognize progress made in one aspect of security without blocking on an unrelated aspect. Tracks also allow the SLSA spec to evolve: we can add more tracks without invalidating previous levels.

Track/Level Requirements Focus
Build L0 (none) (n/a)
Build L1 Provenance showing how the package was built Mistakes, documentation
Build L2 Signed provenance, generated by a hosted build platform Tampering after the build
Build L3 Hardened build platform Tampering during the build

Note: The previous version of the specification used a single unnamed track, SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the Build track. A Source track may be added in future versions.

Build track

The SLSA build track describes increasing levels of trustworthiness and completeness in a package artifact’s provenance. Provenance describes what entity built the artifact, what process they used, and what the inputs were. The lowest level only requires the provenance to exist, while higher levels provide increasing protection against tampering of the build, the provenance, or the artifact.

The primary purpose of the build track is to enable verification that the artifact was built as expected. Consumers have some way of knowing what the expected provenance should look like for a given package and then compare each package artifact’s actual provenance to those expectations. Doing so prevents several classes of supply chain threats.

Each ecosystem (for open source) or organization (for closed source) defines exactly how this is implemented, including: means of defining expectations, what provenance format is accepted, whether reproducible builds are used, how provenance is distributed, when verification happens, and what happens on failure. Guidelines for implementers can be found in the requirements.

Build L0: No guarantees

Summary

No requirements—L0 represents the lack of SLSA.

Intended for

Development or test builds of software that are built and run on the same machine, such as unit tests.

Requirements

n/a

Benefits

n/a

Build L1: Provenance exists

Summary

Package has provenance showing how it was built. Can be used to prevent mistakes but is trivial to bypass or forge.

Intended for

Projects and organizations wanting to easily and quickly gain some benefits of SLSA—other than tamper protection—without changing their build workflows.

Requirements
  • Software Producer:
    • Follow a consistent build process so that others can form expectations about what a “correct” build looks like.
    • Run builds on a build platform that meets Build L1 requirements.
    • Distribute provenance to consumers, preferably using a convention determined by the package ecosystem.
  • Build platform:
    • Automatically generate provenance describing how the artifact was built, including: what entity built the package, what build process they used, and what the top-level input to the build were.
Benefits

  • Makes it easier for both producers and consumers to debug, patch, rebuild, and/or analyze the software by knowing its precise source version and build process.

  • With verification, prevents mistakes during the release process, such as building from a commit that is not present in the upstream repo.

  • Aids organizations in creating an inventory of software and build platforms used across a variety of teams.

Notes
  • Provenance may be incomplete and/or unsigned at L1. Higher levels require more complete and trustworthy provenance.

Build L2: Hosted build platform

Summary

Forging the provenance or evading verification requires an explicit “attack”, though this may be easy to perform. Deters unsophisticated adversaries or those who face legal or financial risk.

In practice, this means that builds run on a hosted platform that generates and signs1 the provenance.

Intended for

Projects and organizations wanting to gain moderate security benefits of SLSA by switching to a hosted build platform, while waiting for changes to the build platform itself required by Build L3.

Requirements

All of Build L1, plus:

  • Software producer:
    • Run builds on a hosted build platform that meets Build L2 requirements.
  • Build platform:
    • Generate and sign1 the provenance itself. This may be done during the original build, an after-the-fact reproducible build, or some equivalent system that ensures the trustworthiness of the provenance.
  • Consumer:
    • Validate the authenticity of the provenance.
Benefits

All of Build L1, plus:

  • Prevents tampering after the build through digital signatures1.

  • Deters adversaries who face legal or financial risk by evading security controls, such as employees who face risk of getting fired.

  • Reduces attack surface by limiting builds to specific build platforms that can be audited and hardened.

  • Allows large-scale migration of teams to supported build platforms early while further hardening work (Build L3) is done in parallel.

Build L3: Hardened builds

Summary

Forging the provenance or evading verification requires exploiting a vulnerability that is beyond the capabilities of most adversaries.

In practice, this means that builds run on a hardened build platform that offers strong tamper protection.

Intended for

Most software releases. Build L3 usually requires significant changes to existing build platforms.

Requirements

All of Build L2, plus:

  • Software producer:
    • Run builds on a hosted build platform that meets Build L3 requirements.
  • Build platform:
    • Implement strong controls to:
      • prevent runs from influencing one another, even within the same project.
      • prevent secret material used to sign the provenance from being accessible to the user-defined build steps.
Benefits

All of Build L2, plus:

  • Prevents tampering during the build—by insider threats, compromised credentials, or other tenants.

  • Greatly reduces the impact of compromised package upload credentials by requiring attacker to perform a difficult exploit of the build process.

  • Provides strong confidence that the package was built from the official source and build process.

  1. Alternate means of verifying the authenticity of the provenance are also acceptable. ↩

‹ Terminology Producing artifacts ›