Skip to main content

Introduction

TrustBOM is a blockchain-anchored system for privacy-preserving SBOM verification using zero-knowledge proofs.

The Problem​

The growing complexity of the software supply chain poses legal and security challenges to organizations that sell software. Vendors rely on open source software and must comply with licensing terms while keeping track of security vulnerabilities.

Software Bills of Materials (SBOMs) have emerged as a solution, containing metadata about dependencies, versions, and authors. They became increasingly relevant after the 2021 US executive order mandating SBOMs for government software purchases, and the EU Cyber Resilience Act suggesting SBOM generation for software manufacturers.

However, mandatory SBOM distribution creates a critical tension: transparency vs. intellectual property protection. For vendors, disclosing a complete dependency graph reveals proprietary design details and provides adversaries with a map of potential targets. For customers, relying solely on vendor self-attestation creates a trust gap—without access to raw data, claims cannot be verified.

The Solution​

TrustBOM resolves this tension by enabling vendors to cryptographically prove the absence of banned dependencies (vulnerable components, restricted licenses) without revealing their complete SBOM.

The system answers one key question: "Is the following list of packages present in the SBOM?" — with cryptographic proof, not just attestation.

How It Works​

The system operates via a two-phase protocol that decouples the software build process from compliance verification.

Phase 1: Commitment (CI/CD Pipeline)​

Every time a vendor releases software, their CI pipeline:

  1. Builds the software artifact
  2. Generates an SBOM using CycloneDX-compliant tooling
  3. Transforms the SBOM into a Sparse Merkle Tree (SMT) of depth 256, where each dependency's Package URL (pURL) is hashed to determine its leaf position
  4. Commits the SMT root hash to the blockchain along with hashes of the source code, image, and SBOM

The cleartext SBOM and SMT data remain in the vendor's private database. Only the cryptographic commitment is public.

Phase 2: Verification (On-Demand)​

When a customer wants to verify that specific packages are not in the vendor's software:

  1. Customer sends a request with the SMT root hash and a list of banned package pURLs
  2. Proof Orchestrator Service receives the request and retrieves the corresponding SMT
  3. Merkle Proof Service generates compressed non-membership proofs for each banned package (proving the leaf value is zero)
  4. Proving Service runs the proofs through a RISC Zero zkVM, producing a zero-knowledge proof that commits to both the SMT root and a hash of the banned list
  5. IPFS Service stores the proof on IPFS and pins the CID to the blockchain
  6. Customer receives the proof and verifies it locally using a universal RISC Zero verifier, checking that:
    • The proof is valid and generated by the expected guest code
    • The SMT root matches the on-chain commitment
    • The banned list hash matches what they requested

If verification succeeds, the customer has cryptographic certainty that none of their banned packages exist in the vendor's SBOM—without ever seeing the actual dependency list.

Architecture​

System Architecture

The proving system is a microservice architecture hosted by the vendor:

  1. Proof Orchestrator Service receives the customer request containing an SMT root and banned package list
  2. Merkle Proof Service generates compressed non-membership proofs for each package
  3. Proving Service uses RISC Zero zkVM to generate a zero-knowledge proof
  4. IPFS Service stores the proof on IPFS with the CID pinned to the blockchain
  5. Verifier Service allows independent verification of proofs
  6. Smart Contracts anchor SMT root hashes and maintain the immutable audit trail