SLSA build provenance is a signed or otherwise authenticated statement about how a software artifact was produced. It can link a package digest to a builder, build definition, external parameters and resolved dependencies. It does not prove that the source code is safe or that the build process had no flaw.
SLSA stands for Supply-chain Levels for Software Artifacts. Version 1.2 separates its requirements into tracks. This explainer focuses on the Build track and the provenance used to assess it.
Specification checked: SLSA v1.2 Build Track Basics, Build Requirements, Build Provenance and Threats were reviewed on 27 October 2026.
Start with the artifact digest
A verifier needs to know which artifact a provenance statement describes. SLSA provenance uses an in-toto statement whose subject includes one or more artifact names and cryptographic digests.
The digest is the practical anchor. If the downloaded package’s digest differs from the subject digest, the provenance applies to something else.
A filename alone is not enough. The same name can be reused for a different release, mirror or rebuild.
What provenance can record
SLSA v1.2 build provenance can describe:
- the artifact subject and digest;
- the builder identity;
- the build type;
- external parameters supplied to the build;
- internal parameters kept by the builder;
- resolved dependencies;
- the build’s start and finish times;
- whether the build was complete and reproducible under the declared conditions;
- the source or configuration used as the build definition.
The exact fields depend on the provenance format and build type. A verifier should understand the predicate type before treating an unfamiliar field as evidence.
The Build track levels
| Level | Core idea | What it adds |
|---|---|---|
| Build L0 | No guarantees | No SLSA requirement |
| Build L1 | Provenance exists | A record of how the package was built |
| Build L2 | Hosted build platform | Signed provenance generated by a hosted platform |
| Build L3 | Hardened builds | Stronger protection against tampering during the build |
Source: SLSA v1.2 Build Track Basics, checked 27 October 2026.
The levels are cumulative within the Build track. A project does not reach L3 merely by attaching a signature to a local build. The platform and isolation requirements matter.
Build L1: provenance exists
At L1, the package has provenance that identifies how it was built. This helps with inventory, debugging and detecting some mistakes.
L1 does not require a hosted platform to generate the statement. The producer can create provenance about its own build, so the evidence remains forgeable by someone who controls that process.
The value is still real: a verifier can require expected source, build type and parameters instead of accepting an opaque binary.
Build L2: signed hosted provenance
L2 adds a hosted build platform and authenticated provenance generated by that platform. The goal is to make tampering with the artifact after the build easier to detect.
The signing identity should belong to the build service, not to a developer’s ordinary account. A verifier needs a policy that says which builder identities are trusted for which packages.
A valid signature only proves that the key authenticated the statement. It does not prove the key was authorised for this project. That authorisation belongs in verification policy.
Build L3: hardened builds
L3 raises the bar against tampering during the build. The platform must meet stronger isolation and control requirements so a build cannot simply alter another build or its provenance.
This is a property of the build platform and its implementation, not a label a package maintainer can self-assign. SLSA provides requirements for assessing the platform.
L3 narrows important attack paths, but it does not audit the source code or guarantee that the intended source was trustworthy.
Signed provenance needs a verification policy
A useful policy answers at least four questions:
- Which artifact digest is being verified?
- Which provenance predicate and version are accepted?
- Which builder identities are trusted?
- Which source repository, branch, tag or build configuration is allowed?
Without those checks, a perfectly valid statement from the wrong builder can pass.
The policy can also constrain external parameters. For example, a release build may need a specific workflow file, release tag and build target. Unexpected debug flags or an untrusted dependency source should fail the policy even when the signature is valid.
Provenance is different from an SBOM
A software bill of materials lists components and dependencies. Build provenance records how an artifact was produced.
They overlap around dependencies, but they answer different questions:
- SBOM: What components are in or associated with this software?
- Provenance: Who built this artifact, from which inputs, with which process?
- Signature: Which key authenticated this statement or artifact?
- Vulnerability report: What known issues match the identified components?
Our SBOM explainer covers the inventory side. A mature release can publish both an SBOM and provenance.
Provenance does not make source code safe
A hardened, correctly attested build can faithfully produce malicious or vulnerable code. SLSA focuses on supply-chain integrity: reducing the chance that the artifact differs from the declared process or that an unauthorised actor altered the build.
Source review, testing, dependency analysis and vulnerability management remain necessary.
The distinction matters during procurement. “SLSA L3” is not a general security score. It is a claim about requirements within a specific track and version.
Verify before installation
A practical verification flow can be:
- Download the artifact and provenance from the distribution channel.
- Compute the artifact digest locally.
- Verify the provenance signature or transparency evidence.
- Confirm the subject digest matches the artifact.
- Check the predicate type and version.
- Match the builder identity to an allowlist.
- Check source, build definition and parameters against release policy.
- Reject or quarantine the artifact when any required field is absent or unexpected.
Run verification in the package pipeline, not only as a manual investigation after an incident. Store the result with the deployment record so operators can show what was checked.
What can go wrong
Provenance from the wrong builder
The signature is cryptographically valid, but the builder is not approved for the package.
Digest mismatch
The statement describes the official artifact while the downloaded file was replaced, recompressed or rebuilt.
Ambiguous source
The provenance points to a repository but not the expected revision or build definition.
Unchecked parameters
The artifact was built with an unexpected flag, dependency mirror or target.
Self-attestation treated as hardened evidence
L1-style provenance created by the same process that emits the artifact is presented as if it had independent platform controls.
A trusted platform with a weak workflow
The platform is hardened, but the workflow downloads mutable scripts or accepts unreviewed input. Platform assurance does not remove the need to inspect the build definition.
Reproducibility and provenance
A reproducible build can be rebuilt from the same inputs to produce the same output. Provenance records the claimed inputs and process. They reinforce each other but are not identical.
Provenance can exist for a non-reproducible build. A reproducible build can lack authenticated provenance from the publisher. Use each property for the question it answers.
Version the claim
SLSA has changed across releases. Version 1.2 uses Build L1 through L3 and track-specific terminology. Older material may show a single L1-to-L4 ladder.
Record the SLSA specification version, track and level together. “SLSA level 3” without a version and track is incomplete.
A release-team checklist
- Publish provenance for every release artifact, not just one archive.
- Identify subjects by cryptographic digest.
- Use a hosted builder capable of the claimed level.
- Protect signing identities in the build service.
- Keep build definitions in version control.
- Pin or otherwise constrain external build inputs.
- Verify builder, source and parameters in policy.
- Test failure paths with a wrong digest and wrong builder.
- Keep provenance available for incident response.
- State the SLSA version and track in documentation.
