Sigstore Keyless Signing

Best Practice: Sigstore Keyless Signing

Sigstore is an open standard and toolset for signing software artifacts, such as container images and packages, so consumers can verify they are authentic and untampered. Its signature feature is "keyless" signing: instead of managing long-lived private keys, a signer authenticates with an existing identity (for example an OIDC token from a CI system or identity provider) and receives a short-lived certificate from Sigstore's Fulcio certificate authority. The signing event is recorded in a public transparency log called Rekor. It matters because lost or stolen signing keys are a major supply chain risk, and short-lived identity-based certificates remove that burden. For a developer it removes the chore and danger of managing signing keys; for a leader it provides a public, auditable record that artifacts came from the expected build. Sigstore underpins signing in many ecosystems, including container registries and language package managers, so adoption often requires little custom work. The verification side is what delivers the value: signing is pointless unless something checks the signature and the expected identity before trusting an artifact. Mature teams enforce this at admission, so an image that lacks a valid signature from the expected build identity is simply refused entry to the cluster.

Step-by-Step Implementation Guidance

1. Identify the artifacts you publish that consumers should be able to verify.
2. Add a signing step to your CI pipeline using Cosign.
3. Use the workflow's OIDC identity to obtain a short-lived certificate from Fulcio.
4. Sign each artifact and confirm the entry is recorded in Rekor.
5. Publish signatures and provenance alongside the artifacts.
6. Add verification to consumers and deployment gates, checking the expected identity.
7. Document the trusted identities so verifiers know what to expect.

Common Mistakes Teams Make When Ignoring This Practice

• Relying on long-lived signing keys that can be leaked or stolen.
• Signing artifacts but never verifying them at deployment.
• Verifying a signature exists without checking the expected signer identity.
• Storing signing keys in CI secrets where they are widely accessible.
• Skipping the transparency log, losing the public audit trail.
• Treating signing as optional metadata rather than a deploy-time gate that blocks unverified artifacts.

Tools and Techniques That Support This Practice

• Cosign for signing and verifying container images and artifacts.
• Fulcio for short-lived certificate issuance tied to identity.
• Rekor as the public transparency log of signing events.
• OIDC identities from CI systems (for example GitHub Actions) as the signer.
• Policy controllers that enforce signature verification at admission.
• npm, PyPI, and registry integrations that surface Sigstore provenance to package consumers.

How This Practice Applies to Different Migration Types

• Cloud Migration: Enforce signature verification at the new cluster or registry admission point.
• Database Migration: Sign and verify migration scripts and tooling artifacts to confirm integrity.
• SaaS Migration: Prefer vendors who publish Sigstore signatures for their distributed components.
• Codebase Migration: Add keyless signing to the new build pipeline so every release is verifiable.

Checklist

• Identified artifacts that need verifiable signatures
• Added Cosign signing to the CI pipeline
• Used OIDC identity for keyless certificates
• Confirmed entries appear in the Rekor transparency log
• Published signatures alongside artifacts
• Enforced verification of the expected identity at deploy
• Documented trusted signer identities