Sigstore and Software Signing: A Security Deep-Dive

📅 October 5, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A compromised software build pipeline delivered malware to 18,000 organizations in the SolarWinds attack—and the signed updates looked completely legitimate. That single incident exposed a foundational weakness in how the industry had approached software trust: signing certificates can be stolen, build systems can be subverted, and the chain of trust between a developer’s workstation and an end user’s production environment has historically been held together with assumptions rather than cryptographic proof. Sigstore was built specifically to close that gap.

The Software Supply Chain Trust Problem

Before understanding what Sigstore solves, it’s worth being precise about what it’s solving against. The software supply chain encompasses everything from the moment a developer commits code to the moment that code executes in a production environment. At every node in that chain—version control, CI/CD pipelines, artifact registries, package managers—there exists an opportunity for tampering, impersonation, or silent substitution.

According to the Sonatype 2025 State of the Software Supply Chain report, supply chain attacks increased by 742% over a three-year period. The attack surface is enormous: a single open-source package may be consumed by tens of thousands of downstream projects, meaning a single compromised maintainer account or dependency update can propagate malicious code at industrial scale.

Why Traditional Code Signing Falls Short

Traditional code signing relies on long-lived private keys stored by developers or organizations. The signing key becomes, functionally, the entire security perimeter. If that key is stolen—via a compromised developer laptop, a poorly secured CI/CD secret store, or a social engineering attack—every artifact signed with it is retroactively suspect. There is no native mechanism for transparency, no publicly auditable log of what was signed and when, and no way for downstream consumers to verify that a signature was produced in the expected environment rather than by an attacker who obtained the key offline.

Furthermore, key management at scale is operationally burdensome. Organizations managing hundreds of repositories often struggle to rotate keys consistently, revoke compromised credentials promptly, or even maintain accurate inventories of which keys are authorized to sign which artifacts. The result is a landscape where signing exists as a checkbox rather than a meaningful security control.

What Sigstore Is and How It Works

Sigstore is an open-source project, incubated under the Linux Foundation and the OpenSSF (Open Source Security Foundation), that provides a free, transparent, and non-repudiable framework for signing software artifacts. It was designed with a specific philosophy: eliminate long-lived signing keys entirely, anchor identity to existing OpenID Connect (OIDC) credentials, and make every signing event publicly auditable via an append-only transparency log.

The project’s core components work in concert: Cosign for signing and verifying container images and other artifacts, Fulcio as a root certificate authority that issues short-lived signing certificates, and Rekor as the immutable transparency log that records all signing events. Understanding how these three interact is essential to grasping Sigstore’s security model.

The Keyless Signing Workflow

When a developer or CI system initiates a signing event using Cosign in keyless mode, the following sequence occurs. First, the signer authenticates against an OIDC provider—GitHub Actions, Google Accounts, Microsoft Azure AD, or another supported identity provider. This produces a short-lived OIDC token that cryptographically proves the signer’s identity. Second, this token is presented to Fulcio, which validates the identity claim and issues an ephemeral X.509 certificate bound to that identity, valid for only 10 minutes. Third, the artifact is signed using the private key corresponding to that short-lived certificate. Fourth, both the signature and a signed certificate transparency entry are submitted to Rekor, which records them immutably. Finally, the ephemeral private key can be discarded—it has already served its purpose, and the trust anchor has shifted to the transparency log entry.

The result is a verifiable artifact where any downstream consumer can confirm: who signed it, what identity provider vouched for them, which build system produced the artifact, and at what timestamp. There is no long-lived private key to steal, and any attempt to produce a fraudulent signature would require either compromising the OIDC provider or subverting the transparency log—both significantly higher bars than stealing a static signing key from a secrets manager.

Rekor: The Transparency Log Architecture

Rekor deserves deeper examination because it is both Sigstore’s most novel contribution and the component most directly responsible for enabling post-hoc audit and detection capabilities. Modeled on Certificate Transparency—the mechanism that made fraudulent TLS certificates auditable at internet scale—Rekor implements a Merkle tree-based append-only log where each entry is cryptographically chained to all previous entries.

