Sigstore & Software Supply Chain Security

Signing, verifying, and attesting software artifacts using Sigstore (Cosign, Fulcio, Rekor), SBOM, and SLSA to secure the software supply chain.

Overview

The supply chain is the attack surface

The software supply chain (every tool, dependency, build step and artifact that goes into production software) is a major attack surface. The SolarWinds breach (2020), Log4Shell (2021) and the XZ Utils backdoor (2024) showed attackers increasingly target the build and distribution process rather than the running application.

Sigstore's three components

Sigstore is an open-source project (OpenSSF, Linux Foundation) that makes cryptographic signing of software artifacts free and accessible.

Cosign — Signs container images and arbitrary blobs
Fulcio — Certificate authority that issues short-lived signing certificates tied to OIDC identity (GitHub, Google or Microsoft)
Rekor — Immutable, append-only transparency log that records all signing events publicly

Keyless signing

Traditional signing needed long-lived private keys that had to be generated, stored securely and rotated. Most teams never did that key management well.

Key — Long-lived private key — Certificate valid for 10 minutes, tied to OIDC identity
Burden — Generate, store, rotate — None
Verification — Trust the key — Check Rekor: the certificate was issued to the expected identity, at a timestamp matching the pipeline

SBOM

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in an artifact: packages, versions, licenses and provenance. SPDX and CycloneDX are the two dominant formats.

> [!TIP] When a vulnerability is disclosed, query the SBOMs to see which services depend on the affected component.

SLSA levels

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") defines levels of supply chain integrity.

L1 — Provenance exists
L2 — Provenance is signed and hosted by CI
L3 — Hardened CI: no manual inputs, signed provenance from a trusted builder
L4 — Hermetic, reproducible builds

> [!IMPORTANT] Most organizations target L2 as the first meaningful milestone. SLSA v1.0 regrouped these into Build L1-L3 and dropped L4.

In-toto attestations

In-toto attestations are the glue: structured statements signed by a trusted party that assert facts about the build ("this container was built from this Git commit by this pipeline"). SLSA provenance is a specific in-toto attestation schema.

Key concepts

Cosign: Sigstore tool for signing and verifying container images and other artifacts. Supports keyless signing via Fulcio and traditional key-based signing. "cosign sign" / "cosign verify" are the primary commands.
Fulcio: Sigstore certificate authority. Issues short-lived (10-minute) X.509 certificates tied to OIDC identity. Eliminates long-lived key management by making certificates ephemeral and identity-bound.
Rekor: Sigstore's immutable, append-only transparency log. Records all signing events publicly. Verifiers check Rekor to confirm a signature was made at the expected time by the expected identity.
Keyless signing: Signing artifacts without managing long-lived private keys. Uses OIDC identity (GitHub Actions, Google) to obtain a short-lived certificate from Fulcio. The certificate proves who signed and when.
SBOM (Software Bill of Materials): Machine-readable inventory of all components in a software artifact. SPDX and CycloneDX are the dominant formats. Required by US Executive Order 14028 for federal software vendors.
SLSA levels: L1: provenance exists. L2: signed provenance from CI. L3: hardened CI with no manual inputs. L4: hermetic reproducible builds. Most teams target L2 as the first meaningful goal.

When to use it

Designing secure CI/CD pipelines for containers deployed to production Kubernetes
Implementing image signing policies in Kubernetes via admission controllers
Responding to supply chain vulnerability incidents with SBOM-based impact analysis
Interview questions about securing the software supply chain beyond SAST/DAST
Meeting compliance requirements (FedRAMP, NIST SP 800-218) for software provenance

Interview questions

How does Sigstore's keyless signing work, and why is it better than traditional key-based signing?