10.2 Building Provenance and SLSA 1.2

Provenance describes how a product is created: 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."

Attestation Bind assertions to subjects

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

Consumers must verify the signature subject and the contents of the assertions, rather than confirm "there is an attestation alone." Attackers can easily generate legitimate signatures for malicious artifacts; the key issue is whether the strategy 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; the current official 1.2 version has split them into separate tracks.

Build track:

L0: No guarantee
L1: Provenance exists
L2: Generated and signed by the hosted build platform with provenance
L3: hardened build platform, further resistant to tampering during construction

Source track focuses on the generation and control of source code revisions, including version control, history/provenance, continuous technical control, and peer review at progressive levels. A build's level does not automatically prove dependency at 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's own build script can forge a provenance signing key, the proof becomes meaningless. 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:

• Temporary, isolated, and destroyed after task completion;
• Build and verify the image and toolchain;
• Clear strategies for network dependency, caching, and secrets;
• The platform generates non-forgable provenance;
• Fix the source revision and build definition;
• Log platform and strategy 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

Storing only provenance without verifying it at deployment time means you can only conduct post-incident forensics, not prevent tampering. In the next lesson, we'll connect signatures, transparent logging, and admission policies into a true acceptance decision.

References

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