Sigstore Documentation

The certificate issuing workflow begins when a client submits a certificate request to Fulcio. The request must contain an OIDC identity token and a challenge to prove ownership of the requested identity. This input is the foundation for all subsequent authentication and verification steps in the certificate issuing process.

Gitsign stores data in two places: (1) Within the Git commit itself, containing a signed digest of user commit content (author, committer, message) along with the code signing certificate, stored as part of the repository. (2) Within the Rekor transparency log as a HashedRekord containing a SHA256 hash of the commit SHA and the code signing certificate, enabling verification for ephemeral certs past their 'Not After' time. By default, data is written to the public Rekor instance. Users sensitive to data in code signing certificates (which may include emails or repository identifiers) can deploy their own Rekor server.

Gitsign signs Git commits using Sigstore's keyless authentication with OpenID Connect. Instead of managing GPG keys, you authenticate via a browser with providers like GitHub or Google, and signing details are recorded in the Rekor transparency log for verification. This eliminates the need for GPG key management while providing cryptographically verifiable commit signatures.

Fulcio issues code signing certificates through a 7-step workflow: (1) Certificate request input containing OIDC identity token and challenge, (2) Authentication of the OIDC token, (3) Verification of the challenge, (4) Certificate construction with identity details, (5) Certificate signing, (6) Certificate Transparency log inclusion, and (7) Return of the signed certificate to the client.

The Policy Controller is an admission controller for Kubernetes that enforces policy on containers allowed to run, ensuring only signed and verified images are deployed.

Sigstore's signing workflow: (1) A Sigstore client like Cosign generates a temporary key pair and sends a certificate signing request to Fulcio (Sigstore's certificate authority) along with an OIDC identity token (email, service account, or CI workflow info). (2) Fulcio verifies the OIDC token and issues a short-lived certificate bound to the identity and public key. The private key is discarded after signing. (3) The client signs the artifact, and the digest, signature, and certificate are recorded in Rekor, Sigstore's immutable transparency log. (4) Verification checks the signature using the certificate's public key, validates the identity matches expectations, verifies the certificate against Sigstore's root of trust, and confirms proof of inclusion in Rekor.

Sigstore provides two GitHub Actions for integrating signing and verification into CI systems: gh-action-sigstore-python for Python-based workflows, and Cosign for container images and blobs. Both enable automated signing without requiring long-lived signing keys.

The sigstore/community repository contains the most current information about getting involved with Sigstore, including the code of conduct and contributing guidelines. Review these documents before engaging with the project.

Sigstore is an open-source project backed by the OpenSSF under the Linux Foundation, with contributions from Google, Red Hat, Chainguard, GitHub, and Purdue University. It provides cryptographic signing tools to improve software supply chain security. Key features: ephemeral signing keys eliminate key management overhead; signing events are recorded in a tamper-resistant transparency log for auditability; 100% free and open source. Sigstore supports signing and verification of release files, container images, binaries, SBOMs, and other software artifacts.

Sharding splits Sigstore's Rekor transparency log (built on a single Merkle Tree) into multiple discrete Merkle Trees. This resolves issues that arise from indefinite log growth. Sharding enables freezing the current log and rotating signing keys, faster entry queries, and easier scaling and platform migrations. End users experience no change—they can still query by UUID (Rekor finds the correct shard) or by log index (indices remain distinct and increase across shards).