💻 computer science

VeriSBOM: Secure and Verifiable SBOM Sharing Via Zero-Knowledge Proofs

The paper presents VeriSBOM, a trustless framework that utilizes zero-knowledge proofs and vector commitments to enable third parties to cryptographically verify software supply chain security and compliance policies while preserving the confidentiality of sensitive SBOM data.

Original authors: Gianpietro Castiglione, Shahriar Ebrahimi, Narges Khakpour

Published 2026-02-17

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Gianpietro Castiglione, Shahriar Ebrahimi, Narges Khakpour

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you buy a high-end, custom-built car. Before you drive it off the lot, you want to know two things:

Is it safe? (Are there any known defects or dangerous parts?)
Is it legal? (Does it meet all the government regulations?)

To answer this, the manufacturer hands you a Software Bill of Materials (SBOM). Think of this as a giant, detailed receipt listing every single screw, bolt, engine part, and piece of software code used to build the car.

The Problem:
The manufacturer is terrified to show you the full receipt. Why?

Trade Secrets: If they show you exactly which specific engine part they used, a competitor might steal that idea.
Vulnerabilities: If they admit, "Oh, we used this specific old bolt that we know is rusty but haven't fixed yet," hackers will immediately target that bolt to break into your car.

So, they say, "Trust us, it's safe," but you can't verify it without seeing the secret list. If you ask to see the list, they refuse. If they show you the list, they lose their secrets. It's a deadlock.

The Solution: VeriSBOM (The "Magic Envelope")

The authors of this paper, VeriSBOM, have invented a magical solution using a concept called Zero-Knowledge Proofs.

Imagine the manufacturer puts the entire secret receipt into a Magic Envelope. They don't open it for you. Instead, they use a special machine to generate a Sealed Certificate.

This certificate proves two things without ever opening the envelope:

"I promise every part in this car comes from the Official Parts Store." (Authenticity)
"I promise every part in this car passes the Safety Inspection." (Compliance)

You can check the certificate, and it's mathematically impossible to fake. But the certificate never tells you which specific parts are inside. You know the car is safe and legal, but the manufacturer keeps their secret recipe safe.

How It Works (The Metaphors)

1. The Two Trees (The Dual-Tree Architecture)
Imagine two giant trees growing in a garden.

Tree A (The Official Tree): This tree is grown by the "Official Parts Store" (the Package Manager). Every branch represents a real, legitimate part. If a part isn't on this tree, it's fake.
Tree B (The Safety Tree): This tree is grown by an independent "Safety Inspector" (the Auditor). Every branch here is marked with a green checkmark (Safe) or a red X (Unsafe).

The manufacturer builds their car using parts that exist on Tree A. Then, they check those parts against Tree B to make sure they are green.

2. The Magic Proof (Zero-Knowledge)
The manufacturer takes their car's parts list and runs it through a "Magic Machine" (the Zero-Knowledge Proof system).

The machine looks at the parts.
It checks: "Do these parts exist on Tree A?" (Yes).
It checks: "Are these parts marked Green on Tree B?" (Yes).
It then spits out a tiny, sealed note (the Proof).

This note says: "I have mathematically verified that all parts are real and safe." It does not say: "The car uses a Ford engine and a Toyota transmission."

3. The Folding Trick (Scalability)
If a car has 1,000 parts, checking them one by one would take forever. That's too slow for big software projects.
VeriSBOM uses a trick called "Folding." Imagine you have 1,000 pieces of paper with checks on them. Instead of showing you all 1,000, you fold them all together into a single, tiny origami crane.

The crane proves that all the papers inside are valid.
The size of the crane stays the same, whether you put 10 papers or 10,000 papers inside.
This means the system works just as fast for a tiny app as it does for a massive operating system.

Why This Matters

For Companies: They can share their software safely without getting their secrets stolen or their vulnerabilities exposed to hackers.
For You (The User): You get a guarantee that the software is safe and legal without needing to trust the company's word. You can verify the "Magic Certificate" yourself.
For the World: It stops hackers from finding weak spots in software by reading the "receipts," because the receipts are now hidden behind a mathematical shield.

In short: VeriSBOM is like a notary public for software. It lets you verify that a software product is built correctly and safely, without ever forcing the builder to reveal their secret ingredients. It's the perfect balance between Transparency (knowing it's safe) and Privacy (keeping the secrets).

1. Problem Statement

Software Bill of Materials (SBOMs) are essential for supply chain transparency, listing components, dependencies, and metadata. However, full disclosure of SBOMs poses significant risks:

Intellectual Property (IP) Leakage: Revealing proprietary dependencies or architectural strategies can aid competitors.
Security Risks: Exposing unpatched vulnerabilities or specific dependency versions allows attackers to fingerprint and target software.
Verification Gap: Current solutions either require full disclosure (compromising privacy) or rely on trusted intermediaries (lacking trustlessness). Existing frameworks often fail to allow third parties to verify policy compliance (e.g., "no vulnerable libraries") without seeing the actual dependencies.

The core challenge is to enable selective disclosure: allowing consumers to cryptographically verify that a software artifact contains authentic, policy-compliant dependencies without revealing the specific identity of those dependencies or the full SBOM structure.

