Software Provenance Is Not a CI Artifact
Software provenance is often generated in CI, stored beside an image, and treated as proof that the delivery pipeline is secure. This confuses evidence production with a security decision.
Provenance becomes useful only when deployment platforms verify who produced it, what artifact it describes, and whether the recorded build satisfies an explicit policy. The control belongs at the consumption boundary, not only in the pipeline that created the evidence.
What matters
- Immutable identity: Bind verification to artifact digests. Mutable tags weaken the connection between evidence and deployed content.
- Trusted producers: Define accepted builders, identities, and trust roots centrally. The presence of an attestation proves little without an approved issuer.
- Policy semantics: Evaluate relevant claims such as source, build process, and dependencies. Signature validity alone does not establish acceptability.
- Consistent enforcement: Apply the same rules across deployment paths, including automation, emergency procedures, and direct administrative access.
- Operational ownership: Assign responsibility for trust rotation, verifier availability, policy changes, exceptions, and failed deployments.
Recommendation
Treat provenance verification as a platform capability with a stable policy interface. CI systems should produce verifiable evidence; deployment environments should independently decide whether that evidence is sufficient.
This separation reduces implicit trust and keeps security rules consistent as build tools change. Provenance is valuable evidence, but the operating model turns it into a control.