Security standards, plainly, part 3: SLSA v1.2

Part 1 (SSDF) listed what a secure process should do. Part 2 (SAMM) measured how well you do it. Both mostly look at the code. SLSA looks at the journey from code to the thing you ship, because attackers have learned that it is often easier to tamper with a build than to find a bug.

What it is, in one sentence

#

SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is “a specification for describing and incrementally improving supply chain security, established by industry consensus” (SLSA v1.2). It tells you what to do, step by step, so that anyone can check where a piece of software came from and how it was built.

Version 1.2 was announced on 24 November 2025. It is backwards compatible with 1.1, and its headline change is a new Source track.

The key idea: provenance

#

Provenance is a receipt for a build: metadata that says which platform built the artifact, which build process it used, and what the top-level inputs were, such as the source commit (Build track basics).

Why a receipt matters: if your release binary comes with a signed receipt saying “built by the CI system from commit a1b2c3 of my-org/my-app”, then a binary built on someone’s laptop, or swapped on the download server, will not have a matching receipt. The check becomes mechanical.

Two tracks, each a staircase

#

SLSA v1.2 has two tracks. Each has levels, so you can climb one step at a time.

Build track: can I trust how it was built?

#

Source track: can I trust the code that went in?

#

Levels come from the Source track requirements.

flowchart LR
  subgraph src["Source track"]
    S["Code in version control
protected branches, two-person review"]
  end
  subgraph bld["Build track"]
    B["Hosted, hardened build
writes and signs provenance"]
  end
  S --> B --> A(["Artifact + signed receipt"])
  A --> C{"Consumer verifies
the receipt"}
  C -- matches --> OK([Deploy])
  C -- missing or wrong --> NO([Reject])

What it looks like in practice

#

On GitHub, two steps get you most of the way. GitHub’s own documentation says artifact attestations “by itself provides SLSA v1.0 Build Level 2”, and that running the build in a shared reusable workflow can take it to Build Level 3 (GitHub docs).

1. Write the receipt in the workflow that builds the release:

permissions:
  id-token: write      # lets the job get a short-lived signing identity
  contents: read
  attestations: write  # lets the job store the attestation

steps:
  # ... your build steps produce dist/my-app ...
  - name: Generate artifact attestation
    uses: actions/attest@v4
    with:
      subject-path: dist/my-app

2. Check the receipt before you deploy or install:

gh attestation verify dist/my-app -R my-org/my-app

If the file was not built by that repository’s workflow, verification fails. The commands follow GitHub’s how-to guide. On GitHub Enterprise Server, check your version’s documentation before relying on this.

Why it is worth anything

#

• It covers a blind spot. Code scanners look at source. Nobody scans the gap between a clean commit and the binary on the download page. SLSA does.
• It is checkable by machines. A deploy pipeline can refuse anything without a valid receipt, with no human judgement needed.
• It climbs in small steps. Build L1 is an afternoon’s work; L3 can wait until the basics are in place.
• Buyers can ask for it. “Show me SLSA Build L2 provenance” is a precise request, much better than “is your build secure?”.

What it does not do

#

• It does not say the code is safe. A perfectly signed receipt can describe a build of vulnerable code. Provenance proves origin, not quality. Scanning (SSDF practices PW.7 and PW.8) still matters.
• It does not cover your dependencies’ bugs. SLSA’s announcement says work continues on future tracks, including a Dependency track; today, known CVEs in your dependencies are a job for SCA scanners and the triage in part 4.
• It does not set deadlines. Like the SSDF and SAMM, there is no clock in it.

Takeaways

#

• SLSA is the sealed bottle with a label: a signed provenance receipt saying who built the software, how, and from what.
• Build track L0–L3 protects the build; Source track L1–L4 (new in v1.2, November 2025) protects the code going in.
• On GitHub, actions/attest plus gh attestation verify gets a team to Build L2 quickly.
• It proves origin, not quality: keep scanning.

References

#

• SLSA specification v1.2: SLSA, definition, tracks, approved status
• Announcing SLSA v1.2: SLSA, 24 November 2025 date, Source track, backwards compatibility, future tracks
• Build track basics: SLSA, Build levels L0–L3 and the definition of provenance
• Source track requirements: SLSA, Source levels L1–L4
• Artifact attestations: GitHub Docs, Build Level 2 by default, Level 3 with reusable workflows, gh attestation verify
• Using artifact attestations: GitHub Docs, workflow permissions, actions/attest@v4, verification command

Previous: part 2, OWASP SAMM. Next: part 4, CISA KEV and BOD 26-04.