SBOM to Provenance: Verifiable Supply Chains on Immutable Ledgers

Executive Order 14028 mandated that federal contractors provide Software Bills of Materials (SBOMs) for all software in their supply chains. The XZ Utils backdoor (CVE-2024-3094), the SolarWinds compromise, and the polyfill.io attack demonstrated why: an SBOM tells you what is in the box, but not whether the contents match what someone claims, or whether they arrived unaltered. Closing that gap requires provenance,a cryptographically signed record of who built what, where, and from which inputs. Anchoring that provenance to an immutable ledger transforms it from a signature into evidence. This post walks through the SBOM baseline, what SLSA adds, how Sigstore and in-toto work in practice, and why transparency logs are non-negotiable for supply-chain verification in regulated environments.

The SBOM Baseline: Inventory Without Assurance

The National Telecommunications and Information Administration (NTIA) defined the minimum elements of an SBOM: product name and version, component name, version, and supplier. SPDX and CycloneDX format these inventories in machine-readable structures that SBOM-consuming tools can parse and aggregate. Both formats are now standard practice in federal procurement.

The problem is structural. An SBOM is a snapshot of what went into a build, but it says nothing about whether the build you received was produced from those components, whether components were swapped, or whether artifacts have been modified since creation. NIST SP 800-161 (Supply Chain Risk Management) and NIST SP 800-218 SSDF (Secure Software Development Framework) acknowledge this gap: SBOMs alone do not meet the verification bar for high-consequence supply chains.

What SLSA Adds: Build Integrity Levels

The SLSA framework (Supply-chain Levels for Software Artifacts, v1.0) defines four progressively stronger assertions about build integrity. Level 1 requires automated builds and access controls. Level 2 adds version-controlled source and build-definition changes. Level 3 enforces hardened build platforms and hermetic build environments. Level 4 requires two-party review and reproducible builds. Each level adds operational cost and complexity. Most open-source projects operate at Levels 1–2 today. Government agencies and sensitive supply chains increasingly require Level 3 or 4.

The distinction matters: a Level 2 build can still be compromised if a developer's workstation is seized; a Level 3 or 4 build isolates the compilation environment so thoroughly that post-hoc injection becomes nearly impossible. SLSA is a framework, not a technology. It describes what security properties to aim for; it does not mandate the tooling. That is where Sigstore and in-toto enter.

Sigstore in Practice: Signing Without Key Management

Sigstore is a free public-good infrastructure for signing and verifying software artifacts without managing long-lived cryptographic keys. Its three layers are Fulcio (a certificate authority that issues short-lived X.509 certificates bound to identity providers), Cosign (the artifact signer), and Rekor (a transparency log that records signed attestations). The design solves the key management problem that has plagued software distribution for decades.

In practice: the CI/CD pipeline calls Cosign to sign a container image or binary artifact using a certificate from Fulcio. The signature is uploaded to Rekor, which appends it to an immutable log. The consumer verifies the signature and checks that the entry appears in Rekor. This design eliminates the burden of managing static signing keys,the system issues five-minute certificates bound to the identity that triggered the build.

In-Toto Attestations: Linking Build Steps

In-toto adds link metadata: each step in the build pipeline (checkout, compile, test, package) produces a link attestation that cryptographically binds inputs to outputs. A consumer can verify that the artifact was produced from a specific commit and that tests passed.

Together, Sigstore and in-toto create a verifiable provenance chain. The weakness is operational: if the signing certificate is compromised after deployment, signatures can still be forged retroactively. This is where the transparency log becomes essential.

Why Immutable Transparency Logs Are Non-Negotiable

A signed attestation can be forged only if the signing key is compromised. But a sophisticated attacker who gains CI/CD access can forge a key, sign a backdoored artifact, and (if no transparency log exists) cover their tracks by deleting or modifying the signature from the registry metadata service. Post-breach log tampering is the standard incident response evasion technique used in major supply-chain attacks.

Anchoring the signature to an immutable ledger changes the economics. Rekor appends signed entries to a Merkle tree that is periodically published. If an attacker modifies an artifact and tries to forge new signatures, those new signatures will never match Rekor's entries. The mismatch is cryptographically detectable. This is why transparency logs are non-optional for true provenance,they transform a signature into verifiable evidence that cannot be forged post-hoc.

Verification on Consumption: Admission Control and Runtime Checks

Provenance is only valuable if consumers verify it. Kubernetes environments increasingly enforce verification using admission controllers (Kyverno, OPA/Gatekeeper) that reject unsigned images at deploy time. Cloud registries can enforce signature verification on pull. Supply-chain aggregators like GUAC (Graph for Understanding Artifact Composition) index attestations across registries to accelerate verification.

Gradual rollout is standard: permissive alerting first, then hard blocks over weeks as teams adapt. SLSA v1.0 includes verification procedures. The OWASP Software Component Verification Standard guides what to check: source repository health, build platform reputation, and attestation freshness.

Data and AI Supply Chains: The Next Frontier

Model weights, training datasets, and fine-tuning instructions are supply-chain artifacts that need the same provenance treatment as binaries. Hugging Face's SafeTensors embeds metadata into model files; Reproducible Builds principles ensure deterministic compilation. Yet coverage remains sparse and few model registries enforce cryptographic verification on pull.

The 3CX compromise exemplified the risk: trojanized development tools spread through multiple distribution channels and evaded detection for months. Model supply chains will face analogous risks,a compromised dataset could poison training, or a backdoored tokenizer could inject exploitable sequences into all downstream models. Training happens offline and results are not immediately verifiable, making detection harder than for binary artifacts.

Extending Provenance to Data and Policy: The Lattix Approach

Lattix's data-centric zero trust (ZTDF) framework extends provenance verification from code and binaries into the data and policy decision layers. Rather than treating provenance as a software-only problem, ZTDF links software provenance to data lineage through a unified audit ledger anchored in Merkle-tree structures. This means that a container image is verified not only for integrity of its source and build, but also for the data it is authorized to access and the provenance of that data through the access control pipeline.

The mechanism is CAS-X (Cryptographic Access State eXtended): every access decision passes through a policy decision point (PDP) that references both the requesting principal (authenticated by the software's build provenance) and the data's cryptographic lineage. The decision is recorded in the ledger. Over time, this creates a unified verifiable chain: source code → build provenance → deployment signature → access policy decision → data lineage. A regulator can audit the entire chain from commit to data touch with cryptographic proof of enforcement at each stage.

The integration is compositional, not replacing existing SLSA tooling. Sigstore signs the container; Lattix's CAS-X extends that trust to the data context in which the container runs. A policy decision point enforces data access based on both the software's provenance and the data's classification and lineage. The result is supply-chain verification that accounts for code integrity, runtime identity, and data context,a requirement that neither SBOMs nor traditional SLSA alone can satisfy for regulated environments.

The Path Forward

SBOM mandates have driven inventory. SLSA frameworks have driven build discipline. Sigstore and transparency logs have made provenance verifiable. The next phase is convergence: binding software provenance to data provenance through cryptographic ledgers. Organizations should start with SLSA Levels 1–2 and Sigstore integration in CI/CD, then layer in consumption-side verification via admission controllers. For those handling sensitive data, data-centric zero trust and unified provenance ledgers are no longer aspirational,they are the baseline for regulated environments.