SBOM and Sigstore in Practice: Building a Verifiable Software Supply Chain

TL;DR: A verifiable software supply chain has four parts that have to work together: an SBOM that enumerates what's actually inside an artifact, SLSA provenance that proves how and from what source it was built, Sigstore-based keyless signing that binds an identity to both without managing private keys, and admission control at deploy time that actually refuses to run anything that doesn't verify. Most organizations have zero or one of these. The EU Cyber Resilience Act's September 2026 SBOM mandate is pushing more teams toward having all four — this article covers how the pieces fit.

Software supply chain security spent years as a compliance checkbox — generate an SBOM, file it somewhere, move on. That's changed for two reasons: attacks like SolarWinds and the XZ Utils backdoor made clear that knowing what's in your software isn't enough if you can't also prove how it got there, and regulation has caught up. The EU Cyber Resilience Act mandates a machine-readable SBOM for products with digital elements sold into the EU starting September 2026, covering at least the most important dependencies. This article walks through building the full verifiable chain, not just the SBOM piece regulators are asking for.

The four pieces, and what each one actually proves

It's worth being precise about what each component proves, because teams often implement one and assume it covers the others.

SBOM (Software Bill of Materials) enumerates the components, libraries, and versions inside an artifact, typically with license and known-vulnerability metadata attached. The two formats that matter are CycloneDX and SPDX — CycloneDX has expanded well beyond software into hardware (HBOM), ML models (ML-BOM), and cryptographic inventories (CBOM), while SPDX (now at the 3.0 line) remains the format most commonly referenced by government and standards bodies. An SBOM tells you what's inside. It says nothing about how it was built or whether it's been tampered with since.

SLSA provenance (Supply-chain Levels for Software Artifacts) answers the question an SBOM doesn't: was this binary built from inspectable source code, by a trusted platform, using declared inputs? A SLSA provenance attestation names the source repository, the exact commit, the build platform, the build configuration, and the resulting artifact digest — signed, so it can't be silently altered after the fact. SLSA defines four maturity levels, from "documented, scripted build" (L1) through "hermetic, two-person-reviewed build on a hardened isolated platform" (L4). Most organizations should target L2 or L3 as a realistic near-term goal; L4 is a genuinely high bar that few org, and few CI platforms, are built to satisfy today.

Sigstore (Fulcio + Rekor + Cosign) is what makes signing practical at CI scale without the key-management burden that killed most GPG-based signing initiatives. Fulcio issues short-lived certificates binding a cryptographic key to an OIDC identity (your GitHub Actions workflow, your GitLab CI pipeline) rather than a long-lived private key someone has to store and rotate — this is "keyless signing." Rekor is a public, append-only transparency log that records every signature, so a compromised or backdated signature is detectable, not just theoretically preventable. Cosign is the CLI that signs and verifies container images, SBOMs, and other artifacts against this infrastructure.

Admission control is the part that turns all of the above from documentation into enforcement. A policy engine (Kyverno or OPA/Gatekeeper are the common choices in Kubernetes environments) checks, at deploy time, that an image carries a valid Cosign signature, a valid SLSA provenance attestation from an approved builder, and an attached SBOM — and refuses to schedule anything that doesn't. Without this step, the first three pieces are audit trail, not protection: you'll know after the fact that something unsigned got deployed, instead of it never happening.

The chain end to end

source commit (signed, or at minimum from a protected branch)
   → CI build (GitHub Actions / GitLab CI, OIDC-federated identity)
      → produces: container image
      → produces: SLSA provenance attestation (source, commit, build config, digest)
      → produces: CycloneDX SBOM (dependency inventory)
   → Cosign signs image + provenance + SBOM (keyless, via Fulcio cert)
   → signatures recorded in Rekor (public transparency log)
   → registry push
   → admission controller (Kyverno/Gatekeeper) verifies signature + provenance + SBOM presence before allowing deploy

A concrete generation and signing step in CI looks roughly like this:

# simplified GitHub Actions step
- name: Generate SBOM
  run: syft packages docker:myapp:${{ github.sha }} -o cyclonedx-json > sbom.json

- name: Sign image (keyless)
  run: cosign sign --yes myregistry/myapp:${{ github.sha }}

- name: Attach and sign SBOM
  run: cosign attach sbom --sbom sbom.json myregistry/myapp:${{ github.sha }}
       && cosign sign --yes --attachment sbom myregistry/myapp:${{ github.sha }}

And the corresponding admission policy that refuses anything unverified:

