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

Provenance generation creates the attestation that records how an artifact was built, including source, pipeline, and artifact relationships. Provenance verification checks that attestation against policy before release or deployment. Generation is about producing trustworthy evidence, while verification is about deciding whether that evidence is sufficient for the intended control boundary.

Why SLSA Separates Evidence Creation from Policy Decision

SLSA treats provenance generation and provenance verification as two different control points because they answer different trust questions. Generation asks whether the build system can produce a faithful record of what happened; verification asks whether a consumer should trust that record enough to release, deploy, or promote the artifact. That separation matters because a build can be repeatable or well-instrumented yet still fail a downstream policy check, and a verified attestation can still be useless if the generator was not trustworthy in the first place.

For practitioners, the distinction is important when defining release gates, supply-chain trust, and provenance retention. A team that only generates provenance may still ship unreviewed artifacts, while a team that only verifies provenance may miss gaps in build integrity or attestation provenance. In SLSA, both sides have to line up: the producer must create evidence that can be trusted, and the consumer must apply a policy that matches the deployment boundary and threat model. In practice, many security teams discover the gap only after a release pipeline accepts evidence that no one had actually validated against policy.

How Provenance Generation and Verification Work Together

Provenance generation happens inside or alongside the build process. The build system records the source revision, build parameters, builder identity, dependency inputs, and the relationship between the resulting artifact and the steps that produced it. The output is an attestation, usually signed or otherwise bound to a trusted issuer, so that later consumers can inspect it without relying on informal claims from the build team.

Provenance verification happens later, at the point where a human or automated policy engine decides whether the artifact is acceptable. That decision typically checks whether the attestation exists, whether it is intact, whether it was issued by an approved builder, and whether the recorded conditions match the organization’s policy. In other words, generation is a producer-side integrity function, while verification is a consumer-side trust decision.

Generation answers: what was built, from what inputs, and by which process?
Verification answers: does this attestation satisfy the rules for release or deployment?
Generation is strongest when the build path is controlled, logged, and resistant to tampering.
Verification is strongest when policy is explicit, narrow, and tied to the intended use of the artifact.

For supply-chain teams, the practical consequence is that provenance only adds value when both stages are present. A signed attestation from an untrusted or poorly governed pipeline may be rejected, and a strict policy with no reliable provenance source leaves reviewers with no evidence to evaluate. That is why SLSA programs usually treat the builder, the attestation format, and the verification policy as linked but separate controls. More detail on the attestation model is available from the SLSA provenance specification, which helps clarify what the generated record is expected to contain.

The guidance breaks down when organisations treat verification as a paperwork step rather than a control decision, or when they generate attestations from pipelines they cannot actually trust.

Where the Distinction Gets Tricky in Real Builds

Tighter provenance requirements often increase pipeline complexity, so organisations have to balance stronger evidence against build latency, operational overhead, and toolchain consistency.

One common edge case is disagreement about what “sufficient” verification means. Some consumers only require that provenance exists and is cryptographically valid. Others require the attestor, builder identity, source repository, and dependency chain to match a stricter policy. There is no single universal threshold, because the acceptable control boundary depends on whether the artifact is being used for internal testing, production deployment, or a high-assurance release path.

Another edge case is partial provenance. A build may record some inputs accurately but omit critical metadata, use a shared builder that is too broad for policy, or produce attestations that are formally valid but operationally weak. In those cases, generation has technically occurred, but verification should still fail because the evidence does not support the intended trust decision. The reverse can also happen: a team may have a strong verification policy, but if provenance is not generated from a controlled and attributable build path, the policy can only reject or downgrade trust.

Consensus is strong that generation and verification should be separated, but practitioners still disagree on how strict the verification boundary should be for non-production environments. The safest pattern is to define policy by release tier, not by convenience, and to avoid assuming that any attestation is automatically meaningful. The model stops working when provenance is detached from a trusted builder or when verification is reduced to a binary check that ignores the artifact’s actual deployment context.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	15 — Service Provider Management	SLSA provenance verification governs trust in external build and supply-chain services.
	8 — Audit Log Management	Provenance generation depends on logged build activity and traceable evidence.
Recommendation — Require evidence from trusted suppliers and validate it before accepting build artifacts. Record build events and attestation creation so verification has auditable evidence.
NIST CSF 2.0	PR.DS — Data Security	Provenance protects the integrity of software artifacts and their metadata.
	GV.SC — Supply Chain Risk Management	SLSA is a supply-chain assurance problem centered on artifact trust decisions.
Recommendation — Apply integrity checks to artifacts and attestations before deployment. Define supply-chain trust criteria for provenance generation and verification.
MITRE ATT&CK	T1218 — System Binary Proxy Execution	Untrusted build artifacts can be abused as trusted execution paths if verification is weak.
Recommendation — Hunt for unauthorized artifact paths that bypass normal trust and release controls.

Practitioner Guidance

What to prioritise: Treat provenance generation and provenance verification as separate ownership domains. Build teams should be responsible for producing complete, attributable attestations, while release or platform teams should own the policy that decides whether those attestations are acceptable.

What to verify: Confirm that the attestation reflects the actual build path, not just the intended one. The most important check is whether the recorded builder, source reference, and artifact relationship are precise enough that a verifier can make a meaningful release decision.

Decision rule: If the provenance record cannot be tied to a controlled builder and a defined policy boundary, treat it as insufficient evidence rather than “almost verified.” Verification should fail closed when attribution or completeness is uncertain.

Practitioner takeaway: The mature SLSA pattern is not “generate provenance and then hope it helps”; it is “generate evidence from a trustworthy build path, then verify it against a release-specific policy that matches the real risk.”