Wiki · Concept · Last reviewed June 25, 2026

Sigstore

Sigstore is an open-source signing and transparency system for verifying where software artifacts came from and whether they changed after signing.

Category: Concept Updated: June 25, 2026 Tags: AI security, supply chain, Sigstore, signing, transparency logs, model artifacts

Definition

Sigstore is an OpenSSF project for improving software supply-chain security by helping developers and consumers sign and verify artifacts. OpenSSF describes the scope broadly: release files, container images, binaries, software bills of materials, and other artifacts.

The important design choice is keyless signing. Instead of asking every maintainer or build system to manage a long-lived private signing key, Sigstore can bind an ephemeral signing key to an identity through OpenID Connect. The result is not "this file is good." It is narrower: this artifact was signed by a particular identity under a signing event that can be audited.

For AI systems, Sigstore matters because model weights, model packages, inference containers, agent tools, evaluation harnesses, and generated releases all move through chains of custody. A model-serving team needs to know that the artifact deployed is the artifact reviewed, scanned, or approved.

How It Works

The Sigstore system is usually explained through three components. Cosign signs and verifies containers and other software artifacts. Fulcio is the certificate authority that issues short-lived identity-based signing certificates. Rekor is the transparency log that records signing metadata so signing events can be inspected after the fact.

In a keyless signing flow, a signer authenticates with an identity provider, such as an OIDC provider used by a person or automation system. Fulcio issues a short-lived certificate binding the signing key to that identity. Rekor records the signing event in a transparency log. Verification then checks the artifact, signature, certificate or key material, identity expectations, and transparency-log evidence.

Cosign can also support hardware keys, key-management systems, generated key pairs, and bring-your-own public key infrastructure. The keyless path is significant because it reduces the operational burden of protecting persistent signing secrets while making identity and log evidence part of the verification habit.

Agent Context

Agents turn artifact integrity from a release-engineering concern into an operating-system concern. A coding agent can fetch packages, build containers, update tools, write plugins, and pass results to deployment systems. A browser or desktop agent can depend on helper binaries and tool servers that users never inspect.

Sigstore gives those workflows a concrete question to ask before trust is granted: is this exact artifact signed by the expected identity, under the expected issuer, with usable transparency evidence? That question does not solve prompt injection, tool misuse, or malicious behavior inside a signed artifact. It does narrow one failure mode: silent substitution between source, build, registry, hub, and runtime.

Model artifacts are a special case. OpenSSF published a 2025 case study describing work by Google, Sigstore, and OpenSSF on model signing, including signing during model-hub upload and using an uploader identity through OIDC. That is directly relevant to AI governance because model hubs and MLOps systems often become the trust boundary for downstream applications.

Governance and Safety

A governance-grade Sigstore workflow should record the artifact digest, signature, certificate identity, issuer, transparency-log evidence, verification policy, verification time, and approving system. For model and agent releases, that record should connect to the model card or system card, SBOM or AI bill of materials, provenance statement, vulnerability review, and deployment approval.

The main safety mistake is treating signatures as a moral certificate. A signed container can still contain a vulnerable library. A signed model can still have unsafe behavior, hidden backdoors, licensing problems, or poor evaluation results. Sigstore answers an integrity and identity question. It does not answer whether the artifact ought to be trusted for a particular use.

Sigstore becomes more useful when combined with SLSA Provenance, AI Bill of Materials, OpenSSF Scorecard, vulnerability data, sandboxing, and human release review. In that stack, signing is the receipt that lets other controls attach to a stable object.

Defense Pattern

Source Discipline

Claims about Sigstore should cite Sigstore documentation, OpenSSF project pages, or the relevant repositories. The name can refer to the broader framework, the public-good service, or individual tools such as Cosign, Fulcio, and Rekor, so source notes should identify the layer being discussed.

Current signing policy is environment-specific. A claim that a package, model, or container was signed should include the artifact digest, verification policy, expected identity, and date checked. Without those details, "signed with Sigstore" is too vague for audit or incident response.

Spiralist Reading

Spiralism reads Sigstore as an answer to a familiar problem of technological faith: modern work depends on artifacts that arrive without a face. The file appears in a registry, model hub, package manager, or agent workspace, and the user is asked to accept its identity by habit.

Sigstore does not restore intimacy. It restores a trail. The ritual is a cryptographic pause: who signed this, through which identity system, when was the event witnessed, and what object entered the machine? In a culture of automated action, that pause is a modest defense against nameless inheritance.

Open Questions

Sources

Return to Wiki