Software Supply Chain Security / Build Integrity

SLSA & Build Provenance Attestations

Knowing what dependencies are inside a software artifact (via an SBOM) is only half of the software supply chain puzzle. The second question is: how was this artifact built, and was the build platform tampered with? Supply-chain Levels for Software Artifacts (SLSA) provides a specification for build integrity. SLSA establishes verifiable build provenance attestations—using in-toto schemas—to prove that a specific binary was generated by a trusted, isolated build platform from a specific source commit.

SLSA v1.2 Build track levels, the in-toto provenance predicate, and where build integrity stops

SLSA v1.2 Build track levels

The SLSA v1.2 specification was approved in November 2025. It organizes build integrity into graduated levels on a Build track:

SLSA level	Build track requirements	Security & integrity guarantee
Build L0	No requirements — L0 represents the absence of SLSA.	No build integrity or provenance guarantees.
Build L1	The producer follows a consistent build process, the platform generates provenance describing the builder, process, and top-level inputs, and that provenance is distributed to consumers. Provenance may be incomplete or unsigned at L1.	Detects mistakes during release and aids debugging and rebuilding.
Build L2	All of L1, plus the build runs on a hosted build platform that generates and signs the provenance itself, and the consumer validates its authenticity. SLSA recommends, but does not mandate, a digital signature as the authenticity mechanism.	Prevents tampering after the build; the build ran on shared or dedicated hosted infrastructure rather than an individual’s workstation.
Build L3	All of L2, plus the platform is hardened: strong controls prevent build runs from influencing one another, and prevent platform secret material from being reachable by user-defined build steps.	Prevents tampering during the build — by insider threats, compromised credentials, or other tenants.

Note: always specify both the track and version when declaring compliance (e.g. SLSA Build L3 (v1.2)). “SLSA level” alone is ambiguous across specification versions — v1.x replaced the earlier v0.1 numeric 1–4 scale.

SLSA v1.2 also promoted a Source track from experimental to approved, covering the authoring, review, and management of source revisions. Build Environment and Dependency tracks remain in development. This page covers the Build track only.

in-toto provenance JSON schema

SLSA provenance is formatted as an in-toto attestation predicate. It links an output artifact’s cryptographic hash (subject) to the exact build parameters and platform identity (builder):

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "release-binary-linux-amd64",
      "digest": {
        "sha256": "3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://actions.github.io/buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/heads/main",
          "repository": "https://github.com/example/repo",
          "path": ".github/workflows/build.yml"
        }
      },
      "resolvedDependencies": [
        {
          "uri": "git+https://github.com/example/repo@refs/tags/v1.2.0",
          "digest": {
            "gitCommit": "4f8a923b7c50188cabbfb72cf0fd9fe288364bc4"
          }
        }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/example/repo/.github/workflows/build.yml@refs/heads/main"
      }
    }
  }
}

Digest and commit values above are illustrative placeholders, not real artifact hashes.

Two fields carry the trust decision and are worth getting exactly right, because a verification policy pins them:

buildType names the schema that the parameters follow. GitHub’s own artifact attestations use https://actions.github.io/buildtypes/workflow/v1; the SLSA community definition used by slsa-github-generator is https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1. Use the value your builder actually emits.
builder.id identifies the trusted builder. GitHub sets it to the server URL plus the job workflow reference, as shown above. A policy that pins the wrong builder ID matches nothing and silently fails open or closed depending on how it is written.

Hermetic and reproducible builds sit beyond Build L3

Two build properties are frequently and incorrectly described as SLSA Build L3 requirements. They are neither required nor sufficient for L3 — SLSA explicitly treats network isolation as a future direction rather than a current requirement, and the Build track requirements do not mention reproducibility at all. Both are worth adopting on their own merits:

Hermetic builds: build steps run in a network-isolated environment where all dependencies (compilers, libraries, header files) are explicitly declared, pinned, and fetched into local caches before execution begins. No undeclared external network calls occur during compilation.
Reproducible builds: two independent builds from the same source, build environment, and instructions produce bit-for-bit identical outputs, so an independent party can rebuild and compare rather than trusting the builder.

What Build L3 does require is narrower and specifically about the platform: isolation between build runs, and keeping platform signing material out of reach of user-defined build steps.

The boundary of SLSA: provenance vs. source integrity

A critical security distinction must be maintained when evaluating SLSA guarantees:

SLSA Build provenance proves HOW an artifact was built — by which builder, from which source S.

SLSA Build provenance does NOT prove that source S or its dependencies are benign.

If a trusted maintainer commits a backdoor to the source repository, a SLSA Build L3 platform will faithfully compile it and emit valid, signed provenance saying exactly that. Build integrity is not source intent, and no Build track level claims otherwise.

The xz-utils backdoor (CVE-2024-3094) is often cited here, but it is a different case and worth separating: that payload reached users through a release tarball that diverged from the Git tree, which is precisely the divergence build provenance is designed to expose. A build that produced the tarball from the tagged commit, and published provenance saying so, would have made the divergence visible. See Code Signing, Binary Integrity & Sigstore for that case in full.

SLSA diagnostic checklist

The checklist below is a journal working model, not a published audit standard. When auditing software build pipelines against SLSA, evaluate these six criteria:

Diagnostic area	Architectural evaluation question	Verification & audit evidence
Level declaration	Is the build target evaluated against explicit SLSA v1.2 Build track levels, naming both track and version?	Organization SLSA compliance audit record.
Authentic signed provenance	Is in-toto provenance generated and signed by the hosted build platform, rather than by the build steps themselves?	Signed in-toto attestation files & public key/certificate checks.
Hosted builder enforcement	Are release builds restricted to hosted build infrastructure, blocking developer laptop builds?	CI/CD pipeline triggers & runner execution logs.
Policy pins the right fields	Does the verification policy pin `builder.id` and `buildType` to the values the intended builder actually emits?	Verifier policy configuration compared against a real attestation.
Verification gate deployment	Do deployment environments verify artifact digests against signed provenance prior to execution?	Kubernetes admission controller rules (Cosign/Kyverno policy).
Dependency commit pinning	Are build tools and upstream dependencies pinned to immutable digests?	Build definition files (`build.yml`, Dockerfile `FROM ...@sha256:`).

What I need to remember

SLSA v1.2 Build track (L1–L3) verifies how an artifact was built, using signed in-toto provenance; L3 means the platform isolates runs and protects its own secrets, not that the build is hermetic or reproducible. A verification policy is only as good as the builder.id and buildType it pins. Build provenance does not prove the source was benign.

Primary references

SLSA v1.2 specification — verified the approved version, the Build track level definitions, and the presence of an approved Source track.
SLSA v1.2 build requirements — verified that hermetic builds are explicitly not an L3 requirement and are deferred to future directions.
in-toto attestation framework — verified the Statement v1 structure and predicate types.
GitHub Actions buildtypes (SLSA community) — verified the community buildType URI and its external-parameter schema.