What is SLSA? Build provenance and levels explained

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is an OpenSSF framework for build integrity. It defines levels of assurance that an artifact was built from the source you expect, by the build process you expect, without tampering along the way. The evidence it relies on is provenance: a statement, signed by the build platform at the higher levels, saying which artifact was built, from which source, by which builder and with which parameters. Consumers verify that statement before they deploy.

This page goes deeper on the SLSA part of What is software supply chain security?.

The problem SLSA addresses

Code review protects the source. It does nothing if the artifact you deploy was not built from the reviewed source. Between a reviewed commit and a running service there is a build: a CI job, its scripts, its runner, its credentials, its dependencies and the registry it publishes to. An attacker who controls any of those can ship something nobody reviewed.

This is not hypothetical. The 2020 SolarWinds compromise inserted malicious code during the build, so the shipped product differed from the source. SLSA's build requirements are aimed at making that kind of attack hard to do and easy to detect.

The SLSA build levels

SLSA version 1.0 organised its requirements into tracks. The build track has four levels:

The levels are cumulative. Level 1 is mostly about having provenance at all. Level 2 makes forging it require compromising the build platform. Level 3 makes compromising one build insufficient to forge provenance for another.

The specification continues to develop, including work on requirements for source control. Check the current version on the SLSA site for what is final.

What provenance contains

SLSA provenance is usually an in-toto attestation: a signed statement about one or more artifacts. The statement names the artifacts by digest, and its predicate describes how they were built. A trimmed example:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{ "name": "checkout-2.4.0.tar.gz", "digest": { "sha256": "…" } }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://ci.example.com/workflow/v1",
      "externalParameters": { "repository": "https://git.example.com/acme/checkout", "ref": "refs/tags/v2.4.0" },
      "resolvedDependencies": [
        { "uri": "git+https://git.example.com/acme/checkout@refs/tags/v2.4.0", "digest": { "gitCommit": "…" } }
      ]
    },
    "runDetails": {
      "builder": { "id": "https://ci.example.com/hosted-runner" },
      "metadata": { "invocationId": "…" }
    }
  }
}

The parts that matter most:

• subject: the artifact, identified by its hash. Provenance about a different hash says nothing about your file.
• buildDefinition: what was built and how, including the source repository, the ref and the exact commit that was resolved.
• runDetails.builder.id: which build platform produced it. Verification checks this against a list of builders you trust.

The statement is signed, typically in a DSSE envelope, and often with Sigstore, which ties the signature to the identity of the build workflow rather than to a long-lived key.

Verifying provenance

Provenance only helps if someone checks it before the artifact is used. Verification asks:

1. Is the signature valid, and does it come from a builder you trust?
2. Does the subject digest match the artifact you are about to deploy or install?
3. Is the source what you expect: the right repository, and a tag or branch you release from?
4. Are the build parameters expected, with no unexpected inputs?

Tools exist for this, such as the SLSA project's verifier and Sigstore's tooling, and some ecosystems build it in. npm, for example, can publish packages with provenance from supported CI providers, and registries can display it. The most valuable place to verify is the last step before deployment, as part of the deploy gate.

What SLSA does not cover

SLSA build levels are about the integrity of the build. They do not tell you:

• whether the source code is free of vulnerabilities or bugs;
• whether malicious code was reviewed and merged by someone with access;
• whether your dependencies were built with similar care, unless they publish their own provenance;
• which components are inside the artifact. That is what an SBOM is for.

SLSA, SBOMs and the SSDF

They complement each other. A mature release can carry all three: an SBOM, signed provenance, and an organisation that can attest to the SSDF practices.

Build pipelines and AI agents

Build definitions are code. A CI workflow file that an AI agent edits can change how artifacts are built, which secrets the build can use and where it publishes. Treat changes to build and pipeline definitions as sensitive: require a specific review for them, and keep the agents that write code away from build credentials. Provenance helps after the fact, because it records which workflow built an artifact, so a modified workflow shows up when provenance is verified.

Getting started

1. Inventory your release paths. List every way an artifact reaches production or a registry, including manual releases from a laptop. Provenance only helps for the paths that produce it.
2. Build releases in CI only. An artifact built on a developer machine has no trustworthy provenance. Moving all release builds to a hosted CI service is the biggest single step.
3. Turn on provenance generation. Many CI services and package registries can generate and publish provenance for you. That gets you level 1, and often level 2.
4. Verify before deploy. Add a verification step to the deploy pipeline that checks the signature, the builder, the source repository and the artifact digest, and fails closed when any of them does not match.
5. Harden the build. Isolate builds, keep signing material away from build steps, and limit who can change build definitions. That is the path towards level 3.

How AI CodeOps relates to SLSA

AI CodeOps does not build your artifacts or generate SLSA provenance; your own CI does the build, and that is where provenance is produced. AI CodeOps covers the steps before the build: how a change was written, reviewed and approved.

• Protect build definitions with policy. A diff.apply rule with decision ask on paths such as .github/** or .forgejo/** requires an approved review before a change to those files becomes a pull request. A deny rule blocks it.
• Keep credentials out of agents' reach. Workspace secrets reach build jobs as environment variables and are removed from build logs; AI agents never receive them.
• Record how each change was made. Each change can be downloaded as a signed evidence pack: the task, models, steps, findings, tests, approvals and delivery, signed with Ed25519 and verifiable offline. It plays a similar role for the authoring of a change as provenance does for the build.

See Approvals and policies for path rules and Security and SBOM tracking for the overview.