SLSA in Practice

Everything that ships passed through a build. Photo: SpaceX, public domain.

Most conversations about software supply chain security start with scanning. Scan the dependencies, scan the image, scan the code. Scanning matters, but it answers a question about contents. It says nothing about origin. A clean scan of an artifact that was swapped out between the build and the registry is still a clean scan of the wrong thing.

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") exists for that second question. It asks whether you can prove where an artifact came from, how it was built, and that nobody changed it on the way. It is less a tool than a ladder: a set of levels, each adding one concrete demand on how you build.

This article walks through what those levels actually ask of a pipeline, what the evidence looks like, and where teams I've seen tend to stall.

The threat it is shaped around​

Picture the path an artifact takes. A developer commits source. A build system checks it out, pulls dependencies, compiles, and packages. The package lands in a registry. Something downstream pulls it and runs it.

Every arrow in that path is a place to interfere. Someone could push source that never went through review. A compromised build step could inject code the source never contained. A dependency could be swapped for a lookalike. The package could be replaced in the registry after the build finished.

SLSA's current Build track focuses on the middle of that path: the build itself, and the record of what the build did. That record is called provenance.

The levels​

SLSA v1.0 defines four Build levels [1]. Each adds one requirement, and each requirement removes a specific way of lying about how an artifact was made.

Level 0 asks for nothing. It is where everyone starts, and it is honest about it.

Level 1 asks that provenance exists. The build produces a document describing what was built, from which source, by which build system, with which parameters. It doesn't need to be signed yet. At this level provenance mostly helps with debugging and inventory: you can finally answer "where did this binary come from?" without archaeology.

Level 2 asks that the provenance is generated and signed by a hosted build platform, not by the build script. This is the first real security step. If the build steps themselves wrote the provenance, a compromised step could simply write a convincing lie. Moving generation into the platform means the record comes from something the build cannot easily impersonate.

Level 3 asks that the build platform is hardened. Builds run isolated from one another, and the secrets used to sign provenance are out of reach of user-defined build steps. Without this, one malicious job could tamper with a neighbouring build, or read the signing key and forge provenance for anything.

What provenance looks like​

Provenance is an in-toto attestation [2]: a signed statement whose subject is the artifact, identified by its digest, and whose predicate describes how it was built.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "app", "digest": { "sha256": "…" } }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "…",
      "externalParameters": { "…": "…" },
      "resolvedDependencies": [ … ]
    },
    "runDetails": {
      "builder": { "id": "…" }
    }
  }
}

The skeleton of a SLSA v1 provenance statement. Values elided.

Two parts carry most of the weight. The subject ties the statement to one exact artifact by digest, so it can't be reattached to something else. The builder.id names who produced the statement, which is what a verifier checks against a list of builders it trusts.

Where teams get stuck​

The first trap is producing provenance that nobody reads. Generating attestations is satisfying: the pipeline goes green and a new file appears next to every artifact. But provenance that is never verified protects nothing. An attacker who can swap the artifact can usually ignore the attestation too, because nothing downstream asks for it.

The second is self-hosted runners. Level 2 wants a hosted build platform generating provenance. Many organisations run their own runners for good reasons, like network access, hardware, or cost. That is compatible with SLSA, but it means the organisation now is the build platform, and has to meet the platform's obligations itself, including keeping signing material away from jobs.

The third is treating the levels as a certificate rather than a direction. Level 3 everywhere is a fine goal. Level 1 everywhere, with verification at one real gate, is usually worth more than Level 3 on one showcase repository.

Provenance you never verify is paperwork. Verification at one real gate is security.

A practical path​

Start with inventory. List the artifacts that actually ship: images, packages, firmware, binaries. You can't attest what you can't name.

Then reach Level 1 broadly. Emit provenance for every shipped artifact, even unsigned. The value here is visibility, and it costs little.

Next, pick one gate and verify there. A deployment step or a cluster admission policy that refuses artifacts without valid provenance from a trusted builder turns the whole exercise from documentation into enforcement.

Only then climb: move generation into the platform for Level 2, and harden isolation and key handling for Level 3, starting with the artifacts whose compromise would hurt most.

None of this replaces scanning. It answers the question scanning can't: not "is this artifact safe?" but "is this the artifact I think it is?"

References​

1. OpenSSF, “SLSA Specification v1.0,” 2023. [Online]. Available: slsa.dev/spec/v1.0
2. in-toto, “in-toto Attestation Framework.” [Online]. Available: github.com/in-toto/attestation