Artifact Signing
Cryptographically signing build outputs so that deployment can verify what is being run was produced by the expected pipeline from the expected source.
The gap it closes: a container image, package or binary arriving at deployment carries no inherent evidence of where it came from. An attacker who can write to the registry, or compromise a build agent, can substitute a malicious artefact that deploys normally.
Signing binds the artefact to its producer. Verification at deployment — as an admission policy rather than a pipeline step — refuses anything unsigned or signed by an unexpected identity. The distinction matters: a pipeline check can be bypassed by deploying another way; an admission control cannot.
The modern practice extends beyond a signature to provenance attestation: a signed statement of which source commit, which builder and which parameters produced the artefact, following the SLSA framework. That answers "was this built from our main branch by our pipeline" rather than only "was this signed by someone we trust".
Sigstore has removed the historical obstacle, which was key management. Keyless signing uses short-lived certificates tied to an OIDC identity — a GitHub Actions workflow, for example — with a public transparency log, so there is no signing key to store, rotate or leak.
The reasonable adoption order: sign artefacts, verify at admission, then add provenance attestation and policy on what provenance is acceptable.