🪜 SLSA Supply-Chain Levels: A Practical Roadmap From Zero to Provenance

Every time a major supply-chain breach hits the news, a flurry of “we need SLSA” lands in someone’s backlog. Then it sits there, because SLSA reads like a compliance framework and nobody knows where to start. It isn’t a compliance framework — it’s a maturity ladder for how much you can trust the way an artifact was built. The point isn’t to hit the top level. It’s to move up one rung at a time and know what each rung buys you.

I’ve walked a few teams up this ladder. Here’s the version I wish someone had handed me first.

What SLSA is actually protecting against

SLSA (Supply-chain Levels for Software Artifacts) is about build integrity — specifically, the gap between “the source I reviewed” and “the binary that shipped.” The threats it addresses:

• A compromised build server injecting code that’s in no commit.
• A dependency swapped between source and build.
• A human pushing an artifact straight to the registry, bypassing the pipeline entirely.
• A tampered build that you can’t detect after the fact.

It is not about scanning for CVEs or finding vulnerabilities in your code. Those are real, but they’re a different problem. SLSA answers: “can I prove this artifact came from this source via this build process, untampered?”

The levels, in plain terms

The current spec collapses to three meaningful build levels (Level 0 being “nothing”).

Build L1 — Provenance exists. Your build produces a signed statement describing how it was built: what source, what builder, what command. It’s not yet tamper-proof, but it exists and is machine-readable. This alone kills the “someone built it on their laptop and pushed it” class of problem, because artifacts without provenance get rejected.

Build L2 — Provenance is signed by the build service. The provenance is generated and signed by the build platform itself, not by the user’s job. Now a developer who controls their pipeline steps still can’t forge provenance, because the signing happens outside their reach.

Build L3 — The build is isolated and unforgeable. Builds run in ephemeral, isolated environments. Secrets used for signing are inaccessible to the build steps themselves. This is the level where a malicious build script genuinely cannot tamper with its own provenance or steal the signing identity.

Each level is a real increase in attacker cost. You don’t need L3 everywhere — you need it on the artifacts that matter most.

Getting to L1 this quarter

L1 is mostly free if you’re on a modern CI platform. Generate provenance as part of the build. On GitHub Actions, the official generator does the heavy lifting:

jobs:
  build:
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    # ... build and push image, capture digest ...

  provenance:
    needs: build
    permissions:
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2
    with:
      image: ghcr.io/acme/api
      digest: ${{ needs.build.outputs.digest }}

That reusable workflow actually targets L3 on GitHub-hosted runners, because it runs the provenance generation in an isolated reusable workflow your build job can’t tamper with. The platform does the isolation for you — which is why “what builder you use” matters as much as “what you configure.”

Verifying provenance — the half everyone skips

Producing provenance you never check is the SLSA equivalent of writing logs nobody reads. The value is in verification at deploy time. Use slsa-verifier:

slsa-verifier verify-image \
  ghcr.io/acme/api@sha256:abc123... \
  --source-uri github.com/acme/api \
  --source-branch main

This fails if the image wasn’t built from acme/api on main via the expected builder. Wire it into the same admission gate you use for signature verification. The mental model: signatures prove who, provenance proves how. You want both before a workload runs.

A realistic adoption order

Don’t try to lift the whole org at once. The order that’s worked for me:

1. Inventory your builders. You can’t reason about build integrity until you know every way an artifact reaches production. The horror is always the one legacy Jenkins box that pushes straight to the registry.
2. Kill the side doors. Make the pipeline the only path to the registry. Provenance is meaningless if humans can still push manually. This is the highest-leverage step and it’s pure access control, not SLSA tooling.
3. Turn on L1 provenance for your highest-value artifacts (the ones with broadest blast radius — base images, shared libraries, the auth service).
4. Move to a builder that gives you L3 isolation for those same artifacts.
5. Add deploy-time verification in warn mode, then enforce.
6. Expand coverage outward to the long tail.

Notice that steps 1 and 2 aren’t really SLSA — they’re prerequisites. Most teams “doing SLSA” who get breached anyway skipped them.

What it costs and what it doesn’t

The honest tradeoffs:

• Build time barely moves; provenance generation is cheap.
• Verification adds a step to deploy, which means a new failure mode. Roll out in warn mode or you’ll block a release over a misconfigured source URI.
• Cognitive load is the real cost. Every engineer needs to understand why they can’t push manually anymore. Budget for the culture change, not just the YAML.

SLSA won’t catch a vulnerable dependency or a logic bug — pair it with scanning and review. What it gives you is the ability to say, with cryptographic backing, “this exact artifact came from this exact source via this exact build, and nobody touched it in between.” After your first incident where that question matters, you’ll be glad you climbed the ladder.

More build-pipeline hardening lives in our security and hardening collection. If you’re reviewing the pipeline changes that add provenance, the AI code review assistant can flag the manual-push side doors that quietly undermine the whole effort.

Workflow snippets are illustrative. Confirm builder isolation guarantees and verification policies against your own platform before relying on them.