2. Methodology: The VeriSBOM Framework

VeriSBOM addresses these challenges using a combination of Vector Commitments (VC) and Zero-Knowledge Proofs (ZKPs), specifically leveraging folding schemes for scalability.

A. Dual-Tree Architecture

The system utilizes two parallel, isomorphic Merkle trees (Vector Commitments) to separate dependency authenticity from policy compliance:

Package Tree ($PT$): Maintained by the Package Manager. It commits to the existence and authenticity of every package version in the official repository.
Shadow Tree ($ST$): Maintained by an independent Auditor. It is isomorphic to the $PT$ (same indices) but stores compliance flags (1 for compliant, 0 for non-compliant) based on policy constraints (e.g., vulnerability status, license type).

B. Cryptographic Primitives

Vector Commitments (VC): Used to create a public root hash ( $g_{PT}$ and $g_{ST}$ ) representing the state of the package repository and policy status. This allows for logarithmic-size proofs of inclusion.
Zero-Knowledge Proofs (ZKPs): The software vendor (Prover) generates a proof attesting that:
- All dependencies in their SBOM exist in the $PT$ (Authenticity).
- All dependencies satisfy the policy constraints in the $ST$ (Compliance).
- Crucially: The proof reveals nothing about the specific dependencies or the full SBOM content.
Folding Schemes (e.g., Nova): To handle large SBOMs with hundreds/thousands of dependencies, VeriSBOM uses recursive folding. Instead of generating a massive proof for the whole list, the prover iteratively "folds" individual dependency checks into a single, constant-size proof. This ensures the proof size does not grow with the number of dependencies.

C. Operational Workflow

Setup: The Package Manager and Auditor publish the roots of their respective trees ( $g_{PT}$ and $g_{ST}$ ).
Prove: The Vendor iterates through their SBOM dependencies. For each dependency, they generate a Merkle path for $PT$ and a compliance check for $ST$. These are folded into a single succinct proof ( $\pi$ ).
Verify: The Consumer verifies $\pi$ against the public roots $g_{PT}$ and $g_{ST}$ . If valid, the consumer is mathematically guaranteed that the hidden dependencies are authentic and compliant, without learning what they are.

D. Policy Propagation Engine (PPE)

To handle complex dependency graphs, the Auditor uses a PPE to propagate compliance status. If a transitive dependency is non-compliant, the status (0) propagates up the tree to all parent packages, ensuring that a package cannot be marked compliant if any part of its chain is compromised.

3. Key Contributions

Privacy-Preserving Verification: A novel framework allowing third parties to verify security and policy compliance of SBOMs without exposing sensitive dependency data.
Dual-Tree Architecture: A separation of concerns between package authenticity (Package Manager) and policy compliance (Auditor), enabling flexible and independent updates to policy roots.
Scalability via Folding: Implementation of recursive folding schemes (Nova) to aggregate thousands of dependency checks into a constant-size proof, solving the scalability bottleneck of traditional ZKPs.
Trustless Accountability: The system prevents "parallel reality" attacks where a vendor might generate a valid proof against a private, forged tree. Verification is strictly bound to the public, trusted roots ( $g_{PT}, g_{ST}$ ).
Implementation & Evaluation: A working prototype integrating Python (orchestration), Rust (cryptographic core), and Circom (circuit logic), evaluated against real-world package registries.

4. Experimental Results

The authors evaluated VeriSBOM on a commodity laptop using datasets ranging from 1K to 10M packages.

Storage Overhead: The Vector Commitment storage for 10 million packages is approximately 1 GB, scaling logarithmically. Even for 100M packages, it remains under 4 GB.
Proof Size: The final ZK proof size is constant (~13 KB), regardless of the number of dependencies or the size of the package registry.
Proof Generation Time: Scales linearly with the number of dependencies but is largely independent of the total registry size. Generating a proof for 300 dependencies takes roughly 4–14 seconds depending on the ecosystem size.
Verification Time: Extremely fast and constant, averaging 80–95 milliseconds, regardless of the complexity of the SBOM.
Interoperability: Successfully demonstrated cross-language support (Rust and C) and compatibility with different package managers (Crates.io, Homebrew).

5. Significance and Impact

VeriSBOM represents a significant advancement in software supply chain security by resolving the tension between transparency and confidentiality.

Enables Selective Disclosure: Organizations can share SBOMs with regulators or clients to prove compliance without leaking trade secrets or vulnerability details to attackers.
Trustless Verification: Removes the need for consumers to trust the vendor's honesty; they only need to trust the mathematical soundness of the ZKPs and the public roots.
Scalable Adoption: The constant-size proof and low verification cost make it feasible to integrate into automated CI/CD pipelines and client-side verification tools without performance bottlenecks.
Future-Proof: The architecture supports dynamic policy updates (e.g., revoking a package due to a new vulnerability) by simply updating the Auditor's root, invalidating old proofs immediately.

In conclusion, VeriSBOM provides a practical, cryptographically sound solution for secure SBOM sharing, bridging the gap between regulatory requirements for transparency and the business necessity of protecting intellectual property.