← Back to all briefings
Developer 6 min read Published Updated Credibility 89/100

Security Briefing — Sigstore Launches for Open Source Signing

The Sigstore project launched a free, Linux Foundation–hosted code signing stack—Fulcio, Rekor, and Cosign—to harden open source supply chains with policy-ready attestations, transparency logs, and automated provenance verification.

Zeph Tech Research Lead

Research lead, Zeph Tech

Timeline plotting source publication cadence sized by credibility.
2 publication timestamps supporting this briefing. Source data (JSON)

On 9 March 2021 Google, Red Hat, and the Linux Foundation’s Public Health initiative announced Sigstore, an open-source service that offers free digital signing, certificate issuance, and transparency logging for software artifacts. The project responds to a decade of software supply-chain compromises—SolarWinds, dependency confusion, and typosquatting—by making cryptographic signing accessible to maintainers who historically lacked the tooling, key management maturity, or budget to implement it. Sigstore combines several components: Fulcio, an online certificate authority; Rekor, a tamper-evident transparency log; Cosign, a container and artifact signing client; and policy integrations that let automated build systems verify provenance before deployment.

Sigstore is governed under the Linux Foundation with a dedicated technical steering committee and a public charter emphasizing vendor neutrality. The project quickly attracted maintainers from Chainguard, VMware, Purdue University, and independent security researchers. For governance teams evaluating secure software development frameworks, Sigstore offered a pragmatic path to meet controls outlined by NIST SP 800-204D, Executive Order 14028, and the OpenSSF Scorecards initiative.

How Sigstore works

Traditional code signing relies on long-lived keys that developers must safeguard, rotate, and distribute. Sigstore replaces that model with short-lived X.509 certificates issued by Fulcio using OpenID Connect (OIDC) identities. When a maintainer or CI pipeline authenticates with a trusted identity provider—GitHub, Google, Microsoft, or other OIDC-compliant services—Fulcio issues an ephemeral certificate binding the workload identity to a public key. The private key lives in memory for the duration of the signing operation and is discarded afterward, drastically reducing the risk of key theft.

Each signed artifact—container image, binary, SBOM, or policy bundle—is recorded in Rekor, which uses a Merkle tree–backed append-only log similar to Certificate Transparency. Rekor provides immutable evidence that a particular digest was signed by a given identity at a specific time. Consumers can query the log via API, command line, or scheduled compliance jobs, making it easier to detect tampering or unauthorized rebuilds. Cosign, the reference CLI, integrates these pieces: it authenticates via OIDC, requests a Fulcio certificate, signs the artifact, stores signatures in Rekor, and verifies them during deployment.

Governance and policy integration

Sigstore’s value lies not only in cryptography but in the policy hooks it enables. Kubernetes admission controllers, Tekton Chains, GitHub Actions, and Google Cloud Build can all enforce that artifacts are signed with Sigstore identities before promotion to production. Enterprises can craft policies specifying which identities are allowed to sign, the acceptable certificate issuers, and required attestations such as software bill of materials (SBOM) references. These controls map directly to supply-chain security frameworks like SLSA (Supply-chain Levels for Software Artifacts) levels 2 and 3, which require authenticated provenance and tamper evidence.

Compliance teams can leverage Sigstore logs to satisfy audit requirements. For example, SOX and SOC 2 controls around change management and release authorization can be evidenced by Rekor entries showing that only approved identities signed production releases. Regulators increasingly expect traceability for critical software: the U.S. Office of Management and Budget’s Memorandum M-22-18 mandates that federal agencies obtain attestations that software conforms to secure development practices. Sigstore provides a standardized way to produce and verify such attestations using in-toto metadata and SLSA provenance documents.

Implementation guidance for organizations