By October 2026, the public Rekor instance maintained by Sigstore’s infrastructure has logged well over two billion signing events, encompassing container images, Python packages, npm modules, and binary releases from major open-source projects including Kubernetes, Tekton, and the broader CNCF ecosystem. This scale matters: a transparency log only has value when it is widely adopted, because widespread adoption makes silent omission detectable.

Inclusion Proofs and Consistency Proofs

Two cryptographic mechanisms give Rekor its forensic power. An inclusion proof allows any verifier to confirm that a specific entry exists in the log without downloading the entire log—the verifier receives a set of Merkle tree hashes sufficient to reconstruct the path from the entry to the signed tree root. A consistency proof allows a verifier who trusts a previous log state to confirm that a newer log state is a valid extension of it, catching any attempt to retroactively modify or delete entries.

For enterprise security teams, this architecture enables a compelling detection use case: monitoring. If a signing event appears in your artifact registry but has no corresponding Rekor entry, that is an immediate anomaly signal. Conversely, if a Rekor entry exists for an artifact your organization never intentionally produced, it may indicate a compromised build identity. This transforms the transparency log from a passive audit record into an active component of a threat detection posture.

Enterprise Adoption and Real-World Implementation

Sigstore has moved well beyond experimental adoption. GitHub’s artifact attestation feature, launched in 2024 and now widely used across GitHub Actions workflows, is built on Sigstore infrastructure. npm packages published via GitHub Actions can carry Sigstore-backed provenance attestations that the npm registry natively verifies. The Python Packaging Authority completed Sigstore integration for PyPI, enabling package maintainers to publish verifiable provenance alongside releases without managing signing keys at all.

For enterprises running internal software supply chains, the deployment model typically involves a private Sigstore deployment rather than reliance on the public infrastructure. Projects like Sigstore’s Helm charts and the Sigstore policy controller for Kubernetes make it possible to run Fulcio and Rekor within a private cloud environment, federated against an enterprise identity provider such as Okta or Azure Active Directory. This gives organizations control over the trust root while preserving the keyless signing model and the auditability benefits of the transparency log.

Policy Enforcement with the Sigstore Policy Controller

One of the most operationally significant capabilities for enterprise security engineers is the Sigstore Policy Controller for Kubernetes. This admission webhook intercepts every container image deployment request and evaluates it against a configurable policy set. A policy might require that all images deployed to a production namespace carry a valid Cosign signature from a specific GitHub Actions workflow identity—not merely from any member of an organization, but from the specific CI pipeline authorized to build production artifacts.

Consider a practical scenario: an attacker gains write access to a container registry and pushes a backdoored image with a plausible tag. Without signature verification at admission time, that image can be deployed. With the Sigstore Policy Controller enforcing that all production images must carry a signature whose certificate’s subject identity matches https://github.com/your-org/your-repo/.github/workflows/release.yml@refs/heads/main, the backdoored image—lacking that specific provenance—is rejected before a single pod launches.

This represents a fundamental shift in how identity is expressed in software supply chains: from “who owns the signing key” to “which specific automated workflow, running in which repository, on which branch, under which conditions produced this artifact.”

Integration with SBOM and SLSA Frameworks

Sigstore does not operate in isolation. Its practical security value is amplified when combined with complementary supply chain security frameworks, particularly Software Bills of Materials (SBOMs) and the Supply Chain Levels for Software Artifacts (SLSA) framework developed by Google and now stewarded by OpenSSF.

SLSA defines four levels of supply chain integrity, from basic build provenance (Level 1) to hermetically sealed, reproducible builds with two-party authorization (Level 4). Sigstore’s keyless signing is a core mechanism for achieving SLSA Level 2 and above, because the OIDC-backed certificates embed the provenance claims—repository URI, workflow ref, trigger event—directly into the signing certificate’s Subject Alternative Name extension. This means provenance is cryptographically bound to the artifact rather than asserted in a separate document that could be spoofed.

Attaching and Verifying SBOMs with Cosign

