阅读中文版本

Release Artifact Signing Workflow

Sign every release artifact in CI and record provenance so the deployed bytes can be traced to a specific commit and pipeline.

Overview

Attach verifiable signatures and provenance to all release artifacts.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• OIDC-capable CI
• A signing tool such as cosign
• A provenance format such as SLSA

Procedure

1. Build the artifact deterministically

Build from a pinned commit with locked dependencies so the output is reproducible.

Expected state: The artifact digest is stable for the same inputs.

2. Sign and attach provenance

Sign the artifact keylessly and attach a provenance attestation describing the build.

Expected state: A signature and attestation accompany the artifact.

3. Store and mirror the evidence

Push signatures and attestations to a registry or evidence store alongside the artifact.

Expected state: Evidence is retrievable and versioned with the artifact.

4. Verify at deploy time

Gate the deployment on signature and provenance verification.

Expected state: Only artifacts signed by the expected workflow can deploy.

cosign sign --yes ghcr.io/org/app@${DIGEST}
cosign attest --yes --predicate provenance.json --type slsaprovenance ghcr.io/org/app@${DIGEST}

Verification

Confirm signature verification succeeds, provenance matches the commit, and deployment rejects unsigned artifacts.

Decision points

Keyless or key-based signing?

• Keyless with OIDC
• Long-lived private key

Recommendation: Prefer keyless to avoid key management and rotation risk.

Block deploys without provenance?

• Enforce
• Warn only

Recommendation: Enforce for production; warn in lower environments during adoption.

Common failures

• Signing by tag instead of digest misses replacements.
• Provenance that omits the commit is not verifiable.
• Unsigned artifacts slip through if verification is warn-only.