SLSA stands for Supply-chain Levels for Software Artifacts. It is pronounced “salsa”. It is a specification for software supply chain security, maintained by industry consensus under the Linux Foundation.

This post explains what SLSA is, how it works, where it applies, and the checks required at each level. It covers version 1.2 of the specification.

Official specification: slsa.dev/spec/v1.2

Contents

What SLSA is

SLSA is a set of guidelines for securing the software supply chain. You adopt it in steps. It works for two groups:

  • Producers use it to reduce the chance that their software is changed without authorization on the way to users.
  • Consumers use it to decide whether to trust a package.

SLSA gives you:

  • A shared vocabulary for supply chain security.
  • A method to evaluate the artifacts you consume.
  • A checklist to improve your own software.
  • A way to measure progress toward the NIST Secure Software Development Framework (SSDF). See csrc.nist.gov/Projects/ssdf.

Reference: About SLSA.

How SLSA works

SLSA is organized into tracks. Each track is divided into levels.

  • A track covers one part of the supply chain. Examples: how an artifact was built, or how a source revision was created.
  • Levels within a track go up in order. A higher level means stronger guarantees and more work to implement. A lower level is easier to adopt and gives fewer guarantees. Level 0 means the software meets no level yet.

The mechanism behind every track is the attestation. An attestation is a signed, machine-readable statement about how an artifact or source revision was produced. Verification means comparing the attestation that exists against the attestation that was expected.

Each ecosystem or organization decides the details: how expectations are defined, which formats are accepted, how attestations are distributed, when verification runs, and what happens on failure.

Reference: Tracks.

The two tracks in v1.2

Track What it covers Levels
Build Track How an artifact was built: who built it, what process was used, what the inputs were. L0 to L3
Source Track How a source revision was created and managed. L1 to L4

Version history: the first version of SLSA used one track with levels 1 to 4. Version 1.0 removed source and focused on the build track. Version 1.2 adds source back as its own track.

Who SLSA is for

Audience What SLSA provides
Software producers (open source projects, vendors, internal teams) Protection against changes to software on the path to users. Reduces insider risk.
Software consumers (teams using open source, agencies, security officers) A method to assess the practices behind software they depend on, and to confirm they received what they expected.
Infrastructure providers (package managers, build and CI/CD platforms) A way to enable a secure supply chain between producers and consumers.

Build Track: levels and checks

The Build Track lets you prove that an artifact was built the way it was meant to be, on infrastructure you can trust. Each level includes the requirements of the level below it.

Level Requirement Threat addressed
Build L0 None None
Build L1 Provenance shows how the package was built Mistakes and missing records
Build L2 Signed provenance from a hosted build platform Changes after the build
Build L3 Hardened build platform Changes during the build

Build L0: no guarantees

  • No requirements. Used for builds that run and are consumed on the same machine, such as unit tests.

Build L1: provenance exists

  • Producer: follow one build process so others can define what a correct build looks like.
  • Producer: run builds on a platform that meets Build L1.
  • Producer: distribute provenance to consumers.
  • Build platform: generate provenance that records the entity that built the package, the build process used, and the top-level inputs.
  • Note: at L1 the provenance can be incomplete or unsigned. It prevents mistakes, not deliberate attacks.

Build L2: hosted build platform (adds to L1)

  • Producer: run builds on a hosted build platform that meets Build L2.
  • Build platform: generate and sign the provenance.
  • Consumer: check that the provenance is authentic.
  • Result: signed provenance enables detection of changes after the build (assuming signing keys and trust anchors are secure).

Build L3: hardened builds (adds to L2)

  • Producer: run builds on a hosted build platform that meets Build L3.
  • Build platform: prevent one build run from affecting another, including runs in the same project.
  • Build platform: keep the signing secrets out of reach of user-defined build steps.
  • Result: protection against changes during the build from insiders, stolen credentials, or other tenants.
  • Note: L3 reduces risk but does not cover compromise of the build platform itself, such as a malicious platform administrator. Verifiers should choose which build platforms to trust and configure their roots of trust accordingly. See Assessing build platforms.

