With Sigstore keyless signing there is no long lived key to steal, so verification rests on identity. A verifier must check that the signature is valid, that the certificate names the signer you expect, that the certificate chains to Sigstore's root, and that the signing event appears in the transparency log.
The three pieces
The Sigstore overview describes three main components.
- Cosign is the client. It generates a key pair for each signing, requests a certificate, signs the artifact and records the result.
- Fulcio is the certificate authority. It checks an identity token and issues a short lived certificate bound to that identity and the public key.
- Rekor is the transparency log, an append only ledger that records the artifact digest, signature and certificate so signing events can be audited.
Signatures use ephemeral keys, so there is no key to manage. The private key is discarded after one signing and Sigstore services never receive it.
What the certificate binds
The certificate ties an identity to a public key. The identity comes from an identity token. For a person it contains an email address or service account. For CI it carries workflow information.
That is the key point for consumers. The signature proves who signed, not that the artifact is good.
The four verification checks
According to the overview, a verifying client:
- checks the signature using the public key in the certificate,
- confirms the certificate's identity matches the expected identity,
- validates the certificate against Sigstore's root of trust, and
- checks proof of inclusion in Rekor.
If you run only the first step, any valid Sigstore signature from anyone passes. Step two is the one people forget.
Writing the identity policy
Decide in advance who may sign each kind of artifact.
- Name the signer. For CI signing, that means the specific repository and workflow, not just the CI platform in general.
- Name the issuer. The identity provider that issued the token is part of the identity. Require the one you expect.
- Fail closed. If verification cannot run, do not deploy.
- Keep the policy in version control and review changes like code.
- Test the negative case. Try verifying an artifact signed by an unexpected identity and confirm it fails.
Limits
- A correct signature from your own workflow says your pipeline produced it. If an attacker controls that pipeline or can change the workflow, the signature is valid and the artifact is bad.
- Transparency logs help detect misuse after the fact, but only if someone watches them.
- Signing does not replace dependency scanning or review.
Where this fits
Pair signature checks with provenance verification and an SBOM, and put the checks at the point of deployment, where they can block. Safeguard offers policies and gates for this kind of enforcement, along with SBOM and dependency scanning.
Quick check
If a keyless signature verifies, can I trust the artifact?
Only if the certificate identity is the one you expect. A valid signature from an unexpected identity should be rejected.
Why is there no key to protect?
Keys are ephemeral. The private key is discarded after one signing, and Sigstore services never receive it.
Sources
Last reviewed: 19 October 2026.
