Build Provenance

Build provenance is a record of how an artifact was produced: its builder, inputs, and build parameters. An authenticated attestation adds evidence about the origin and integrity of that statement. These are not interchangeable guarantees: SLSA v1.1 Build L1 can provide provenance that is unsigned or incomplete.

SLSA’s purpose for the record is to let consumers compare a build with their expectations. Define the accepted builder, source, and process before verification. A matching record supports those claims; it does not establish that the resulting code is safe.

What it asserts, and what it cannot

SLSA’s builder identifier represents the platform and the entities trusted to execute the build and record its provenance. Accepting an authenticated record therefore relies on that trust boundary, as well as on checks that the signer is authorized to speak for the claimed builder.

What it cannot assert is that the result is safe, and the specification’s own build model says why: “the steps within the build environment are under the tenant’s control.” If the repository is compromised, the build steps are the attacker’s steps, and the platform will faithfully attest to having run them. Provenance turns we do not know where this came from into this came from that source through that process, which is what makes an intrusion traceable and a forged artifact rejectable. It does not review the code.

An independent reproducible build compares output bytes from declared source, environment, and instructions. It reduces reliance on the original builder but retains trust in the source, toolchain, rebuilding environment, and comparison. The same compromised compiler can reproduce the same malicious bytes. Matching outputs do not prove the original run’s identity, time, or approval; authenticated provenance addresses those recorded claims within its assurance and coverage.

Verification enables release-rule enforcement

An unchecked record can assist investigation but does not enforce a release rule. A consumer may verify it directly or delegate to a verifier. In either case, the acceptance decision needs protected expectations and a path that rejects mismatches.

Four expectations are worth stating explicitly, because a verifier that checks only the signature accepts anything the attacker can get built.

• The expected signer and builder. Authenticate the statement and check that its signer is authorized for the claimed builder. A valid signature from an unrelated platform is insufficient.
• The expected source. The repository and revision the build claims to have used, so an artifact built from a fork or a branch nobody reviewed is visible.
• The expected process. Check the build type, permitted workflow, and external parameters. SLSA v1.1 recommends rejecting unrecognized or unexpected fields within externalParameters, because these inputs can change the build. This is not a blanket rule for all provenance fields: the specification permits extension fields whose unknown contents can be ignored without changing the defined meaning.
• The artifact identity. The digest the record is about, since an artifact is “an immutable blob of data” and the digest is what makes the statement bind to one specific blob rather than to a name or a tag.

Build-time verification provides early feedback. Registry-ingestion verification can exclude unacceptable artifacts but cannot cover later registry or transit compromise. Consumer-side deployment or admission checks can cover the artifact actually about to run. In any location, protect verifier code, trust roots, policy, approval evidence, and deployment credentials from the build’s control, and close bypass paths. A deployment pipeline is not inherently compromised merely because it shares orchestration with a build; separate identities are not sufficient if an attacker can modify both. This enforcement question is developed in policy enforcement point.

Three common misreadings

The first is treating a signature as provenance. A signature says a key signed these bytes; provenance says which platform produced them from which inputs. Both are useful and they answer different questions, and a signing step added at the end of a pipeline tells you nothing about the inputs.

The second is assuming every dependency is captured. SLSA v1.1 treats resolved-dependency completeness as best effort. A software bill of materials can add component evidence, but its coverage also depends on generation inputs and tools. Check missing inputs and approved origins explicitly; neither document’s presence proves that all components were approved.

The third is treating all provenance as equally resistant to forgery. In SLSA v1.1, Build L1 supplies provenance without requiring authentication. L2 adds a hosted platform and authenticated, platform-generated provenance, with specified allowances for tenant-supplied fields, including the subject and non-required fields. L3 strengthens isolation and resistance to tenant forgery; signing secrets must not be accessible to user-defined build steps. Dependency completeness remains best effort. A build script signing arbitrary claims with a key it can read does not acquire L3 protection merely by producing a signature.

How provenance, inventories, dependency resolution, and pipeline permissions combine across the development lifecycle is worked through in The Pipeline Had the Keys.

References (SLSA discussion uses v1.1):

• SLSA v1.1, Provenance — purpose, model, builder identity, and verifier expectations.
• SLSA v1.1, Terminology — definitions of attestation, artifact, and dependency, the build model, and the producer, verifier, and consumer roles.
• SLSA v1.1, Verifying artifacts
• Reproducible Builds, Definition
• SLSA v1.1, Security levels
• SLSA v1.1, Requirements