Sigstore and the Transparency Log Revolution

Sigstore is a collection of open-source tools , Cosign for signing, Fulcio for certificate authority, Rekor for transparency log , that collectively provide software supply chain security infrastructure that was previously only accessible to large organisations with dedicated PKI teams. Sigstore's fundamental innovation is keyless signing: instead of requiring developers to manage long-lived private signing keys (which can be stolen, lost, or forgotten), Sigstore uses short-lived certificates issued just-in-time for each signing operation, tied to the signer's OIDC identity (GitHub Actions, GitLab CI, or Google Cloud identity). When the signing is complete, the certificate expires , there is no persistent private key to protect.

The transparency log (Rekor) is the second major Sigstore innovation. Every signing event , every certificate issuance and every artifact signature , is logged to Rekor, an immutable append-only transparency log. This creates a public, auditable record of all Sigstore signing events. A consumer verifying a software artifact can query Rekor to confirm that the signature was produced at a specific time by a specific CI/CD identity , not just that the signature is cryptographically valid, but that it was produced by the expected build system at the expected time. A supply chain attack that uses a compromised key to sign a malicious artifact before Sigstore adoption cannot produce a valid Sigstore certificate (because there is no legitimate OIDC identity for the attacker's signing operation), making the attack detectable.

The adoption landscape is rapidly expanding. The npm, PyPI, and Maven Central ecosystems have announced or implemented Sigstore-based signing for their package ecosystems. The Linux Foundation, CNCF, and Kubernetes project have adopted Sigstore. GitHub has built Sigstore integration into GitHub Actions. The practical implication for TPRM practitioners is that asking whether a vendor uses Sigstore (or equivalent) is increasingly a question with a binary answer that correlates with software supply chain security maturity.

Why this matters

Sigstore matters for TPRM because it provides a free, accessible standard for software supply chain signing and transparency that removes the technical barrier to adoption for smaller vendors. A vendor that has not adopted Sigstore or an equivalent in an era when the npm ecosystem is adopting it by default is a vendor whose software supply chain security investment is behind the current standard of practice , not necessarily compromised, but behind.

• Sigstore awareness absent in vendor software supply chain security assessment
• Legacy private key signing , long-lived keys without Sigstore short-lived certificates
• No transparency log , signing events not in public immutable audit log
• Key management overhead preventing small vendor adoption of signing
• Sigstore adoption as supply chain security maturity signal

What good looks like

Mature supply chain signing programmes adopt Sigstore for new software releases , specifically cosign for signing and Rekor for transparency log verification , and include Sigstore adoption status as a vendor supply chain security assessment question.

• Sigstore cosign for software signing , replacing legacy private key signing
• Rekor transparency log logging , immutable public audit record
• Keyless signing via OIDC CI/CD identity , no persistent private key
• Consumer verification via cosign verify against Rekor
• Sigstore adoption status in vendor supply chain assessment

Tooling

Sigstore , cosign for signing/verification, Fulcio for certificate authority, Rekor for transparency log (sigstore.dev)

Sigstore's tools are freely available and integrate with all major CI/CD platforms. The cosign GitHub Action signs artifacts and logs to Rekor in a single step with no key management required. For TPRM practitioners, verifying that a vendor's releases are in Rekor's public log provides independent confirmation of Sigstore adoption without requiring vendor attestation.

Governance challenges

The governance challenge with Sigstore is the adoption transition , vendors with existing signing infrastructure need to migrate to Sigstore without disrupting customers who have built verification into their deployment workflows. The governance resolution is parallel adoption: Sigstore signing alongside existing signatures during a transition period, with a defined migration timeline for customers.

• Check Rekor for vendor releases , verify adoption independently
• Ask about Sigstore adoption roadmap for vendors with legacy signing
• Include Sigstore adoption in software supply chain security assessment
• Reference Sigstore in vendor supply chain security requirements
• Monitor npm/PyPI ecosystem adoption for Sigstore-based package verification

If you are a small team

For your three most critical software vendors, check Sigstore's Rekor transparency log (rekor.sigstore.dev) for entries associated with their releases. If their releases are in Rekor, Sigstore has been adopted. If not, ask the vendor about their current signing approach and whether they have a Sigstore adoption plan. The Rekor check takes minutes and provides an independent verification of Sigstore adoption that questionnaire confirmation cannot provide.

• Check Rekor transparency log for vendor release entries
• Ask about signing approach for vendors not in Rekor
• Include Sigstore adoption status in vendor supply chain assessment
• Reference Sigstore in vendor contract signing requirements

What to require

Ask directly:

"Do you sign your software releases using Sigstore cosign with logging to the Rekor transparency log , and if not, what is your current signing approach and what is your timeline for adopting keyless Sigstore signing?"

Expect as evidence

• Sigstore cosign adoption confirmation or roadmap
• Rekor log entry verification for recent releases
• Current signing approach and key management if not Sigstore
• Migration timeline to keyless signing

A vendor who confirms code signing should be asked whether that signing includes Sigstore transparency logging. Signature confirms the key signed the artifact. Rekor logging confirms the signing event in an immutable public audit record. The combination provides the supply chain signing assurance that private key signing alone cannot achieve.

How to evidence it

• Rekor verification for critical vendor releases
• Sigstore adoption assessment
• Signing approach assessment for non-Sigstore vendors
• Sigstore adoption roadmap tracking

Key Takeaway

Signing key: file on build server, three years unrotated. Sigstore: free, short-lived certificates from OIDC CI identity, public immutable transparency log, no persistent key to protect or lose. The vendor had been managing a three-year-old private key file because they had not known there was a better approach available at zero cost. Sigstore makes short-lived certificate signing and public transparency logging accessible to every developer. The transparency log revolution means that signing event verification , independent confirmation that an artifact was signed by the expected CI identity at the expected time , is now a public good rather than a PKI infrastructure investment.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security