SLSA explained: supply-chain levels for software artifacts

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework for grading how trustworthy a software build and its source history are, published at slsa.dev as part of the Open Source Security Foundation (OpenSSF). Rather than a single pass/fail check, SLSA defines two separate tracks of increasing levels: a Build Track that grades the build process, and a Source Track that grades the source repository's history and controls. A level is only as credible as the signed provenance attestation behind it, which a consumer can independently verify.

Who maintains it and what version is current

SLSA's homepage describes it as led by a "cross-organization, vendor-neutral steering group" under OpenSSF, with participants including Google, Microsoft, Intel, IBM, Red Hat and Datadog. The specification text itself is published by The Linux Foundation under the Community Specification License 1.0. The framework has evolved in stages: version 1.0 narrowed the original multi-level scheme to a Build Track only (removing source-related requirements to focus the spec); version 1.1 was a clarity refresh; and version 1.2, approved 12 November 2025, is a structural release that adds a full Source Track, promoted from experimental to approved status. SLSA v1.2 is backward compatible with Build Track claims made under v1.0 and v1.1.

Build Track: levels 0-3

Per the v1.2 Build Track specification, provenance is documentation describing an artifact's construction: the entity that built it, the process used, and the top-level build inputs.

Level	Name	What it requires
Build L0	No guarantees	No requirements; represents the absence of SLSA, typical of local development or test builds
Build L1	Provenance exists	The build platform automatically generates provenance recording who built the package, what process was used, and the top-level build inputs; the producer distributes that provenance
Build L2	Hosted build platform	All L1 requirements, plus: builds run on a hosted platform that generates and signs the provenance itself, so forging it requires an explicit attack on that platform
Build L3	Hardened builds	All L2 requirements, plus: the build platform implements strong controls so that concurrent build runs cannot influence one another, and the signing secret for provenance is inaccessible to user-defined build steps

Source Track: levels 1-4

Approved as part of v1.2, the Source Track grades the source repository rather than the build. Per the v1.2 source requirements specification:

Level	Name	What it requires
Source L1	Version controlled	Source is stored in a modern version control system (Source Control System), in a repository with a stable, unique locator
Source L2	History & provenance	Branch history is continuous, immutable and retained; force pushes that break ancestry are prevented; the Source Control System issues a Source Provenance Attestation for each new revision
Source L3	Continuous technical controls	The Source Control System provides evidence that the organisation's technical controls on protected branches are continuously enforced, with the meaning of those controls documented and recorded in attestations
Source L4	Two-party review	Changes to protected branches must be agreed to by two or more trusted persons before submission

Why this matters for device and firmware makers

SLSA's Build Track provenance answers a question a firmware SBOM cannot: not just what components are inside the image, but how the image itself was produced, and by whom. A firmware build pipeline that reaches Build L2 or L3 can prove, with a signed attestation, that a given binary came from a specific hardened, hosted pipeline rather than an engineer's laptop — useful evidence for a secure-development-lifecycle narrative alongside an SBOM; see our guide to firmware SBOM without source code. The Source Track is relevant further upstream: a chip vendor's SDK or an open-source dependency with Source L2+ history gives a downstream device maker more confidence that what they pulled is what the maintainer actually committed, before it ever reaches the build.

No regulation known to us at the time of writing names a required SLSA level. Where SLSA is useful is as evidence of process maturity that can support, but does not substitute for, the specific duties in frameworks such as the Cyber Resilience Act's secure-development and vulnerability-handling requirements (see CRA Annex I explained) or a formal secure development lifecycle model such as NIST SSDF or IEC 62443-4-1. Confirm any specific regulatory mapping against current guidance before relying on it; this guide makes no such claim.

A workable adoption order

1. Start with Build L1: turn on provenance generation in your existing CI, even if it is self-reported and easy to forge — it establishes the habit and the schema.
2. Move the build to a hosted, SLSA-aware platform to reach Build L2, so provenance is generated and signed by something other than the build job itself.
3. Harden the build platform (isolated runs, inaccessible signing secrets) to reach Build L3 for your highest-value release artifacts.
4. Separately assess your source repositories against the Source Track: continuous, immutable history (L2) and enforced branch protection (L3) are usually closer at hand than full two-party review (L4) for a small team.
5. Publish and verify provenance, not just generate it: a SLSA level only has value to a downstream consumer who can check the signed attestation, so treat distribution of the provenance artifact as part of the release, not an afterthought.

SoftWSP matches your firmware image against its declared build and component provenance as part of a firmware security assessment: see device firmware security.

This guide summarises the public SLSA v1.2 specification at slsa.dev; it does not constitute legal or compliance advice.