What Is the SLSA Framework?

Learn what the SLSA framework is, its build integrity levels L0-L3, and how signed provenance secures your software supply chain.

hardQ214 of 224 in DevOps Est. time: 6 minsLast updated: July 2026

Open Code Lab

Expected Interview Answer

SLSA (Supply-chain Levels for Software Artifacts, pronounced 'salsa') is a security framework, originally developed at Google and now under the OpenSSF, that defines a graduated set of requirements for build and provenance integrity, letting organizations measure and incrementally improve how trustworthy their software supply chain is rather than treating it as an all-or-nothing problem.

SLSA v1.0 focuses primarily on the build track, defining levels from L0 (no guarantees) up to L3 (a hardened, auditable build platform), with each level adding requirements: L1 requires the build process to be scripted and produce provenance metadata describing how the artifact was built; L2 requires that provenance to be generated by a hosted build service and signed, so it cannot be forged by the person triggering the build; L3 requires the build environment itself to be hardened against tampering — isolated, ephemeral runners where even a compromised build script cannot alter the provenance record after the fact. Provenance is the key artifact SLSA produces: a signed, verifiable statement of exactly which source commit, which build configuration, and which build service produced a given artifact, so a consumer can decide whether to trust it based on how it was made, not just what it contains. Achieving a specific SLSA level in CI is increasingly requested by enterprise customers and is directly supported by tooling like GitHub’s native build provenance attestations and the in-toto/SLSA generator actions, making it practical to adopt incrementally rather than requiring a full platform rebuild.

Gives a shared vocabulary and roadmap for supply chain maturity
Produces signed provenance that proves how an artifact was built
Lets consumers make trust decisions based on build integrity, not just scan results
Adoptable incrementally, level by level, rather than all-or-nothing

AI Mentor Explanation

SLSA is like a graduated grading system a cricket board uses to certify how trustworthy a bat manufacturer’s process is — level one just requires a written record of materials used, level two requires that record to be issued by an independent certifying lab rather than the manufacturer itself, and level three requires the entire factory floor to be monitored so no one can alter the record after the fact. A team buying bats can check the manufacturer’s certified level and decide how much to trust the equipment based on how rigorously it was made, not just how it looks. Boards do not demand every supplier hit the top level overnight — they encourage moving up one level at a time. This turns a vague notion of 'trustworthy manufacturing' into something measurable and improvable.

Step-by-Step Explanation

Step 1
Assess current state
Determine whether builds are scripted, hosted, and produce any provenance today (baseline against L0-L3).
Step 2
Adopt hosted, scripted builds
Move ad hoc/manual builds to a scripted, hosted CI system to satisfy L1 requirements.
Step 3
Generate signed provenance
Have the hosted build service emit signed provenance metadata the triggering user cannot forge, reaching L2.
Step 4
Harden the build platform
Use isolated, ephemeral runners and prevent mid-build tampering to reach L3, the strongest guarantee.

What Interviewer Expects

Understanding SLSA is a graduated maturity model, not pass/fail
Knowledge of what distinguishes L1 (scripted) from L2 (hosted, signed) from L3 (hardened)
Ability to explain provenance as the core artifact SLSA produces
Awareness that SLSA is adopted incrementally, supported by real CI tooling

Common Mistakes

Confusing SLSA with a vulnerability scanning standard
Assuming SLSA requires reaching the top level immediately
Not distinguishing provenance (how it was built) from an SBOM (what it contains)
Forgetting that L2/L3 require the build service itself, not the developer, to produce provenance

Best Answer (HR Friendly)

“SLSA is a framework that gives us a step-by-step ladder for making our build pipeline more trustworthy, instead of an all-or-nothing security bar. At the lower levels we just need a scripted, documented build; at higher levels our hosted CI system itself generates a signed record proving exactly how and from what source an artifact was built, so anyone consuming our software can verify its origin rather than just trusting us blindly. We can target a level, prove we hit it, and keep climbing over time.”

Code Example

Generating SLSA build provenance in GitHub Actions

name: build-with-provenance
on: [push]
permissions:
  id-token: write
  contents: read
  attestations: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: make build
      - name: Generate SLSA provenance attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: dist/myapp-binary
      - name: Verify provenance before release
        run: gh attestation verify dist/myapp-binary --owner myorg

Follow-up Questions

What is the difference between an SBOM and SLSA provenance?
Why can't the developer triggering a build forge its own L2 provenance?
What specifically makes an L3 build platform “hardened” against tampering?
How would you verify SLSA provenance before deploying a third-party dependency?

MCQ Practice

1. What does the SLSA framework primarily measure?

2. What distinguishes SLSA level 2 from level 1?

3. What is “provenance” in the context of SLSA?

Flash Cards

1 / 4

What Is the SLSA Framework?

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Assess current state

Adopt hosted, scripted builds

Generate signed provenance

Harden the build platform