Software Supply Chain Integrity Playbook (SBOM + SLSA + Sigstore)

Date: 2026-03-01
Category: knowledge (software / security / delivery)

Why this matters

Most teams still answer "what shipped?" with best-effort logs and trust. That fails during incidents.

A practical supply-chain baseline should let you prove:

• what artifact was released (digest),
• how it was built (provenance),
• from which source/workflow (identity + commit),
• with which dependencies (SBOM),
• and whether policy accepted it before deploy.

Goal: make production promotion a verification problem, not a trust ritual.

Threat model (realistic, not cinematic)

Defend first against common failures:

1. wrong commit / wrong branch built,
2. tampered artifact after build,
3. dependency surprise (unknown vulnerable component),
4. untrusted CI context (fork PR artifact treated as release),
5. unverifiable manual hotfix binary.

Do not assume attestations alone mean "secure". They provide evidence; your policy decides acceptance.

Core primitives

1) SBOM (inventory)

Use SPDX or CycloneDX as machine-readable dependency inventory.

Minimum fields to enforce in policy:

• component identifier (purl/package identity),
• version,
• dependency edges,
• generation timestamp,
• producer/tool metadata,
• artifact digest linkage.

Operational rule: SBOM must be generated from the actual build output context, not only from source manifests.

2) Provenance attestation (how it was built)

Capture at least:

• repository + commit SHA,
• workflow/build definition identifier,
• builder identity (OIDC subject / issuer),
• build start/end time,
• subject artifact digest,
• top-level resolved inputs.

This is the evidence plane for SLSA-style verification.

3) Signature + transparency

Sigstore keyless model (practical summary):

• ephemeral keypair per signing event,
• short-lived certificate bound to OIDC identity (Fulcio),
• signed event logged for auditability (Rekor, public instance flows).

This removes long-lived key handling burden and gives a queryable audit trail.

4) Verification policy (the actual control)

No verification, no security benefit. Enforce policy gates before deploy:

• trusted issuer/identity patterns only,
• expected repository/workflow/ref,
• digest match between artifact and attestation subject,
• required predicate types present (build-provenance, SBOM),
• freshness/expiry constraints.

SLSA mapping (what to target)

Pragmatic maturity ladder:

• Build L1: provenance exists.
• Build L2: provenance signed and generated by hosted build platform.
• Build L3: hardened isolation so build runs cannot tamper with each other and signing material is protected from user build steps.

If using GitHub artifact attestations:

• baseline attestation flow maps to SLSA v1 Build L2,
• reusable-workflow isolation patterns can be used to reach Build L3 posture.

Implementation blueprint (90-minute MVP)

Phase 0 — Artifact identity first

• promote only immutable digest references (sha256:...), never mutable tags alone,
• store build outputs in one registry/bucket with retention policy.

Phase 1 — Emit evidence on every release candidate

• generate SBOM (SPDX or CycloneDX),
• generate build provenance attestation,
• sign/attest in CI with OIDC-based identity,
• publish artifact + attestations together.

Phase 2 — Verify before environment promotion

• dev -> staging: warn-only verification,
• staging -> prod: hard fail on policy mismatch,
• keep allowlist for emergency break-glass with ticket ID + expiry.

Phase 3 — Continuous trust operations

• scheduled re-verification of running artifacts,
• vulnerability correlation against SBOM inventory,
• drift report: running digest with no valid provenance/SBOM = noncompliant.

Example policy checks (high signal)

1. Issuer check

   • attestation cert issuer is expected Sigstore/Fulcio trust root.

2. Identity check

   • subject identity matches regex like:
   • repo:org/repo:ref:refs/heads/main
   • deny fork/untrusted refs for production.

3. Workflow check

   • only approved reusable workflow path/version may produce prod artifacts.

4. Digest binding check

   • artifact digest exactly matches attestation subject digest.

5. Predicate completeness check

   • require both build provenance and SBOM predicate.

6. Freshness check

   • attestation timestamp within policy window (e.g., 30 days for prod promotion).

SBOM format choice (quick rule)

• Choose CycloneDX when security tooling depth and operational metadata are priority.
• Choose SPDX when licensing/compliance interoperability is primary.
• Keep a canonical internal schema either way; avoid format wars in runtime controls.

Critical point: conversion between formats can lose semantics if fields don’t map 1:1. Verify downstream parsers against your required fields.

Common failure patterns

1. "We sign everything" but never verify

   • Cosmetic security. Add mandatory verification gates.

2. Attest only container image, not deploy manifest

   • Leaves room for manifest-level tampering.

3. SBOM from lockfile only

   • Misses build-time/resolved/runtime differences.

4. No identity pinning

   • Any validly signed artifact from same ecosystem may slip in.

5. Break-glass with no expiry

   • Temporary bypass becomes permanent policy hole.

Operator runbook (minimal)

On verification failure:

1. stop promotion,
2. capture failing predicate + digest + identity claims,
3. classify: identity mismatch / digest mismatch / missing predicate / expired evidence,
4. open incident with artifact digest as primary key,
5. only allow break-glass via time-boxed approval and postmortem.

SLO suggestion:

• 99% of production artifacts have valid provenance + SBOM and pass policy at deploy time.

References

• SLSA v1.0 Security Levels: https://slsa.dev/spec/v1.0/levels
• SLSA v1.0 Requirements: https://slsa.dev/spec/v1.0/requirements
• Sigstore keyless signing overview (Fulcio/Rekor/OIDC): https://docs.sigstore.dev/cosign/signing/overview/
• GitHub Artifact Attestations concept: https://docs.github.com/en/actions/concepts/security/artifact-attestations
• CycloneDX JSON spec reference: https://cyclonedx.org/docs/1.6/json/
• SPDX 2.3 Annex K (security references usage): https://spdx.github.io/spdx-spec/v2.3/how-to-use/

One-line takeaway

If deploy gates verify identity-bound provenance + digest + SBOM (not just signatures), supply-chain security shifts from "trust CI" to "prove every promotion."