Category: Software Supply Chain
Sigstore
Simply put
Sigstore is an open source framework that allows developers to sign, verify, and protect software artifacts. It provides tooling to help confirm that software is exactly what it claims to be, supporting trust in the software supply chain. Both software producers and consumers can use Sigstore to validate the integrity and origin of software packages.
Formal definition
Sigstore is an open source project under the OpenSSF umbrella that provides a framework and associated tooling for cryptographic signing and verification of software artifacts, including package distributions and other release artifacts. It is designed to improve software supply chain security by enabling developers to attest to the provenance and integrity of software they produce, and enabling consumers to verify those attestations. Implementations exist for multiple ecosystems, including a Python client available via PyPI, among others.
Why it matters
Software supply chain attacks have demonstrated that compromised or tampered artifacts can propagate through ecosystems at scale, affecting downstream consumers who have no direct relationship with the original source of compromise. Without a reliable way to verify that a software artifact is exactly what its author produced, consumers must either trust distribution channels implicitly or forgo verification entirely. Sigstore addresses this gap by providing a standardized framework for cryptographic signing and verification that is accessible to both producers and consumers across multiple ecosystems.
Who it's relevant to
Software Developers and Maintainers
Developers and open source maintainers can use Sigstore to sign the artifacts they produce and publish, providing downstream consumers with a verifiable attestation of provenance and integrity. This is particularly relevant for maintainers of widely consumed packages, where tampered releases could affect large numbers of dependent projects.
Software Consumers and Operators
Teams that consume third-party software packages, including both commercial and open source dependencies, can use Sigstore to verify that the artifacts they are installing or deploying match signed, expected versions. This verification step helps detect tampering or substitution that may occur between a package's publication and its consumption.
Security and Compliance Teams
Security practitioners responsible for software supply chain risk and compliance programs may find Sigstore relevant as a technical control supporting artifact integrity verification. It can contribute to supply chain security posture by enabling systematic verification of software provenance as part of build and deployment pipelines.
Platform and Toolchain Engineers
Engineers who build and maintain CI/CD pipelines, package registries, or software distribution infrastructure may integrate Sigstore to automate signing at the point of artifact production and verification at the point of consumption, reducing reliance on manual or implicit trust in distribution channels.
Inside Sigstore
Cosign
A command-line tool within the Sigstore ecosystem used to sign, verify, and manage signatures for container images and other OCI artifacts. Cosign stores signatures in OCI registries alongside the artifacts they cover, enabling verification without a separate signature distribution channel.
Fulcio
A certificate authority within Sigstore that issues short-lived code signing certificates tied to an identity verified through an OpenID Connect provider. Because certificates expire quickly, long-term private key management is not required by the signer.
Rekor
An immutable, append-only transparency log within Sigstore that records signing events, including the certificate and artifact digest at the time of signing. Rekor allows third parties to audit and verify that a signature event occurred and that the log has not been tampered with.
OpenID Connect (OIDC) Identity Binding
The mechanism Sigstore uses to tie a signing event to a verifiable identity, such as a human user authenticated through a provider like Google or GitHub, or a workload identity from a CI/CD platform. The OIDC token is exchanged with Fulcio to obtain a short-lived signing certificate.
Keyless Signing
A signing workflow supported by Sigstore in which the signer does not manage long-term cryptographic private keys. Instead, ephemeral keys are generated per signing event, bound to an OIDC identity, and the corresponding certificate is logged in Rekor. Verification relies on the transparency log entry rather than a persistent public key.
Gitsign
A Sigstore component that enables keyless signing of Git commits using OIDC identity, extending the transparency and identity-binding properties of the Sigstore ecosystem to source code commits rather than only built artifacts.
Policy Enforcement
The practice of using Sigstore verification as a gate in deployment pipelines or admission controllers, such as Kubernetes admission webhooks, to ensure that only artifacts with valid, identity-bound signatures are permitted to run in a given environment.
Common questions
Answers to the questions practitioners most commonly ask about Sigstore.
Does Sigstore eliminate the need to manage private keys entirely?
Not entirely. Sigstore's keyless signing mode uses ephemeral keys tied to short-lived certificates, which removes the burden of long-term private key storage and rotation for that signing workflow. However, organizations using Sigstore's traditional signing path with cosign and persistent keys still manage those keys directly. Keyless signing shifts trust to identity providers and the transparency log rather than removing cryptographic key usage from the process.
Does signing an artifact with Sigstore guarantee the artifact is free of vulnerabilities or malicious code?
No. Sigstore signatures attest to the identity of the signer and the integrity of the artifact at the time of signing, meaning the artifact has not been tampered with since it was signed. Signing does not imply any security review, vulnerability scan, or code audit has been performed. A signed artifact may still contain vulnerabilities, insecure dependencies, or malicious code introduced before signing.
What identity providers are supported for keyless signing, and what happens if my organization does not use one?
Keyless signing in Sigstore relies on OpenID Connect (OIDC) tokens issued by supported identity providers, which typically include GitHub Actions, Google, and Microsoft accounts in the public instance. Organizations without access to a supported provider may need to operate a private Sigstore instance configured with their own OIDC provider, or use the traditional key-based signing path with cosign instead.
How do consumers verify a Sigstore signature, and what do they need to trust?
Consumers verify signatures using cosign or compatible tooling by checking the artifact's signature against the signer's certificate and confirming the signing event was recorded in the Rekor transparency log. Trust depends on the transparency log being available and honest, the certificate authority (Fulcio) having issued the certificate to the correct identity, and the OIDC provider having authenticated the signer accurately. Verification fails or is inconclusive if any of these components are unavailable or compromised.
Can Sigstore be used in air-gapped or offline environments?
The public Sigstore infrastructure requires network access to Rekor for logging and Fulcio for certificate issuance during keyless signing. In air-gapped environments, organizations typically need to deploy their own private instances of Rekor and Fulcio, which involves additional operational complexity. Traditional key-based signing with cosign can function offline for the signing step itself, though verification workflows may still require access to a transparency log depending on policy.
What happens to signatures if the Rekor transparency log becomes unavailable?
If Rekor is unavailable, new signing events cannot be recorded in the public log, which may block keyless signing workflows that require a log entry. Verification of previously recorded signatures may also be affected if verifiers require a live query to Rekor. Organizations with strict availability requirements typically implement offline verification using signed checkpoints or bundle artifacts that capture the log inclusion proof at signing time, allowing verification without a live Rekor connection.
Common misconceptions
Sigstore keyless signing eliminates the need for any trust decisions because everything is verified automatically.
Keyless signing shifts trust from key management to identity providers and the transparency log, but verifiers must still explicitly define which OIDC identities and certificate issuers are acceptable. Accepting any valid Sigstore signature without identity policy checks does not provide meaningful supply chain guarantees.
A Sigstore signature proves that an artifact is free of vulnerabilities or that its contents are safe.
A Sigstore signature attests only that a specific identity signed a specific artifact digest at a recorded point in time. It provides provenance and integrity assurance but makes no claims about the security, correctness, or absence of vulnerabilities in the artifact's contents.
Because Sigstore uses a public transparency log, all signing activity is automatically private and protected from exposure.
The Rekor public transparency log is intentionally public and append-only. Signing events, including the signer's identity derived from the OIDC token and the artifact digest, are visible to anyone querying the log. Practitioners signing sensitive or internal artifacts should account for this visibility when deciding whether to use the public Rekor instance or operate a private log.
Best practices
Define explicit verification policies that specify which OIDC identity subjects and certificate issuers are trusted for a given artifact or deployment context, rather than accepting any well-formed Sigstore signature.
Integrate Sigstore signature verification into CI/CD pipeline gates and, where applicable, into runtime admission controllers so that verification is enforced consistently rather than performed only on an ad hoc basis.
Retain the Rekor log UUID or a copy of the signed bundle returned at signing time, as this allows offline or auditable verification of a signing event even if the transparency log is temporarily unavailable.
When operating in environments where signer identity or artifact digests must not be publicly disclosed, evaluate deploying a private Rekor instance and a private Fulcio CA rather than relying on the public Sigstore infrastructure.
Pair Sigstore signatures with attestations, such as SLSA provenance documents, so that verifiers can confirm not only who signed an artifact but also how and where it was built, providing a more complete chain of custody.
Periodically audit the OIDC identity providers and CI/CD workload identity configurations that are authorized to produce signatures, since a compromised identity provider or misconfigured workflow could allow unauthorized signing events that appear valid to verifiers.