Safeguard
Software Supply Chain•

Sigstore vs GPG signing: which fits your releases?

GPG signs with a long lived key you manage. Sigstore signs with short lived certificates tied to an identity and logs the event. Pick by who verifies.

Safeguard Security Team
4 min read

GPG signs releases with a key pair you create and protect, and users verify with your public key. Sigstore signs with an ephemeral key tied to an identity and records the event in a public log. Choose by who verifies, how you handle keys, and whether you can rely on online services.

How does GPG signing work?

GnuPG describes itself as a command line tool and universal crypto engine that is often used as the backend of other applications. It has become a de facto free software standard for private communication and digital signatures. You generate a key pair, keep the private key secret and publish the public key. A consumer who trusts your public key can verify that an artifact was signed by the holder of the private key and has not been altered.

What problems does Sigstore point to?

The Sigstore documentation lists three weaknesses in traditional key based signing. Identity: how do you know the signer is who they say? Key management: how do you protect the private key and distribute the public key safely? Key revocation: if a key is compromised, how do you convince users you are legitimate and not an attacker?

How does Sigstore work?

The project describes keyless signing as associating identities, not keys, with an artifact signature. Fulcio issues short-lived certificates that bind an ephemeral key to an OpenID Connect identity. Cosign is the client that signs. Rekor, a transparency log, records the signing event so there is an auditable record of when a signature was created. The root of trust is distributed through The Update Framework. Sigstore supports sign in with Microsoft, Google and GitHub identities, and Cosign can detect certain automated environments and produce a token.

In practice that means a CI job can sign a container image using its workload identity, with no private key stored anywhere, and a verifier checks that the certificate identity matches the expected workflow.

Where do they differ?

Key custody. GPG: you own and protect a long lived key. Sigstore: no long lived signing key, so there is nothing to leak from a laptop or a CI secret store.

Identity. GPG: identity is whatever your trust model says about the key. Sigstore: identity is an OIDC identity in a certificate, such as a specific CI workflow.

Transparency. GPG: signing leaves no public record by default. Sigstore: signing is logged.

Dependency on services. GPG verification can work offline with a trusted key. Sigstore relies on its trust root and, in the default setup, on the public log, so plan for offline or private deployments if you need them.

Ecosystem. Some package ecosystems and Linux distributions still expect GPG signatures. Check what your consumers verify.

A constructed decision

Constructed example: a team publishes a CLI as Linux packages and a container image. The package repository expects a GPG signature, so they keep a GPG key in a hardware token, with a documented rotation and revocation plan. The container image they sign with Sigstore from CI, and the deploy cluster verifies that the identity is their release workflow on the main branch. The two methods coexist because the consumers differ.

What do you need either way?

A signature only proves who signed and that the content has not changed. It does not prove the code is safe. Pair signing with provenance, an SBOM and vulnerability scanning. Safeguard offers SBOM generation and dependency scanning that complement signing, which answers where an artifact came from rather than what it contains.

What to do

  1. List who verifies your releases and what they can verify.
  2. For GPG, store keys on hardware, set an expiry, and write the revocation plan.
  3. For Sigstore, define the identity a valid signature must carry and enforce it at deploy.
  4. Decide how you will handle verification with no internet access.
  5. Publish verification instructions beside every release.
  6. Add an SBOM and scan results to the release.

Quick check

Is Sigstore a replacement for GPG in every case?

No. Some ecosystems still expect GPG. Use what your consumers can verify, and use both where needed.

What does a signature not prove?

It does not prove the software is free of vulnerabilities. It shows who signed and that the artifact is unchanged.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.