
The key insight: Sigstore solves code signing's fundamental problem—not the cryptography, but the operational nightmare of managing private keys securely at scale.
Traditional code signing puts developers in an impossible position. You need to generate long-lived private keys, store them securely, rotate them regularly, and somehow distribute them to CI/CD systems without leaking them. One compromised key can invalidate your entire supply chain security model. It's no wonder most open-source projects skip signing altogether.
Sigstore flips this model completely. Instead of "sign with a key you own," it's "sign with an identity you already have." The magic happens through three interconnected components that eliminate private key storage entirely.
The Keyless Signing Dance
When you run cosign sign, here's what actually happens behind the scenes:
1. Ephemeral keypair generation: Cosign generates a public/private key pair in memory—never touching disk
2. OIDC authentication: Your browser opens to authenticate with GitHub, GitLab, or another OIDC provider
3. Certificate binding: Fulcio (Sigstore's Certificate Authority) verifies your OIDC token and issues a short-lived certificate that cryptographically binds your identity to the public key
4. Artifact signing: Your artifact gets signed with the ephemeral private key
5. Transparency logging: The signature, certificate, and artifact hash get recorded in Rekor's immutable transparency log
6. Key destruction: The private key and certificate are immediately discarded
1# This simple command triggers the entire keyless flow
2cosign sign --yes docker.io/username/image@sha256:digest
3# Browser opens for GitHub auth, then signing completes automaticallyThe brilliance is in step 6—there's literally no private key to compromise afterward. The signature exists, but the signing capability is gone forever.
Why Transparency Logs Change Everything
Rekor isn't just a fancy database—it's what makes keyless verification possible. Since the private key gets destroyed immediately after signing, how do you verify signatures later? The transparency log provides cryptographic proof that:
- The signature was created by someone who controlled your identity at a specific time
- The signing event is publicly auditable
- Any tampering with the log would be immediately detectable
<> "Transparency logs enable supply chain audits and detect tampering retroactively, even after the signing keys are destroyed."/>
This shifts security from "protect the key" to "trust the log," which is far more scalable for distributed development teams.
Practical Implementation in CI/CD
The real power emerges in automated environments. Here's how GitLab CI can sign container images without any secret management:
1build-and-sign:
2 image: gcr.io/projectsigstore/cosign:latest
3 id_tokens:
4 SIGSTORE_ID_TOKEN:
5 aud: sigstore
6 script:
7 # Build your image first
8 - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
9 - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
10 # Sign using GitLab's built-in identity token
11 - cosign sign --yes --key env://SIGSTORE_ID_TOKEN $CI_REGISTRY_IMAGE@$(docker inspect --format='{{index .RepoDigests 0}}' $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA | cut -d@ -f2)No secrets to rotate, no keys to leak, no complicated key distribution. The CI system's identity becomes the signing credential.
For npm packages, it's even simpler:
1publish:
2 image: node:latest
3 id_tokens:
4 SIGSTORE_ID_TOKEN:
5 aud: sigstore
6 script:
7 - npm publish --provenance=on --access publicThe --provenance=on flag automatically generates Sigstore attestations that link your package to the specific CI job and repository that built it.
The Trust Model Shift
Traditional code signing asks: "Do you trust this specific private key?"
Sigstore asks: "Do you trust this identity provider and this transparency log?"
For most developers, the second question has a much clearer answer. You already trust GitHub or GitLab with your source code. You already rely on Certificate Transparency logs for HTTPS. Sigstore extends these existing trust relationships to code signing.
This shift dramatically reduces the attack surface:
- No long-lived secrets to exfiltrate
- No key rotation procedures to compromise
- No central key storage to breach
- Transparent, auditable signing events
Verification in Practice
Signing without verification is security theater. The keyless model makes verification straightforward:
1# Verify a container image signed by a specific GitHub identity
2cosign verify \
3 --certificate-identity=user@example.com \
4 --certificate-oidc-issuer=https://github.com/login/oauth \
5 docker.io/username/image@sha256:digestConsumers can verify not just that something was signed, but specifically who signed it and when, without requiring access to any private keys.
Why This Matters
Sigstore's keyless approach removes the biggest barrier to widespread code signing adoption: operational complexity. By leveraging identities developers already manage and eliminating private key storage entirely, it makes supply chain security accessible to individual developers and large organizations alike.
The transparency logs provide a permanent, auditable record of what was signed when and by whom—critical for forensics when supply chain attacks do occur.
Next steps: Try signing a local Docker image with cosign sign to see the keyless flow in action. Then explore integrating Sigstore signing into your CI/CD pipeline using your platform's identity tokens. Start with non-critical artifacts to build familiarity before applying to production deployments.
The future of supply chain security isn't about better key management—it's about eliminating key management entirely.

