Skip to content

17.7 Signing Artifacts: Sigstore and Transparency Logs

For decades, the software industry understood that cryptographic signatures could prove artifact authenticity and integrity. Yet adoption remained stubbornly low. The barriers were substantial: managing long-lived private keys, obtaining and renewing certificates from certificate authorities, distributing public keys to verifiers, and building the infrastructure to support verification at scale. These challenges meant that signing remained the province of large organizations with dedicated security teams, while the vast majority of open source software shipped unsigned.

Sigstore represents a fundamental rethinking of this problem. Launched in 2021 by Google, Red Hat, and the Linux Foundation, Sigstore provides free, easy-to-use signing infrastructure for open source software. Its core insight is that the friction in traditional code signing stems from key management, and that eliminating long-lived keys through identity-based, ephemeral certificates can make signing as easy as authenticating to a service you already use.

The Sigstore project's goal is to make software signing ubiquitous—to make signing so easy that there's no reason not to do it. By late 2024, Sigstore had achieved remarkable adoption: npm generates Sigstore attestations for all packages published to the public registry, PyPI supports and encourages Sigstore attestations, Kubernetes signs all release artifacts, and Homebrew signs all package bottles. This section examines how Sigstore works, how to use it, and how to deploy it for your organization.

The Sigstore Architecture

Sigstore consists of three primary components that work together to enable keyless signing:

  1. Fulcio: A certificate authority that issues short-lived certificates based on OpenID Connect (OIDC) identity
  2. Rekor: A transparency log that provides an immutable, publicly auditable record of signing events
  3. Cosign: A client tool for signing and verifying container images and other artifacts

The architecture eliminates long-lived keys by binding signatures to identities rather than cryptographic key pairs that users must manage:

┌─────────────────────────────────────────────────────────────────┐
│                     Sigstore Architecture                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   Developer                                                      │
│      │                                                           │
│      │ 1. Authenticate via OIDC                                  │
│      ▼         (GitHub, Google, Microsoft)                       │
│   ┌──────────┐                                                   │
│   │  Fulcio  │ ◄── Certificate Authority                         │
│   └────┬─────┘     Issues short-lived certs (10 min)             │
│        │                                                         │
│        │ 2. Receive ephemeral certificate                        │
│        ▼                                                         │
│   ┌──────────┐                                                   │
│   │  Cosign  │ ◄── Signing Tool                                  │
│   └────┬─────┘     Signs artifact with ephemeral key             │
│        │                                                         │
│        │ 3. Record signature in transparency log                 │
│        ▼                                                         │
│   ┌──────────┐                                                   │
│   │  Rekor   │ ◄── Transparency Log                              │
│   └──────────┘     Immutable, publicly auditable record          │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

This architecture provides several security properties that traditional signing cannot easily achieve:

  • No key management: Developers never generate, store, or rotate long-lived signing keys
  • Identity binding: Signatures are tied to verified identities (email addresses, GitHub accounts)
  • Public auditability: All signing events are recorded in a public log that anyone can inspect
  • Non-repudiation: The transparency log provides cryptographic proof that a signature existed at a specific time

Fulcio: The Certificate Authority

Fulcio serves as Sigstore's certificate authority, issuing short-lived X.509 certificates to authenticated users. Unlike traditional certificate authorities that issue certificates valid for months or years, Fulcio certificates expire in approximately ten minutes—long enough to complete a signing operation, short enough to be useless if compromised.

The certificate issuance flow works as follows:

  1. The user authenticates to an OIDC identity provider (GitHub, Google, Microsoft, or others)
  2. The identity provider returns an OIDC token containing the user's verified identity
  3. The user generates an ephemeral key pair and sends the public key along with the OIDC token to Fulcio
  4. Fulcio verifies the OIDC token and issues a certificate binding the public key to the identity
  5. The user signs their artifact with the ephemeral private key
  6. The private key is discarded immediately after signing

The certificate embeds the signer's identity in the Subject Alternative Name (SAN) extension. For email-based identities, this is the email address; for CI/CD systems like GitHub Actions, it includes the repository, workflow, and other context that precisely identifies what performed the signing:

Certificate:
    Subject Alternative Name:
        URI: https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.0.0
    Issuer: https://token.actions.githubusercontent.com

