Cosign keyless signing: verifying artifacts without a keypair
You download a release binary, and the project tells you to verify its signature. Good advice — except the entire system depends on a private key that someone, somewhere, has to store. If that key leaks, an attacker can sign anything, and every release you ever verified becomes worthless retroactively. Key management is the weak link in release signing, and keyless signing exists to remove it.
Cosign’s keyless mode, part of the Sigstore project, verifies artifacts without asking anyone to safeguard a long-lived signing keypair. Here is how it works and what it gives you.
The problem with keypairs
A traditional signing setup requires a private key that is kept secret for years. That key lives somewhere — a CI secret store, a hardware token, a vault — and every storage option is an attack surface. Keys get exfiltrated, backed up to the wrong place, or reused across projects. The moment a signing key is compromised, the damage is silent: signed malware passes every check your users were told to run.
The deeper issue is that a keypair has no identity: a signature proves “someone holding the private key signed this,” but not who, or when they were authorized.
How keyless signing works
Keyless signing replaces the long-lived keypair with a short-lived key bound to an identity. The flow, per signing event:
- Ephemeral keypair. A fresh keypair is generated for this signing operation only. The private key exists for minutes and is discarded.
- Identity proof. The signer authenticates to an OIDC provider (email account, CI identity, GitHub workflow), proving who they are.
- Certificate issuance. Fulcio, a public certificate authority, issues a short-lived code-signing certificate binding the ephemeral public key to that OIDC identity.
- Transparency log. The signature and certificate are written to Rekor, an append-only log that anyone can audit.
The artifact is signed with a key that expires in minutes and is cryptographically tied to a real identity, with the whole event recorded publicly.
What verification actually checks
Verifying a keyless signature means checking the certificate chain back to Fulcio’s root, confirming that the certificate’s identity matches who you expected (an email address, a repository, a CI workflow), and confirming the signature appears in Rekor. Three properties fall out:
- Provenance, not just possession. The signer is identified by name, not by a faceless key.
- Compromise is useless. A stolen ephemeral key is already expired and logged.
- Tamper evidence. Rekor is append-only; retroactively rewriting the record would be visible to anyone auditing the log.
The trust tradeoffs
Keyless signing does not eliminate trust — it relocates it. Instead of trusting a project to protect a private key, you trust public infrastructure (Fulcio, Rekor, and the OIDC providers) and the transparency the log provides. That trade is usually the right one: public infrastructure is audited by many parties, and ephemeral keys have no long-term value.
It also does not fix everything. Keyless signing proves who signed an artifact and when; it says nothing about whether the code is secure. A compromised OIDC account or stolen CI credential can still produce valid signatures, which is why pinning verification to a specific identity — not just “anyone from this provider” — matters.
In practice
For projects shipping Go binaries, keyless signing fits naturally with a single-artifact release model: one file to sign, one signature to verify, one SBOM to attach. That is the setup used by trustless, a credential broker CLI for AI agents whose releases are cosign keyless-signed and shipped with an SBOM, so the download you verify is tied to a real identity rather than an anonymous key.
Next time you verify a release, ask what the signature actually proves: possession of a secret, or an identity you can hold accountable? Which would you rather trust with your supply chain?