10.2 Build Provenance and SLSA 1.2

Provenance describes how an artifact is produced: which builder, which build definition, what top-level inputs, and what the output digest is. It complements an SBOM: while an SBOM answers "what's inside," provenance answers "where it came from and how it was built."

Attestations Bind Claims to Artifacts

subject: artifact sha256:abc...
predicateType: SLSA provenance
predicate:
  builder identity
  build type and parameters
  source revision and dependencies
  invocation/environment metadata
signature / transparency evidence

This is a conceptual structure, not complete in-toto JSON. The subject identifies the artifact; signer identity comes from the signature and trust configuration. Consumers must verify both the signer and the claims, not merely the presence of an attestation. Attackers can easily generate legitimate signatures for malicious artifacts; the key issue is whether policy trusts the builder to produce that artifact for this repository/build type.

SLSA 1.2 Uses Multiple Tracks

Old materials often listed SLSA L1–L4 as a single track; this lesson uses approved SLSA 1.2, with independent Build and Source tracks.

Build track:

L0: No guarantee
L1: Record build provenance and make it available to consumers
L2: A hosted build platform generates and signs provenance
L3: hardened build platform, further resistant to build-time tampering

The Source track covers how source revisions are created and controlled: Source L1 uses version control, L2 adds history and provenance, L3 enforces organizational technical controls, and L4 requires two-party review. An artifact's Build level does not establish that its dependencies reach the same level, nor does it guarantee that the source code lacks malicious logic.

Don't continue referencing the old "L4 builds must be reproducible and require two-person review" as the current 1.2 requirement; these qualities still hold value, but should be expressed separately based on current track and organizational strategies.

Builder is part of the trust root

If a project build script can obtain the platform's provenance signing key or make it sign arbitrary fabricated claims, consumers cannot treat those claims as independent platform evidence. High-security builds require provenance to be generated by the platform's control plane, ensuring the build job cannot arbitrarily forge it and that builds are isolated across tenants/builds.

Whether a self-hosted runner meets the requirements depends on who generates provenance, who holds signing capability, and whether the runner can influence these assertions. You can't automatically claim a certain level just because the interface displays "hosted CI."

The platform should:

• Use temporary isolated build environments and destroy them after completion;
• Pin and verify build images and toolchains;
• Define policies for network dependencies, caches, and secrets;
• Generate provenance that the build job cannot forge;
• Fix the source revision and build definition;
• Record platform and policy versions and support auditing.

Hermetic and reproducible builds answer different questions

Hermetic builds declare and control all inputs and never fetch materials from unknown networks or host states during construction. Reproducible builds mean that identical inputs produce identical outputs independently. The former improves input integrity, while the latter provides cross-verification capability; reproducibility does not guarantee source code is free of malicious content, and hermeticity does not automatically ensure byte-for-byte consistency.

Timestamps, paths, random seeds, compression order, and toolchain differences all undermine reproducibility. Start by eliminating nondeterminism from key artifacts and have independent builders compare digests.

Consumers must form expectations

Validation strategy example:

artifact digest matches attestation subject
AND source repository == expected repo
AND source revision is protected and reviewed
AND builder identity in approved builders
AND build type/parameters match release workflow
AND provenance signature/transparency evidence valid

For example, reject a matching output digest when the builder belongs to a personal fork. Reject an approved builder if it used unapproved release parameters. A claim that source was reviewed needs trusted source-control evidence or an external policy query; a commit identifier alone does not establish review.

Storing provenance without checking it at release/deployment cannot reject an unexpected artifact at that boundary. The next lesson connects signatures, transparency logs, and admission policy into an acceptance decision.

References

• SLSA, Specification v1.2
• SLSA, Build Track
• SLSA, Source Requirements
• in-toto, Attestation Framework