The Challenge
Software artifact signing has long relied on the flawed assumption that teams can securely handle cryptographic keypairs across numerous release pipelines without failures. This traditional model creates three main issues. First, identity binding is unreliable; you might verify that someone signed an artifact, but not who. Second, key custody is chaotic: private keys often end up in repositories, unencrypted CI variables, or shared through Slack. Third, revocation is ineffective at scale; once a key is compromised, there's no reliable way to alert all downstream users that a trusted signature is now a threat.
These risks aren't just theoretical. Typosquatting, compromised distribution sites, and post-publication tampering exploit the gap between "this artifact was signed" and "this artifact is legitimate and unaltered."
Real-World Constraints
The Open Source Security Foundation, supported by the Linux Foundation, designed Sigstore to address real-world software supply chain challenges:
- No secure key storage assumption. Development teams lack HSMs. CI runners are temporary. Developers use laptops that can be lost or stolen.
- No reliable key distribution. Publishing a verification key online is pointless if the site can be compromised. PGP's web-of-trust never reached the necessary adoption for supply chain security.
- Identity verification at signing. Signatures must bind to an OIDC identity, like an email or service account, that can be validated externally.
- Public, tamper-resistant auditability. Every signing event must be recorded in an immutable log for identity monitoring and artifact verification.
Sigstore's Approach
Sigstore eliminates long-lived keypairs. Here's how it works:
A Sigstore client, such as Cosign for container images, creates an ephemeral keypair. It requests a certificate from Fulcio, Sigstore's certificate authority, providing the public key and a verifiable OpenID Connect identity token. Fulcio validates the token, confirming the signer's identity, and issues a short-lived certificate binding that identity to the public key.
The client signs the artifact with the private key and then discards it. The signature, certificate, and artifact digest are recorded in Rekor, an immutable transparency log.
Verification reverses the process without key exchange. The verifier checks the signature against the public key in the certificate, confirms the certificate identity, validates the certificate's signature using Sigstore's root of trust, and verifies inclusion in Rekor. If all checks pass, the artifact is authentic and unaltered.
Rekor addresses revocation differently: it creates a permanent record of the signing event. If an identity is compromised later, you can audit the log to identify legitimate versus fraudulent events based on timestamps and context.
Results and Metrics
Sigstore, supported by the Open Source Security Foundation, Google, Red Hat, Chainguard, GitHub, and Purdue University, operates as a public-good, non-profit service. It's fully open source and free for developers and software providers.
The framework eliminates key management overhead. Teams don't need to secure private keys, rotate keypairs, or maintain key distribution infrastructure. Signing events are recorded in a public log, allowing identity monitoring and artifact verification.
The ephemeral key model ensures Sigstore services never store private keys. Each signing operation generates a fresh keypair, uses it once, and destroys it, removing long-term key compromise risks.
Considerations for Improvement
While Sigstore's documentation doesn't specify changes they would make, the architecture has tradeoffs:
- OIDC dependency introduces a new trust boundary. Trust shifts from key custody to identity providers. Misconfigured CI system OIDC integration negates benefits. Verification policies must specify authorized identities.
- Transparency log growth. Each signing event adds to Rekor, creating query and storage challenges. Efficient log search and monitoring tools are necessary.
- Certificate lifetime constraints. Fulcio issues short-lived certificates. Verification must confirm the certificate was valid at signing time, relying on Rekor's timestamp proof.
Takeaways for Your Team
When considering Sigstore for procurement security workflows, focus on these integration points:
- Map OIDC identities to vendor responsibility. Contracts should specify which service accounts or email domains can sign artifacts. Sigstore binds signatures to identities, but you must define trusted identities for components.
- Audit Rekor for critical vendors. The transparency log is public. Query it for vendor signing events and compare activity against expected schedules. Unexpected events may indicate compromise.
- Integrate verification into intake workflows. Verify signatures during the vendor intake process. Confirm artifacts are signed, the signing identity matches vendor OIDC configuration, and the signature appears in Rekor. This enhances supply chain assurance.
- Test substitutability without key handoff. Traditional signing required key transfers during offboarding. With Sigstore, verify against the transparency log, not vendor-held keys. Ensure you can verify and re-sign artifacts if switching providers, without key custody transfer.
The identity-based model shifts supply chain risk from key management to identity governance. This is progress, but your team must adapt verification policies to maintain security.
