SLSA explained: supply-chain levels for software artifacts

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.

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

The build requirements page splits the work between the producer (the organisation that releases the software) and the build platform:

"Isolated" is stricter than it sounds. The specification says a build must not be able to persist or influence the environment of a later build, so "an ephemeral build environment MUST be provisioned for each build," and one build must not poison a cache another build uses: "the output of the build MUST be identical whether or not the cache is used."

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

SLSA recommends its own provenance format, carried as the predicate of an in-toto Statement (see our in-toto guide). Its predicateType is always https://slsa.dev/provenance/v1, whatever minor version the URL bar shows.

At Build L2 some fields, such as resolvedDependencies, may still be produced by the tenant rather than the platform; the specification asks builders to document such cases.

SLSA's threat model labels threats A to I along the path from producer to consumer. The table summarises what the v1.2 text says about each.

The verification guidance is explicit that "SLSA Build L3 does not cover compromise of the build platform itself, such as by a malicious insider." Choosing which builders to trust stays a human decision.

Synthetic example: product, URLs and digests are invented; digests are shortened for readability. A Yocto build of gateway firmware 4.2.0, run by a reusable CI workflow, produces this Statement (unsigned view):

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "gw-4.2.0.swu", "digest": { "sha256": "5d2e…a91c" } }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://ci.example.com/buildtypes/yocto-image/v1",
      "externalParameters": {
        "repository": "https://git.example.com/gw/manifest",
        "ref": "refs/tags/v4.2.0",
        "machine": "gw-imx8",
        "target": "gw-image-prod"
      },
      "resolvedDependencies": [
        { "uri": "git+https://git.yoctoproject.org/poky", "digest": { "gitCommit": "8c1f…02be" } },
        { "uri": "https://mirror.example.com/busybox-1.36.1.tar.bz2", "digest": { "sha256": "b8cc…3f0d" } }
      ]
    },
    "runDetails": {
      "builder": { "id": "https://ci.example.com/workflows/yocto-release@v3" },
      "metadata": { "invocationId": "run-18422", "startedOn": "2026-11-03T08:12:00Z", "finishedOn": "2026-11-03T10:47:00Z" }
    }
  }
}

A verifier pins the builder.id, the repository and the tag pattern. Any other machine, target or repository fails the check; the parameters stay few because the image recipe and layer list live in the tagged manifest rather than in the provenance.

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 and the comparison of Yocto and Buildroot SBOMs with image scanning. 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.

Provenance stops at the release. Whether the device only boots that signed image is a separate control; see secure boot and hardware root of trust.

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.

• Generating provenance nobody checks. GitHub's documentation puts it plainly: attestations "must be verified for the benefit to be realized."
• Signing inside the build job. If the key is readable by build steps, the provenance is L1 at best, whatever the label says.
• Claiming L3 on a persistent runner. Leftover build directories and writable shared caches break the isolation requirement.
• Unpinned fetches. A floating branch in SRC_URI or a missing .hash file means resolvedDependencies records whatever happened to be downloaded.
• Attesting the wrong file. Provenance for a build directory does not cover the signed update package a device installs.
• Too many parameters. Recording every shell command in externalParameters makes expectations impossible to write; SLSA suggests keeping the build definition in a versioned repository instead.