Cosign’s attest subcommand allows signing and attaching arbitrary in-toto attestation documents to container images, stored as OCI artifacts in the same registry. This enables a workflow where the SBOM is generated during the build, signed with the build’s ephemeral key, attached to the image in the registry, and later retrieved and verified by consumers using Cosign’s verify-attestation command. The result is an end-to-end verifiable chain: the artifact exists, the SBOM describes its components, and both are cryptographically bound to the same build identity anchored in the transparency log.

For compliance officers navigating the U.S. Executive Order 14028 and its downstream requirements—including NIST SP 800-218 (the Secure Software Development Framework) and the FDA’s medical device software security guidance—this kind of verifiable provenance is increasingly not optional. Auditors are beginning to ask not just whether an SBOM exists, but whether it is signed and whether its provenance can be verified against an immutable record.

Threat Scenarios Sigstore Defends Against—and Its Limitations

Clarity about what Sigstore does and does not defend against is essential for security architects building realistic threat models. The framework provides strong mitigations against several specific attack classes. A compromised signing key attack is largely neutralized because there are no long-lived keys to steal. A malicious insider who attempts to sign an unauthorized artifact using their CI credentials will produce a transparency log entry under their own identity—creating an audit trail. A silent artifact substitution attack—where a registry serves a different image than what was signed—is detectable at verification time because the signature won’t match the served digest.

However, Sigstore does not solve every supply chain problem. If the build environment itself is compromised and the attacker controls the build process, the malicious artifact will receive a legitimate Sigstore signature—signed by the correct identity, logged in Rekor, and verifiable by consumers. The transparency log records what was signed, not whether the underlying code is trustworthy. This is why Sigstore should be understood as a necessary but not sufficient control, deployed alongside runtime security monitoring, static analysis in CI pipelines, dependency vulnerability scanning, and network segmentation of build infrastructure.

Key Takeaways

• Long-lived signing keys are a structural liability. Sigstore’s keyless model eliminates the most common attack vector in software signing by binding signatures to ephemeral, identity-backed certificates rather than persistent secrets.
• Transparency is a security control, not just an audit mechanism. Rekor’s append-only log enables active anomaly detection—unsigned artifacts, unexpected signing identities, and missing provenance entries all become detectable signals in a monitored environment.
• Granular build identity is the future of supply chain authorization. Sigstore certificates encode not just organizational identity but workflow-level provenance, enabling policy enforcement that distinguishes between authorized release pipelines and all other code paths.
• Sigstore is regulatory infrastructure. As EO 14028 requirements mature and SBOM mandates proliferate across federal contracting and regulated industries, verifiable artifact provenance anchored to an immutable log is becoming a compliance expectation, not an advanced practice.
• A compromised build environment defeats signing guarantees. Sigstore defends the signing ceremony, not the build itself—it must be combined with hardened, isolated build infrastructure and continuous runtime monitoring to constitute a complete supply chain defense.

Conclusion: Making Software Trust Verifiable at Scale

The era of treating a GPG signature or a self-managed code signing certificate as meaningful proof of artifact integrity is ending—not because cryptography has failed, but because key management, transparency, and provenance traceability have consistently been afterthoughts. Sigstore offers a mature, production-ready architecture that makes software signing operationally viable for teams that previously found it too burdensome, and meaningfully more trustworthy for consumers who previously had no way to distinguish a legitimate artifact from a signed-but-compromised one.

The concrete steps your organization should take today are specific: audit every artifact produced by your CI/CD pipelines and identify which carry verifiable provenance and which do not. Evaluate whether your Kubernetes admission control layer enforces signature verification before pod scheduling. Assess your identity provider landscape to determine whether your CI platform supports OIDC-based keyless signing—GitHub Actions, GitLab CI, and Google Cloud Build all do. If you operate a private artifact registry, investigate the Sigstore policy controller Helm chart for your Kubernetes environment and define your first signing policy against a non-production namespace before expanding to production. The transparency log for your organization’s software supply chain should be a living security asset, monitored for anomalies, not a compliance artifact consulted only during incidents.

Start with one pipeline, one artifact type, and one enforced policy. The operational discipline of verifiable provenance compounds—every signed artifact becomes evidence that your supply chain worked as intended, and every anomaly becomes a signal worth investigating before it becomes a breach.