What is the difference between provenance generation and provenance verification in a SLSA program?

How provenance generation differs from provenance verification

Provenance generation is the build-time act of creating the attestation, so the pipeline can record where the artifact came from and how it was produced. Provenance verification is the release-time or deployment-time act of checking that attestation against policy before the artifact is allowed onward. The key difference is creation versus decision.

That distinction matters because the two steps answer different questions. Generation asks whether the build system can produce trustworthy evidence at all. Verification asks whether the evidence is complete, untampered, and acceptable for the control boundary you are enforcing. A SLSA program only works when both exist and are consistently tied to the same artifact identity.

In practice, generation is owned by the build path, while verification is owned by the consuming control point. A strong program treats provenance as part of the artifact, not as a separate document that can be checked later by hand. The attestation should travel with the build output so downstream policy engines can make an automatic pass or fail decision.

Where each step sits in the software supply chain

Generation happens in the trusted build environment, close to source checkout, dependency resolution, compilation, packaging, and signing. Its job is to capture the relationships that matter for traceability: source revision, builder, build inputs, and output artifact. The more deterministic and hermetic the build path, the easier it is to produce provenance that is both accurate and useful.

Verification happens outside the build, usually where a release, artifact registry, admission controller, or deployment pipeline decides whether to trust what it received. The verifier checks that the attestation matches the expected source, pipeline, identity, and policy conditions. For a practical overview of the build side, see SLSA and Build Provenance Guide, which covers the relationship between build provenance, attestations, and deploy-time checks.

This split is important because a good attestation does not automatically mean a trustworthy release. A pipeline can generate provenance and still fail to enforce it. Likewise, a verifier can be strict and still be useless if the provenance was never generated, was generated outside the trusted path, or does not describe the artifact actually being released.

What good control design looks like in a SLSA program

Good design makes provenance generation routine and provenance verification mandatory. Generation should be automated in the build system so every releasable artifact has evidence by default. Verification should be enforced at the point where failure is still safe, such as before promotion to production or before admission into a protected environment.

That is why teams often pair provenance with policy. The policy defines what counts as sufficient evidence for this artifact, this environment, and this release channel. The build system then emits the attestation, and the verifier applies the rule set. For teams standardising this path, the in-toto Attestations Guide is useful because it explains the attestation structure, verification flow, and policy rejection logic behind SLSA provenance.

It also helps to keep the evidence model narrow. Verification should not become a vague trust review. It should be a concrete decision on whether the attestation satisfies the stated release policy, including the required build lineage, signing expectations, and any environment or repository constraints. If those conditions are not explicit, verification becomes subjective and loses its value as a control.

Risk and Threat Considerations

Provenance generation and verification fail differently. If generation is weak, the build can emit evidence that is incomplete, misleading, or easy to forge. If verification is weak, even a well-formed attestation may be accepted when the artifact was built in the wrong pipeline, from the wrong source, or with the wrong trust assumptions.

Failure mechanism: Attackers or compromised build paths can tamper with the artifact or the build inputs, then rely on missing, stale, or poorly validated provenance to move the bad build downstream.

Impact: The organisation may release or deploy an artifact that appears trusted but is not actually traceable to an approved build process, weakening supply-chain integrity and making rollback, incident scoping, and trust decisions harder.

Practitioner Guidance

What to verify: Treat generation and verification as separate control tests. First confirm that the build pipeline always emits provenance for the intended artifacts, then confirm that downstream gates reject artifacts when the attestation is missing, mismatched, or outside policy.

Decision rule: If you can produce provenance but cannot enforce it at release time, you have traceability but not control. If you can verify provenance but do not reliably generate it from the trusted path, you have a policy that cannot be satisfied at scale.

Practitioner takeaway: The mature pattern is to make provenance generation automatic, provenance verification mandatory, and the policy between them explicit enough that no human judgement is needed at release time.

Related resources from NHI Mgmt Group

• How do you know if an age verification program is actually audit-ready?
• Why is provenance generation alone not enough to reduce software supply chain risk
• What breaks when organizations rely on retrieval augmented generation without provenance controls?
• How should security teams use AI code generation without losing independent verification?