Adopting Sigstore involves aligning development, security, and platform engineering teams:

  1. Inventory artifacts. Catalog container images, binaries, Helm charts, and infrastructure-as-code templates that require signing. Map them to build pipelines and deployment targets.
  2. Integrate Cosign into CI/CD. Update pipelines to authenticate using workload identities (e.g., GitHub Actions OIDC tokens), invoke Cosign after build steps, and publish signatures alongside artifacts in registries such as OCI or artifact repositories like Harbor and JFrog Artifactory.
  3. Enforce verification. Configure Kubernetes admission controllers (Kyverno, OPA Gatekeeper), Sigstore policy-controller, or deployment scripts to verify Rekor inclusion proofs before allowing promotion. For air-gapped environments, mirror transparency logs and periodically reconcile.
  4. Manage trust stores. Distribute Fulcio root certificates and Rekor public keys through configuration management so that verification nodes have trusted anchors. Maintain change logs for root rotations and update DevSecOps runbooks.
  5. Monitor and audit. Establish dashboards that track signing coverage, failed verifications, and deviations. Integrate Rekor queries with SIEM platforms to detect anomalies such as unexpected signers or frequent resigning.

Organizations must also plan for incident response. If a developer’s OIDC account is compromised, administrators can revoke trust by removing the identity from allow lists, invalidating tokens, and rotating Fulcio root certificates if necessary. Rekor’s immutable log provides investigators with time-stamped evidence of malicious signatures.

Community roadmap and ecosystem

Following the launch, Sigstore prioritized stability and additional language support. The project introduced keyless signing for automation contexts, developed experimental support for hardware-backed keys via KMS and Trusted Platform Modules, and added interoperability with the CNCF’s Notary v2 efforts. In 2022, Sigstore moved under the Linux Foundation’s new Sigstore Public Benefit LLC to manage infrastructure liability and service-level objectives. The community also partnered with the Open Source Security Foundation (OpenSSF) to integrate Sigstore metrics into the Scorecards project, providing visibility into how widely repositories adopt signing.

Adoption accelerated: Kubernetes required release artifacts to be signed with Cosign, Python’s pip team experimented with Sigstore-backed attestations, and distroless container images published by Chainguard came with verifiable signatures. Cloud providers such as Google Cloud Artifact Registry and AWS Signer announced integrations, enabling enterprise users to verify Sigstore signatures during deployments.

Regulatory and industry alignment

Policy makers increasingly reference software supply-chain security following Executive Order 14028. The U.S. National Institute of Standards and Technology (NIST) updated its Secure Software Development Framework (SSDF) and NIST SP 800-218 to emphasize provenance capture, while the Cybersecurity and Infrastructure Security Agency promoted SBOM practices via the SBOM Awareness and Adoption workstreams. Sigstore’s transparency log model dovetails with these directives by providing objective evidence of build provenance. European regulators considering the EU Cyber Resilience Act likewise highlighted the need for secure update mechanisms and signed binaries, areas where Sigstore can furnish compliance artifacts.

Financial services firms aligning with the Bank of England’s operational resilience and the Basel Committee’s principles recognized that software provenance is essential for critical service mapping. Sigstore’s open governance and public infrastructure allow auditors and regulators to verify signatures without relying on proprietary vendor attestations, increasing trust in third-party software supply.

Long-term considerations

Despite its accessibility, Sigstore adoption requires cultural change. Developers must treat signing as a non-negotiable build step, and organizations must budget for monitoring infrastructure to track Rekor entries at scale. Risk managers should evaluate legal and compliance implications of relying on a shared public CA and transparency log, potentially implementing fallback private deployments for highly regulated workloads while contributing metadata back to the public log where permissible.

As the ecosystem matures, governance teams should stay engaged with the Sigstore community, monitor root key rotations, and update policies to reflect evolving best practices. Participation in working groups—such as those inside the OpenSSF or CNCF—provides early visibility into roadmap changes, vulnerability disclosures, and interoperability milestones.

Sigstore’s launch represented a pivotal step toward democratizing strong provenance for open-source software. Organizations that integrate its tooling into their DevSecOps pipelines can measurably reduce the risk of tampered dependencies, satisfy emerging regulatory attestations, and build confidence with customers who increasingly demand verifiable software supply chains.

Timeline plotting source publication cadence sized by credibility.
2 publication timestamps supporting this briefing. Source data (JSON)
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Sigstore
  • Software supply chain
  • Code signing
  • Transparency log
Back to curated briefings