Build provenance attestations: what SLSA provenance records and how it is verified

What it is

Provenance, in the SLSA specification, is verifiable information about how an artifact was produced: which entity built it, what process it used and what the inputs were. The Build track defines levels. Build L1: provenance exists, possibly unsigned; it prevents mistakes but is "trivial to bypass or forge". Build L2: a hosted build platform generates and signs the provenance, which protects against tampering after the build. Build L3: a hardened platform whose runs cannot influence one another and whose provenance signing material is not accessible to user-defined build steps, which protects against tampering during the build. The recommended format is an in-toto attestation with predicateType https://slsa.dev/provenance/v1. Its subject lists the output artifacts by digest. buildDefinition holds the buildType (a template identifying the process), externalParameters (the untrusted inputs, which must be recorded and verified downstream), optional internalParameters, and resolvedDependencies (what the inputs resolved to, for example the exact commit a repository URL pointed at). runDetails names the builder.id and run metadata. The build platform signs the envelope.

Why it matters

An SBOM says what is inside an artifact; provenance says who built it from what. With verified provenance a consumer can reject a package built from a commit that is not in the upstream repository, built by an unexpected workflow, or built with parameters that differ from the documented release process. Unverified provenance is documentation only.

How to apply

• Producer: build on a platform that generates and signs provenance, publish the attestation next to the artifact, and keep the build process consistent so that consumers can form expectations about it.
• Consumer: follow the specification's steps. Verify the envelope signature against configured roots of trust (a map from builder identity to the level it is trusted for); check that the subject digest matches the artifact and that predicateType is the SLSA provenance type; then compare buildType and externalParameters with expected values. The specification says unrecognised external parameters should fail verification.
• Decide the failure action (block, warn, log) before enabling verification, and start with artifacts where you control both ends.

Pitfalls

L1 provenance is forgeable; it catches mistakes, not attackers. Trusting a builder.id without pinning its key or certificate identity makes the signature meaningless. Provenance covers the build, not source review and not the dependencies' own builds; the specification's optional recursive dependency check and its separate Source track address those.