Reference: Build Track Basics. Detailed requirements: Producing artifacts. Verification: Verifying artifacts.

Source Track: levels and checks

The Source Track lets you trust how a source revision was created and confirm that its history was not rewritten. The repository owner (the organization) defines the process and runs the controls that enforce it. Consumers review attestations to confirm a revision meets their bar.

Level Requirement Focus
Source L1 Use a modern version control system (produce discrete, immutable revisions) Discrete revisions for precise use
Source L2 Keep change history and produce source provenance History backed by evidence
Source L3 Enforce the organization’s technical controls Controls that consumers can see
Source L4 Require two-party review Code review and insider-threat resistance

Responsibility is split between the organization and the Source Control System (SCS), such as GitHub, GitLab, Gerrit, or a self-hosted system. Each has its own checks.

Claims apply only forward from the revision where a branch is onboarded to a level. No claims are made about earlier history.

Organization checks by level

Check L1 L2 L3 L4
Choose an SCS that can reach the target level x x x x
Configure access control and enforce history; prevent tags from being moved or deleted   x x x
Document a safe process for removing content for legal or privacy reasons, with logging   x x x
Provide evidence of continuous enforcement for every control claimed, and document each control     x x

Source Control System checks by level

Check L1 L2 L3 L4
Repositories are uniquely identifiable with a stable locator x x x x
Revisions are immutable and uniquely identifiable x x x x
Provide tooling to show diffs between revisions x x x x
Issue a Source Verification Summary Attestation (VSA) for any revision at L1 or above x x x x
Record all changes to references; allow a branch to move only to descendant revisions (no force-push)   x x x
Track continuous enforcement of each control from a start revision   x x x
Authenticate actors and let the organization set who can perform sensitive actions   x x x
Produce source provenance for each revision at the time the branch is updated   x x x
Let the organization enforce custom controls on chosen branches and tags, and record them     x x
Require two trusted persons to agree to each change on protected branches       x

Two-party review applies to the final submitted revision. Later edits are reviewed again. Organizations may grant standing exceptions to trusted automation, such as Dependabot or migration bots.

Reference: Producing source. Verification: Verifying source.

Attestations

Every track is enforced through attestations. These use the in-toto attestation format. See the in-toto attestation specification.

  • Build provenance: records who built an artifact, the process, and the inputs. See Provenance.
  • Source provenance: SCS-issued evidence of how a revision was created. The format is left open so each SCS can fit its own model.
  • Verification Summary Attestation (VSA): a summary issued by an authority that states the level a revision or artifact meets, for example SLSA_SOURCE_LEVEL_3. VSAs use predicateType https://slsa.dev/verification_summary/v1 in the in-toto attestation framework. See Verification Summary.

Verification means a verifier compares the attestation against the expectations defined for the artifact or revision. The level tells the consumer how much weight that comparison carries.

What SLSA does not cover

  • Code quality: SLSA does not check whether the code itself is written securely.
  • Producer trust: SLSA does not stop an organization that intends to ship malware. It reduces insider risk inside an organization you already trust.
  • Transitive dependencies: an artifact’s level is separate from the levels of its dependencies. There is no single level that covers an artifact and its full dependency tree.

Pair SLSA with vulnerability scanning, SBOMs, code review, and dependency management.

Reference: Threats and mitigations.

A path to adoption

  1. Reach Build L1 by producing provenance from your current pipeline.
  2. Move to a hosted build platform that signs provenance to reach Build L2.
  3. Harden the platform to reach Build L3 for production releases.
  4. Walk the Source Track in parallel: L1 uses a version control system, L2 adds history and source provenance, L3 enforces controls, L4 requires two-party review.
  5. Verify, not just produce. Provenance has value only when consumers compare it against expectations and reject mismatches.

Sources

Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.

Thank you for reading!

Back to Top