Sigstore and SLSA: Proving Where Software Artifacts Come From

After a series of high-profile attacks on the software supply chain - from SolarWinds to worms in npm - one question has become crucial: how do you know that the artifact you downloaded (container image, package, binary) is what it claims to be, and that it was built as you think? The answer is two complementary projects: Sigstore (signing) and SLSA (verifiable provenance). Let’s break them down technically.

Problem: code signing is hard, so no one does it

Classic code signing (GPG, certificates) theoretically solves the authenticity problem. In practice, it falls down to key management: a long-lived private key must be securely generated, stored, protected against theft, and invalidated after leakage. This is so burdensome that most open source projects simply don’t sign releases - and if they do, users rarely verify them anyway.

Sigstore: signing without key management

Sigstore overturns this model by eliminating long-lived private keys. Instead, it uses identity-based signing (keyless signing) with three components:

• Fulcio - a certification authority that issues a short-lived certificate (valid for minutes) based on the identity from OIDC (e.g. GitHub account, Google account, CI workflow identity). You sign the artifact with it, and then the certificate expires - there’s nothing to steal or keep.
• Rekor - public, immutable transparency log. It receives an entry with the signature: what, who (identity), when. Thanks to this, the signature is publicly verifiable and undeniable, and an attempt to silently replace the artifact leaves a trace.
• cosign - a tool that you use in practice to sign and verify (especially container images in the OCI registry).

The result: signing becomes so simple that it can be included in the pipeline without managing secrets. The signature associates the artifact with an identity (e.g. “this image has signed workflow build.yml from repository X”), not with an anonymous key that may have been leaked.

# Simplified flow
cosign sign registry.example.com/app@sha256:...   # OIDC identity → Fulcio → Rekor
cosign verify registry.example.com/app@sha256:... \
  --certificate-identity=... --certificate-oidc-issuer=...

SLSA: provenance, or “how it was built”

The caption says “this is authentic”. However, it does not say how the artifact was created. This is where SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) comes in - a framework that describes the integrity of the build process.

The heart of SLSA is *provenance: a signed, verifiable document (attestation, usually in in-toto format) describing what, from what and where it was built - what source (commit), what builder, what dependencies. The artifact consumer can verify this provenance and reject anything that does not meet its policy (e.g. “I only accept images built by our trusted CI system from the main branch”).

SLSA defines levels of increasing warranty, in simple terms:

• Level 1 - provenance exists (it is known how the artifact was built), although not necessarily tamper-proof.
• Level 2 - Provenance is signed and generated by the hosted build system.
• Level 3 - build is isolated and tamper-proof; provenance is unforgeable because it is generated by a trusted, separated builder to which the code of the project being built does not have access.

The higher the level, the more difficult it is for an attacker - even with access to the repository - to inject a malicious artifact to pass validation.

How it works in practice

Sigstore and SLSA play together: SLSA tells you what guarantee you want, and Sigstore provides the cryptographic mechanism (signature + transparency log) to implement it. Typical flow in a mature pipeline:

1. The CI system builds the artifact in an isolated environment.
2. Generates provenance attestation (what, where, how).
3. Signs the artifact and attestation by Sigstore (workflow identity, entry in Rekor).
4. On deployment - the admission controller (e.g. in Kubernetes) verifies the signature and provenance according to the policy and rejects artifacts that do not meet it.

This closes a loophole exploited by supply chain attacks: it is no longer enough to replace a package in the registry - you also need to forge a verifiable, publicly registered proof of origin, which is practically unattainable at higher SLSA levels.

Where to start

You don’t have to aim for SLSA level 3 right away. A reasonable order:

1. Generate SBOM and basic provenance in pipeline CI/CD - knowing “what and how we build” is the foundation.
2. Sign artifacts via cosign (keyless) - low-cost entry for authenticity and transparency log entry.
3. Verify on deployment. A signature without verification is useless - add signature and identity control on deployment (admission control).
4. Raise the SLSA level gradually: builder isolation, unforgeable provenance, acceptance policies.
5. Extend to vendors. Ask key software vendors about signing and provenance - this is a specific element of vendor risk management.

Summary

Sigstore and SLSA answer two questions that supply chain attacks have made critical: “Is it authentic?” and “how was it built?”. Sigstore makes signing simple enough (no long-lived keys, with a public log) that it can be realistically implemented; SLSA provides a framework for verifiable provenance with increasing assurance. Together, they shift trust from “I trust the package is clean” to “I have cryptographic proof of its origin and construction.”

If you want to build artifact signing and provenance verification into your development process, let’s talk - we help you design secure pipelines as part of security consultation.

Frequently asked questions (FAQ)

How does keyless signing in Sigstore differ from a regular GPG signature? GPG relies on a long-lived private key that must be protected and which compromises all signatures when leaked. Sigstore uses a short-lived identity-based certificate (OIDC) and records the signature in a public transparency log. There is no permanent secret to steal, and the signature is publicly verifiable and linked to a specific identity.

Is SLSA a standard that needs to be “fully implemented”? No - SLSA is graduated. You start by generating provenance (Level 1) and increase guarantees as the process matures. Even a low level gives real value: it is known what was built and how, which makes silent substitutions difficult.

Doesn’t Rekor’s public journal reveal my secrets? No. The signature metadata (hash of the artifact, signer’s identity, time) is sent to the log, not the artifact itself or its contents. The goal is transparency and non-repudiation, not revealing the code.

I sign artifacts, but is that enough? The signature only has value if it is verified upon download and deployment - otherwise it is ornamental. The key is to embed signature and provenance verification at the point of implementation (e.g. an admission controller in Kubernetes), with a policy that rejects artifacts from outside a trusted source.