Skip to main content
RunBook Academy

Git, CI/CD & GitOpsLXX · ProvenanceBuildTrack

SLSA build levels — L0 through L3 and what each level guarantees

Advanced⏱ ~24 mingit

What you'll learn

  • Describe the four SLSA build levels and the incremental guarantee each one adds
  • Identify which threats L1, L2, and L3 mitigate and which threats they do not
  • Map a typical GitHub Actions workflow to the SLSA build level it satisfies
  • Recognise the production cost of operating at L3 versus the cost of operating at L1

Prerequisites

Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x

Not yet marked complete on this device.

SLSA build levels describe incremental guarantees about the build process. L0 has no provenance; L1 has provenance but does not sign it; L2 adds signed provenance and an isolated build platform; L3 adds a hardened build platform and two-party review. The levels are the yardstick the audit team uses to score the supply chain; the yardstick the platform team uses to plan remediation. The question is not “what level should we operate at?” but “what level can we operate at given the platform we have?”.

The four levels

  • L0 — No guarantees. The build is not documented. There is no provenance; the consumer cannot answer “where did this artifact come from?”.
  • L1 — Provenance exists. The build produces a provenance attestation that names the source, the builder, and the step. The provenance is not signed; the consumer can read the claim but cannot trust the signer.
  • L2 — Provenance is signed and the build is isolated. The provenance is signed by the build platform; the build runs on a platform that prevents the script from accessing the signing key or the registry credentials during the build.
  • L3 — Hardened build, two-party review. The build platform is hardened against runtime tampering; the build script cannot influence the provenance generation; a second party reviews the source before the build runs. L3 is the level designed to resist a determined attacker with access to the build pipeline.
flowchart LR
    A["L0: no provenance"] --> B["L1: provenance exists"]
    B --> C["L2: signed + isolated"]
    C --> D["L3: hardened + two-party"]
    A -.-> A1["Audit cannot answer"]
    B -.-> B1["Audit can read but not trust"]
    C -.-> C1["Audit can verify signer"]
    D -.-> D1["Audit can defend against insider"]

What each level prevents

The threats the levels mitigate are not the same:

  • L1 prevents the silent absence of provenance. The audit team can ask “where did this artifact come from?” and get an answer, even if the answer is unsigned.
  • L2 prevents a forger from producing a fake provenance. The signature binds the attestation to the build platform’s identity.
  • L3 prevents an attacker who has compromised the build script from tampering with the provenance. The provenance is generated by the hardened platform, not by the script.

L1 does NOT prevent forgery. L2 does NOT prevent a script-level compromise. L3 is the only level designed to resist a determined attacker with script-level access.

Mapping GitHub Actions to the SLSA levels

  • L1: actions/attest-build-provenance@v1 produces a SLSA build provenance attestation. The attestation is unsigned at this level.
  • L2: GitHub signs the attestation with the OIDC identity of the workflow. The verifier pins the workflow path and the issuer URL; the build runs on GitHub-hosted runners that isolate the build script from the signing material.
  • L3: The build runs on hardened runners, the workflow file is reviewed by a code owner before merge, and the source branch is protected with two-party review.

The progression is the same shape as the audit benchmark: more control, more review, more cost.

The production cost of operating at L3

L3 is not free. The costs are build latency (hardened runners are slower), review friction (two-party review on every protected branch means every change waits for a second reviewer), and platform investment (L3 requires a build platform the team can demonstrate meets the hardened-build requirements). The production trade-off is between supply-chain integrity and developer velocity; the team’s risk appetite is the dial.

Production discipline

  1. Generate provenance at L1. The audit team will ask for provenance; the build pipeline must produce it.
  2. Sign the provenance at L2. Unsigned provenance is provenance that can be forged.
  3. Document the level your platform achieves. The level is the answer to the audit question; the platform is the evidence.
  4. Plan the L3 remediation as a roadmap. The level is the target; the roadmap is the path.

Cross-course references

  • Git, CI/CD & GitOps — Part LXX-01 (What Provenance Is) is the concept; LXX-02 is the SLSA grading.
  • Git, CI/CD & GitOps — Part LXIX-03 (Keyless Signing with Fulcio) is the signing infrastructure L2 requires.
  • Container Security for Production Sysadmins — Part VII (Admission Control) is the verifier side.

Quiz

Knowledge check · 4 questions

  1. Q1. Which SLSA build level is designed to resist a determined attacker who has compromised the build script that runs inside the workflow?

  2. Q2. Operating at SLSA build L2 is not sufficient to defend against a compromise of the build script that runs inside the workflow.

  3. Q3. Name the SLSA build level that GitHub Actions achieves when the workflow uses actions/attest-build-provenance@v1, runs on GitHub-hosted runners, and consumes the signed attestation via the OIDC identity of the workflow.

  4. Q4. Diagnose why the team is operating at L1 despite believing they are at L2, and recommend the fix.

    Team T configures the workflow to produce a provenance attestation with actions/attest-build-provenance@v1. The team tells the auditors they are at SLSA L2. The auditors inspect the runner configuration and find that the workflow runs on a self-hosted runner that has persistent Docker credentials; the runner can push to the registry during the build. The provenance is signed by the workflow identity, but the runner is not the isolated build platform SLSA L2 requires.

Passing score: 75%. Answers are checked in this browser.