Sigstore

What it is #

Sigstore is an OpenSSF project providing infrastructure for signing software artefacts and verifying those signatures, without each signer having to manage long-lived signing keys. Three pieces matter most:

• Fulcio. A certificate authority that issues short-lived (~10 minute) signing certificates, with the signer’s OIDC identity baked into the certificate. Authentication runs through an OIDC provider such as Google, GitHub, GitLab, or a CI workflow’s federated identity.
• Rekor. A public append-only transparency log of every issued signature. Each signing event becomes a Rekor entry, and verifiers check that the signature appears in the log.
• cosign. The CLI most users interact with. cosign sign <artefact> runs the keyless flow end-to-end: browser OIDC, fetch certificate, sign, upload to Rekor. cosign verify checks the signature, the chain to Fulcio’s root, the OIDC identity carried in the certificate, and the Rekor inclusion proof.

Sigstore is the substrate beneath several mainstream provenance schemes: npm --provenance publishes, PyPI Trusted Publishers, GitHub Actions artifact attestations, and Chainguard image signatures all build on it.

Trust model #

Trust in Sigstore is anchored in three places: Fulcio’s root certificate, Rekor’s signing key, and the set of OIDC providers Sigstore is willing to recognise. These are operated by the Sigstore project as a single public-good instance. Verifying a signature means checking a chain to Fulcio, a Rekor inclusion proof, and that the certificate’s OIDC identity matches what the consumer expects (a specific GitHub workflow, a specific Google account, and so on).

The thing being attested is provenance: this artefact was signed by the holder of this OIDC identity, at this time, with this short-lived certificate. Sigstore does not say anything about what is in the artefact. It raises the cost of unauthorised publishes (an attacker without the project’s CI or OIDC identity cannot mint a signature that matches the expected identity) and provides clear forensic data after an incident. Authorised compromises, where the attacker uses the real publishing identity, still verify cleanly.

Comparison to OpenVet #

Sigstore and OpenVet share a lot of cryptographic shape and diverge on what they are attesting.

What is being attested. Sigstore attests who signed an artefact, under which OIDC identity. OpenVet helps you make attestations about the code itself: whether it is malicious, whether it is implemented correctly, whether there are findings consumers should know about. A package can be Sigstore-attested by a real CI workflow and still contain malicious code; the 2024 Ultralytics PyPI compromise went through the legitimate GitHub Actions pipeline and was properly attested in Sigstore.

Log architecture. Both projects publish to append-only transparency logs. Rekor is one global log shared across all signers. OpenVet has many independent logs, one per publisher, each append-only and signed by the publisher; consumers subscribe to whichever logs they trust by URL in openvet.toml.

Identity model. Sigstore’s keyless flow binds each signature to a short-lived certificate carrying an OIDC identity. That identity is often a CI workflow rather than a human. OpenVet auditors hold long-lived signing keys, on the assumption that an audit is a deliberate human artefact that benefits from a stable, attributable identity.

Maintainer cooperation. Sigstore signing requires the publisher of a package to opt in. Until the publisher does so, downstream consumers get no Sigstore evidence about that package. OpenVet audits can be written by anyone who can read the source, without involving the upstream maintainer at all.

Using alongside OpenVet #

The two are complementary by design; OpenVet’s audit data structures explicitly compose with Sigstore provenance rather than replace it.

Provenance and review answer different questions. Sigstore tells you the artefact you have was signed by the identity you expected. OpenVet tells you what auditors you trust have said about the source that artefact was built from. Both signals are useful at different points: provenance at install or build time, audits at adoption time.

Stacking them. Verify Sigstore provenance on incoming artefacts (or rely on the registry to do so, as npm and PyPI increasingly do), and use OpenVet to check whether direct dependencies have been audited by auditors you trust. Each fills a gap the other does not address.

Where provenance is the best available signal. For binary artefacts that cannot be meaningfully audited (compiled blobs without sources, foundation-model weights, hardware firmware), provenance is often the only signal you can get. OpenVet makes no attempt to displace Sigstore in that role.