Artifact Provenance Must Survive the Promotion Boundary

A pipeline can generate signed provenance and still deploy an unverified artifact. The gap usually sits between building and promotion: an image tag is mutable, an emergency job takes a different path, or verification happens against a file that is not the one ultimately executed.

I would place the security decision at promotion and bind it to the artifact digest. Build-time checks remain useful, but the deployment boundary must verify what it is about to trust.

Define acceptance before choosing tooling

For a hypothetical service, the policy might require these conditions:

artifact digest == attestation subject digest
builder identity belongs to the approved build platform
source repository == the service's registered repository
source revision == the reviewed release revision
build configuration belongs to the approved workflow
attestation signature and trust chain verify

This is policy pseudocode, not a verifier implementation. Signature validity alone does not establish that an artifact came from the expected source or builder. SLSA’s artifact verification guidance separates verification of provenance from checking the consumer’s expectations. The linked version is a useful baseline for that distinction, not a claim that it is the newest specification.

Resolve an image tag to a digest and deploy that digest. If verification inspects one digest and the deployment later pulls a changed tag, the control has a time-of-check/time-of-use gap.

Treat rollback as another promotion

A previously deployed artifact may no longer meet today’s policy. Its builder might be distrusted, its dependencies might carry a newly relevant vulnerability, or its configuration might be incompatible with the current database schema.

I would keep a small set of verified rollback candidates with their compatibility constraints. An emergency exception should identify the exact digest, environment, approving role, and expiration. It should not turn off verification for every release in the account.

Provenance also does not prove that code is safe. A compromised approved source repository can produce faithfully attested malicious code. Source review, branch controls, build isolation, dependency policy, and runtime containment address different parts of the chain.

Roll out without making release engineering the enemy

Start by observing real promotion traffic and explaining failures in terms developers can act on: missing evidence, wrong builder, unexpected source, or digest mismatch. Then enforce on a service with a supported release path and an exercised recovery process.

Platform engineering owns reliable verification and usable error messages. Service owners own their source and workflow declarations. Security owns the trust model and exception criteria. An incident commander needs a documented emergency route before the ordinary route fails at night.

I would test a valid artifact, a valid signature from the wrong builder, a changed tag, missing provenance, and an expired exception. Report coverage as the proportion of actual deployment paths enforcing the policy. Counting signed builds misses the unverified path that an attacker or hurried operator can still use.