# simplified Kyverno ClusterPolicy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cosign-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-image-signature
      match:
        resources:
          kinds: ["Pod"]
      verifyImages:
        - imageReferences: ["myregistry/*"]
          attestors:
            - keyless:
                subject: "https://github.com/myorg/myrepo/.github/workflows/*"
                issuer: "https://token.actions.githubusercontent.com"

validationFailureAction: Enforce is the detail that matters most in that policy — set to anything else (a common initial rollout choice, Audit) and the whole chain degrades back to "we'd know after the fact," which is exactly the gap admission control exists to close.

Rollout order: don't try to do all four at once

Attempting to stand up SBOM generation, SLSA provenance, keyless signing, and enforcing admission control simultaneously is how these initiatives stall for a year. A workable sequence:

1. SBOM generation first, non-blocking — wire SBOM generation (Syft, or your language ecosystem's native tooling) into CI and start publishing artifacts, without gating anything on it yet. This alone satisfies near-term compliance asks and starts building the muscle of treating SBOMs as a build output, not an afterthought.
2. Signing next, still non-blocking — add Cosign keyless signing to images and SBOMs, verify manually or via a dashboard, but don't enforce yet. This is where teams typically discover CI identity/OIDC configuration issues that are much cheaper to fix before enforcement than after.
3. SLSA provenance, targeting L2 initially — most CI platforms can generate this with relatively modest configuration changes once signing is already working, since provenance attestations use the same signing infrastructure.
4. Admission control last, in Audit mode before Enforce — run the policy in audit/dry-run mode against real traffic for a few weeks, fix whatever it flags (legacy images, third-party images you don't control the build of), and only then flip to enforce.

Skipping straight to step 4 without the groundwork is the single most common way these rollouts fail: the policy goes live, blocks a legitimate deploy during an incident, gets disabled in a panic, and never gets re-enabled.

What this doesn't solve

A verifiable chain proves provenance and inventory — it doesn't make your dependencies secure. An SBOM will faithfully enumerate a vulnerable dependency; SLSA provenance will happily attest to a build that includes a component with a known CVE, because provenance is about the build process, not the content's security posture. Pair the chain described here with actual vulnerability scanning against the SBOM (most SBOM tooling integrates with a vulnerability database lookup) and a patching SLA — the chain gives you the visibility and tamper-evidence to act on scan results quickly and with confidence in what's actually deployed; it doesn't replace the scanning itself.

Handling the transparency log and revocation

Rekor's append-only transparency log is what turns "we signed this" into "anyone can verify we signed this, and when" — but it also raises an operational question teams don't think through until they hit it: what happens when a signing identity is compromised, or a build turns out to have been produced from a poisoned source commit after the fact? Sigstore's short-lived certificates (typically valid for minutes, tied to a single signing event) mean there's no long-lived key to revoke in the traditional PKI sense — the exposure window for a compromised CI credential is naturally bounded by how quickly that credential itself is rotated at the identity provider (GitHub, GitLab) level, not by a separate certificate-revocation process.

What you can and should do is maintain a way to mark specific signed artifacts as untrusted after the fact — an internal "do not deploy" list checked by the same admission controller that verifies signatures, keyed by artifact digest. This isn't a Sigstore-native feature; it's a policy layer your team owns on top of the verification chain, and it's worth building before you need it rather than during an incident when a signed-but-compromised artifact needs to be pulled from rotation immediately.

Measuring whether the rollout is actually working

Two numbers are worth tracking once the chain is live, both drawn from the admission controller's own logs: the percentage of production deploys that pass verification versus the percentage that hit an exception path, and the age distribution of exceptions (a one-week-old exception for a vendor image you're actively working to replace is very different from a two-year-old exception nobody remembers the reason for). Treat the exception list as a backlog with an owner, not a permanent allowlist — every entry on it is a gap in the chain you just spent significant engineering effort building, and it deserves the same visibility a security team gives to any other open risk.

Organizations that have completed this rollout across SBOM, provenance, signing, and enforced admission control report substantially fewer supply-chain-related security incidents relative to before the chain was in place, alongside meaningfully lower incident-response cost when something does surface — largely because the provenance data that used to require days of forensic reconstruction ("what was actually running, and where did it come from") is now attached to the artifact itself.

Syslabs' team builds software supply chain security programs — SBOM, signing, and admission control — as part of our cybersecurity consulting work.

Sources: Supply Chain Security 2026: SBOM, Sigstore/SLSA, and Admission Control, Chainguard Academy: How to Sign an SBOM with Cosign, Cloudsmith: What is the SLSA framework?, Interlynk: CycloneDX vs SPDX in 2026