This binding means that when you verify a signature, you learn not just that "someone with access to a valid private key signed this," but specifically "this GitHub Actions workflow in this repository at this Git reference signed this."

Rekor: The Transparency Log

Rekor implements a transparency log—a cryptographic data structure that provides append-only, tamper-evident storage of signing events. The concept derives from Certificate Transparency (CT), a system developed to detect misissued TLS certificates that has been required for all publicly trusted certificates since 2018.

When a signature is created, the signing event is recorded in Rekor. Each entry includes:

  • The artifact's hash
  • The signature
  • The signing certificate (containing the signer's identity)
  • A timestamp

Rekor uses a Merkle tree structure that makes tampering detectable. Each entry receives a Signed Entry Timestamp (SET) and a position in the log. Anyone can verify that:

  1. An entry exists in the log at a specific position
  2. The log has not been modified since an entry was added
  3. The log maintained by the Sigstore project matches logs maintained by monitors

The transparency log serves multiple purposes:

  • Discoverability: Users can query Rekor to find all signatures for a given artifact or by a given identity
  • Non-repudiation: Even though signing certificates expire quickly, the log entry proves the signature existed when the certificate was valid
  • Monitoring: Organizations can watch for unexpected signing events using their identities
  • Incident response: If a compromise occurs, the log provides a complete record of what was signed

You can query the public Rekor instance directly:

# Search for entries by artifact hash
rekor-cli search --sha "sha256:abc123..."

# Get details of a specific log entry
rekor-cli get --log-index 12345678

# Verify an artifact against its log entry
rekor-cli verify --artifact myfile.tar.gz --signature myfile.tar.gz.sig

Cosign: Signing and Verification

Cosign is the primary client tool for interacting with Sigstore infrastructure. Originally designed for container images, it now supports signing arbitrary files ("blobs"), software bills of materials, and SLSA provenance attestations.

Signing Container Images

Container image signing with Cosign uses keyless mode by default:

# Sign a container image (keyless)
cosign sign myregistry.io/myimage:v1.0.0

# This will:
# 1. Open a browser for OIDC authentication
# 2. Request a certificate from Fulcio
# 3. Sign the image digest
# 4. Store the signature in the registry (as an OCI artifact)
# 5. Record the signing event in Rekor

For CI/CD environments, Cosign detects ambient OIDC credentials automatically:

# GitHub Actions example
- name: Sign container image
  run: |
    cosign sign ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

The signature is stored alongside the image in the container registry as an OCI artifact, making distribution seamless—wherever the image goes, its signature follows.

Signing Blobs and Files

For signing arbitrary files, Cosign provides blob signing:

# Sign a file
cosign sign-blob --output-signature myfile.sig myfile.tar.gz

# This produces:
# - myfile.sig: The signature
# - (optional) myfile.pem: The signing certificate

# For bundle output (signature + certificate + Rekor entry)
cosign sign-blob --bundle myfile.bundle myfile.tar.gz

The bundle format is particularly useful because it contains everything needed for offline verification: the signature, the certificate, and the Rekor inclusion proof.

Verification

Verification requires specifying expected identities to prevent accepting signatures from unexpected sources:

# Verify a container image
cosign verify myregistry.io/myimage:v1.0.0 \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.0.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# Verify a blob
cosign verify-blob \
  --bundle myfile.bundle \
  --certificate-identity-regexp ".*@myorg\.com" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  myfile.tar.gz

The identity and issuer flags are security-critical. Without them, you would accept signatures from any valid Sigstore user, which provides no meaningful security. Always specify the identities you trust.

Ecosystem Adoption

Sigstore has achieved remarkable adoption across major package ecosystems:

npm (Node.js): Starting with a public beta in April 2023 and reaching general availability in September 2023, npm generates Sigstore attestations for packages published to the public registry. The attestations link packages to their source repositories, enabling verification that a package was built from specific source code. Verification is available through npm audit signatures:

npm audit signatures
# audited 1256 packages in 3s
# 1256 packages have verified registry signatures

PyPI (Python): As of November 2024, PyPI supports digital attestations including Sigstore provenance, generated automatically by default for packages using the official PyPA publishing action. Packages published from GitHub Actions, GitLab CI, or other supported CI systems include provenance attestations. The sigstore-python package enables verification:

python -m sigstore verify identity \
  --bundle mypackage-1.0.0.tar.gz.sigstore \
  --cert-identity "https://github.com/myorg/mypackage/.github/workflows/publish.yml@refs/tags/v1.0.0" \
  --cert-oidc-issuer "https://token.actions.githubusercontent.com" \
  mypackage-1.0.0.tar.gz

Homebrew (macOS): Since May 2024, Homebrew provides Sigstore-powered build provenance for bottles built in the official Homebrew CI, achieving SLSA Build Level 2 compliance. This ensures that the binaries you install were built by Homebrew's official infrastructure.

Kubernetes: All Kubernetes release artifacts—container images, binaries, and SBOMs—are signed using Sigstore. The project publishes verification instructions for each release.

Wolfi/Chainguard: The Wolfi Linux distribution and Chainguard Images sign all packages and container images with Sigstore, providing full supply chain transparency.

Sigstore for Enterprises: Private Deployments

While the public Sigstore infrastructure serves most open source needs, enterprises often require private deployments for several reasons:

  • Air-gapped environments: Systems without internet access cannot reach public Sigstore services
  • Compliance requirements: Some regulations require that signing infrastructure be under organizational control
  • Custom identity providers: Organizations may need to use internal OIDC providers not supported by public Fulcio
  • Confidentiality: Some organizations prefer not to publish signing events to public logs

The Sigstore Scaffolding project provides Kubernetes manifests and Helm charts for deploying private Sigstore infrastructure:

# Deploy private Sigstore to Kubernetes
helm repo add sigstore https://sigstore.github.io/helm-charts
helm install sigstore-stack sigstore/scaffold \
  --set fulcio.config.OIDCIssuers[0].issuer="https://your-idp.example.com" \
  --set fulcio.config.OIDCIssuers[0].clientID="sigstore" \
  --set fulcio.config.OIDCIssuers[0].type="email"

Private deployments require careful planning around:

  • Trust root distribution: Clients need the root certificates for your private Fulcio and Rekor
  • OIDC provider integration: Configure Fulcio to trust your organization's identity providers
  • Log monitoring: Implement monitoring for your private Rekor instance
  • Key ceremony: The initial setup of signing keys for Fulcio and Rekor requires security ceremony

For hybrid scenarios, Policy Controller (part of the Sigstore ecosystem) can enforce that artifacts must be signed by either public or private Sigstore infrastructure based on policy.

Integration with SLSA Provenance

Sigstore and SLSA work together seamlessly. While SLSA defines what provenance should contain and what security levels mean, Sigstore provides the mechanism for signing and distributing that provenance.

The typical workflow:

  1. A SLSA-compliant build system generates provenance attestations
  2. The attestations are signed using Sigstore (Cosign)
  3. The signature and provenance are recorded in Rekor
  4. Consumers verify both the signature (Sigstore) and the provenance contents (SLSA)
# Generate and sign SLSA provenance with Cosign
cosign attest --predicate provenance.json --type slsaprovenance \
  myregistry.io/myimage@sha256:abc123...

# Verify SLSA provenance
cosign verify-attestation \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --type slsaprovenance \
  myregistry.io/myimage@sha256:abc123...

Tools like slsa-verifier combine both checks, verifying that an artifact was built by a trusted builder and that the provenance meets SLSA requirements.

Recommendations

We recommend the following approach to adopting Sigstore:

  1. Start signing today: For new projects, enable Sigstore signing in your CI/CD pipelines. The public infrastructure is free and requires no setup.

  2. Specify verification policies: When verifying signatures, always specify expected identities and issuers. Generic verification that accepts any signature provides no security.

  3. Monitor your identities: Use Rekor to watch for unexpected signing events using your organization's identities, which could indicate compromise.

  4. Integrate with existing security tools: Many container security scanners and admission controllers now support Sigstore verification natively.

  5. Plan for private deployment if needed: If compliance or operational requirements necessitate private infrastructure, begin planning early—deployment requires significant coordination.

  6. Combine with SLSA: Sigstore signatures prove who signed; SLSA provenance proves how artifacts were built. Use both for comprehensive supply chain security.

Sigstore has fundamentally changed the economics of artifact signing. What once required significant investment in key management infrastructure is now available for free, integrated into major package ecosystems, and simple enough that there is no longer any excuse for shipping unsigned software. The transparency logs provide unprecedented visibility into the software supply chain, enabling both proactive security monitoring and rapid incident response when compromises occur.