VeriSBOM: Trustless SBOM Verification

• VeriSBOM is a confidential SBOM framework that uses zero-knowledge proofs to verify hidden dependency claims without fully disclosing sensitive information.
• It employs a dual-tree architecture—comprising a Package Tree for authenticity and a Shadow Tree for policy compliance—to securely manage and verify dependencies.
• Scalable proof aggregation techniques maintain nearly constant proof size and verification time, even as the dependency count and registry size grow.

VeriSBOM is a trustless, selectively disclosed Software Bill of Materials framework that provides cryptographic verifiability of SBOMs using zero-knowledge proofs. It is designed for settings in which plaintext SBOM disclosure is unacceptable because dependency inventories can reveal proprietary dependencies, unpatched vulnerabilities, architectural strategies, and multi-tier supplier relationships. Within VeriSBOM, third parties can validate specific statements about delivered software—most notably that hidden dependencies are authentic entries distributed by official package managers and that those same dependencies satisfy policy constraints such as the absence of vulnerable dependencies or adherence with specific license models—without learning the full SBOM (Castiglione et al., 14 Feb 2026).

1. Problem Setting and Design Goals

A Software Bill of Materials is treated in VeriSBOM as a structured inventory of the components, dependencies, and associated metadata of a software artifact. The framework begins from a practical asymmetry: software producers are increasingly expected to provide SBOMs for transparency, vulnerability assessment, and compliance, yet full disclosure may expose commercially sensitive implementation choices or create additional attack surface by revealing exact libraries and versions. The framework therefore addresses two coupled requirements: privacy-preserving SBOM sharing and trustless proof-based verification of the hidden contents (Castiglione et al., 14 Feb 2026).

The motivating risks are concrete. Plaintext SBOM sharing can reveal proprietary dependencies and internal architecture; it can also disclose vulnerable or unpatched components that facilitate targeted exploitation. In multi-tier supply chains, an SBOM may reveal sub-suppliers and intermediate relationships, enabling disintermediation. VeriSBOM therefore treats confidentiality not as an optional feature but as a precondition for practical SBOM exchange in many enterprise settings (Castiglione et al., 14 Feb 2026).

The paper explicitly models three attacker types. A targeting attacker learns dependencies or vulnerabilities from a plaintext SBOM to facilitate exploitation. A competitor attacker infers the business graph and proprietary architecture for commercial advantage. A malicious vendor acts as a malicious prover and makes false claims about authenticity or policy compliance. VeriSBOM’s core design target is this last case: verification should require no trust in the SBOM publisher beyond the soundness of the underlying cryptographic primitives (Castiglione et al., 14 Feb 2026).

This framing places VeriSBOM in a broader line of work that treats SBOM reliability as more than schema conformance. Research on cross-tool incompatibility has shown that even standards-compliant SBOMs can lead to inaccurate reporting and undetected vulnerabilities, while work on confidential exchange has shown that selective disclosure without strong verification leaves room for omission or equivocation (Bufalino et al., 7 Oct 2025, Ishgair et al., 16 Sep 2025). This suggests that VeriSBOM is best understood as a response to both confidentiality pressure and verification failure.

2. Cryptographic Architecture

VeriSBOM is built around a dual-tree architecture. The first structure is a Package Tree, or PT, which is a vector commitment over official package-manager data. The second is a Shadow Tree, or ST, which is isomorphic to PT and stores policy-compliance bits for the same package positions. PT establishes authenticity and inclusion; ST establishes policy compliance. The framework instantiates the vector commitment with a Merkle tree (Castiglione et al., 14 Feb 2026).

If the committed vector is

$v = [v_1,\ldots,v_n],$

each leaf is

$\ell_i = h(v_i),$

and each internal node is computed as

$H(h_l \parallel h_r),$

where $h_l$ and $h_r$ are left and right child hashes. The root is the digest $g$. To verify inclusion of a leaf $\ell_k$ with Merkle path

$\pi = [h_1, h_2, \dots, h_{\log n}],$

the verifier recursively recomputes the root from the leaf and authentication path and accepts if the final value equals $g$ (Castiglione et al., 14 Feb 2026).

The design uses sparse Merkle trees with deterministic indexing so that package positions remain stable as registries evolve. For package $p_j$, the sparse-tree index is

$\ell_i = h(v_i),$0

where $\ell_i = h(v_i),$1 is the tree depth. This makes package placement depend on identity rather than insertion order (Castiglione et al., 14 Feb 2026).

The leaves of the two trees carry different semantics. For the package tree,

$\ell_i = h(v_i),$2

while for the shadow tree,

$\ell_i = h(v_i),$3

A value of $\ell_i = h(v_i),$4 denotes compliance and $\ell_i = h(v_i),$5 non-compliance. The central validity predicate requires simultaneous success in both trees:

$\ell_i = h(v_i),$6

A dependency is therefore accepted only if it is both an authentic member of the official package-manager state and marked compliant under the selected policy profile (Castiglione et al., 14 Feb 2026).

The paper’s terminology is precise. “Trustless” means that the verifier does not need to trust the SBOM publisher or vendor. “Selective disclosure” means the publisher can reveal only chosen public metadata while keeping sensitive dependency information hidden. “Verifiable SBOM sharing” means that a recipient can check cryptographically that the hidden SBOM satisfies specific properties without seeing the full dependency set (Castiglione et al., 14 Feb 2026).

3. Policy Encoding and Proof Aggregation

A major design choice is that policy logic is not encoded directly into the arithmetic circuit. Instead, policy evaluation is externalized into the Shadow Tree through a Policy Propagation Engine. For a package $\ell_i = h(v_i),$7, let $\ell_i = h(v_i),$8 be its dependencies, $\ell_i = h(v_i),$9 its local compliance bit, and $H(h_l \parallel h_r),$0 its propagated compliance bit. The propagation rule is

$H(h_l \parallel h_r),$1

A package is compliant only if it is locally compliant and all of its dependencies are compliant. A single zero propagates upward through the dependency graph (Castiglione et al., 14 Feb 2026).

For multiple policy constraints $H(h_l \parallel h_r),$2, the framework extends compliance to

$H(h_l \parallel h_r),$3

and for a set of policies $H(h_l \parallel h_r),$4,

$H(h_l \parallel h_r),$5

The paper also gives a Datalog-style semantics,

$H(h_l \parallel h_r),$6

which makes the conjunction across policy predicates explicit (Castiglione et al., 14 Feb 2026).

This externalization is motivated by scalability and maintainability. If policy logic were encoded directly into the zero-knowledge circuit, changing a policy would require circuit recompilation and would increase proof-generation and verification cost. By moving policy evaluation into auditor-maintained shadow trees, VeriSBOM keeps the zero-knowledge statement at the level of membership and consistency rather than general policy execution (Castiglione et al., 14 Feb 2026).

Scalability is further addressed through folding-based proof aggregation, specifically Nova-style incrementally verifiable computation. Instead of generating separate proofs per dependency, the prover checks one dependency at a time against PT and ST and folds each step into an accumulator. The final proof attests that the validity predicate holds for all dependencies in the SBOM while keeping proof size essentially constant (Castiglione et al., 14 Feb 2026).

The repeated computation is described through iterates of a function $H(h_l \parallel h_r),$7:

$H(h_l \parallel h_r),$8

Successful verification ensures, with overwhelming probability $H(h_l \parallel h_r),$9, that

$h_l$0

In VeriSBOM, the folded computation is “check one dependency, update the accumulator, continue.” This preserves prover cost that scales roughly with dependency count while making verifier cost and final proof size effectively constant in practice (Castiglione et al., 14 Feb 2026).

4. Protocol Workflow and Implementation

The operational protocol has three phases: setup, prove, and verify. In setup, the package manager builds the Package Tree by hashing package metadata and publishing the PT root. The auditor independently evaluates packages under selected policy constraints, computes propagated compliance bits, builds the Shadow Tree, and publishes the relevant ST root. The paper sketches package-manager commitments as

$h_l$1

and policy-side commitments as

$h_l$2

These are inserted into PT and the appropriate $h_l$3, respectively (Castiglione et al., 14 Feb 2026).

In the proving phase, the software developer or designated prover takes the SBOM dependency set $h_l$4, computes the deterministic index for each dependency, obtains the PT and ST Merkle paths, and recursively folds each check into the proof state:

$h_l$5

The final recursive proof is then compressed as

$h_l$6

The public artifact may therefore include only limited public SBOM metadata together with $h_l$7, while the hidden dependencies remain private (Castiglione et al., 14 Feb 2026).

In the verification phase, the client fetches the trusted public roots from the package manager and auditor rather than from the vendor, then checks

$h_l$8

Acceptance requires that the proof verify against those public roots. This root-binding is critical: a malicious vendor cannot build a private parallel package universe and still satisfy verification against the trusted public commitments (Castiglione et al., 14 Feb 2026).

The implementation spans Python, Rust, Circom, and Volatility-style engineering choices familiar from modern proof systems. Python orchestrates data management and policy propagation through pyDataLog and SQLite. The cryptographic core is implemented in Rust. Circom defines the arithmetic circuits, with Poseidon used for in-circuit hashing because it minimizes R1CS constraint count compared with conventional hashes such as SHA-256. Proof generation uses Nova over the Pasta curves Pallas and Vesta, and the final compressed proof uses a Spartan SNARK wrapper. The circuit takes private dependency attributes such as name, version, license, code checksum, permission, the previous accumulator hash, randomizers, and Merkle paths; it computes a Poseidon hash, verifies Merkle inclusion, and updates the accumulator (Castiglione et al., 14 Feb 2026).

VeriSBOM’s supported policy classes include authenticity, absence of vulnerable dependencies, license compliance, approved package lists, and version checks. These are all expressed through the auditor-maintained Shadow Tree, not through public disclosure of the dependency set itself (Castiglione et al., 14 Feb 2026).

5. Security Properties and Empirical Results

The security analysis states completeness, soundness, zero knowledge, position-binding, authenticity of dependencies, policy-compliance guarantees, and accountability through root binding. The paper formulates three principal theorem statements. First, Package Tree position-binding: an adversary cannot open a leaf at a fixed index to a value different from the originally committed value without violating collision resistance. Second, soundness of dual-tree verification: an adversary cannot produce a valid proof for a non-compliant or non-existent dependency. Third, root-binding accountability: an adversary cannot convince a consumer to accept a proof generated for divergent package and shadow trees if verification is performed against the trusted public roots (Castiglione et al., 14 Feb 2026).

These guarantees are strong but not unlimited. The paper explicitly states the main limitation: VeriSBOM proves properties of the SBOM the vendor provides, but it does not prove that the SBOM is complete or faithfully extracted from the delivered artifact. A vendor that omits a real dependency from the SBOM can still produce a proof that is valid relative to the incomplete SBOM. Trust is therefore eliminated with respect to hidden-value disclosure, but not with respect to the completeness of the underlying dependency inventory (Castiglione et al., 14 Feb 2026).

The evaluation was run on an Intel Core i5-8265U laptop with 16 GB RAM under Ubuntu 22.04. It measures vector-commitment storage, Merkle path size, proof size, proof generation time, and proof verification time as functions of registry size and dependency count. The headline storage result is that vector-commitment overhead remains below 1 GB even for more than 10 million packages, and is about 4 GB if package counts exceed 100 million. For a repository with roughly $h_l$9 package-version entries, the tree height is about 27, total storage is about 4–5 GB, a Merkle proof is about 832 bytes, and verification requires 26 hash computations (Castiglione et al., 14 Feb 2026).

The most visible proof-system result is that proof size remains nearly constant at approximately 13 KB regardless of the number of dependencies and the size of the registry. Verification time remains almost constant between 80 and 95 ms across all tested configurations. Proof generation time is affected mainly by dependency count and only weakly by total repository size. The paper gives the example that proving authenticity of a library with 300 dependencies takes only about 4 seconds longer in a system with 1 million packages than in one with 1,000 packages, which is less than a 10% increase (Castiglione et al., 14 Feb 2026).

The paper also evaluates four scenario classes. In baseline compliance, a compliant SBOM against the published roots verifies successfully. In injection, the introduction of an unknown or policy-violating dependency causes failure at PT or ST. In revocation, a vulnerability update changes the shadow-tree root and invalidates the prior proof. In remediation, patching the SBOM and regenerating the proof against the updated root restores validity. These cases make explicit that proof validity is tied not only to dependency membership but also to the current public policy state (Castiglione et al., 14 Feb 2026).

6. Relation to Adjacent Verifiable-SBOM Research

VeriSBOM is part of a broader shift from declarative SBOM production toward evidence-backed and privacy-preserving verification. Its closest direct comparator in the provided literature is Petra, which supports confidentiality-preserving SBOM exchange through selective encryption, salted commitments, Merkle authentication, and signatures. Petra verifies structural integrity of redacted SBOM views, while VeriSBOM verifies semantic claims about hidden dependencies through zero-knowledge proofs; Petra requires decryption rights or auditor access to inspect encrypted material, whereas VeriSBOM allows blind verification against public commitments (Ishgair et al., 16 Sep 2025, Castiglione et al., 14 Feb 2026).

Other work addresses complementary parts of the trust problem. Bomfather moves evidence collection below user space by tracing file accesses at the kernel level with eBPF, hashing accessed files with SHA-256, and binding the observed dependency set into a Merkle root; this strengthens completeness and provenance for build-time and runtime dependencies but does not address confidential selective disclosure (Srinivasan et al., 3 Mar 2025). MEM-SBOM reconstructs a runtime-grounded SBOM from Python process memory, achieving 100% extraction accuracy on 51 real-world applications and showing that runtime evidence can contradict or refine deployment-time SBOMs; this addresses the gap between declared and executed dependencies rather than the confidentiality of sharing those dependencies (Alia et al., 22 Jun 2026).

SBOMproof shows that “alleged compliance” is not enough: even standards-compliant SPDX and pURL encodings can remain semantically incompatible across scanners, leading to inaccurate reporting and undetected vulnerabilities. This reinforces VeriSBOM’s emphasis on proving specific semantic statements rather than merely serializing an SBOM in a recognized schema (Bufalino et al., 7 Oct 2025). Similarly, work on SBOM-based vulnerability scanning demonstrates that scanners can silently fail on valid inputs, mis-handle identifier semantics, or depend on undocumented optional fields, which suggests that proof-backed SBOM exchange still needs downstream behavioral validation in operational toolchains (Rosso et al., 19 Dec 2025).

A broader survey argues that verification should be treated as a supply-chain assurance problem over the entire BOM lifecycle—generation, canonicalization, evidence binding, secure distribution, runtime correspondence, and downstream trust calibration—rather than a document-format problem alone. From that perspective, VeriSBOM addresses one important slice of the lifecycle: confidential yet publicly checkable sharing of policy-constrained dependency claims (Zhang et al., 16 Jan 2026).

7. Limitations and Open Directions

The central limitation is explicit: VeriSBOM does not prove SBOM completeness. If a dependency is omitted from the SBOM before proof generation, the resulting proof can still be valid. This means that VeriSBOM is a framework for trustless verification of hidden claims about a given SBOM, not for proving that the SBOM exhaustively describes the delivered artifact (Castiglione et al., 14 Feb 2026).

Additional limitations follow from the trust model. The framework still trusts the package manager and auditor roots, so stale or compromised public roots can certify stale or compromised truth. Security also depends on collision resistance of the underlying hash functions, correctness of the circuits, and correctness of the policy-maintenance pipeline. The paper explicitly flags under-constrained circuits as a concern and identifies formal verification of zero-knowledge circuits as future work (Castiglione et al., 14 Feb 2026).

Operationally, prover-side cost remains materially higher than simple encryption-based sharing even though verification stays cheap. Updating commitments as repositories evolve is also a continuing systems problem. The authors identify more efficient incremental commitment schemes, support for additional package repositories, richer policy classes, and real-world deployment studies as future directions (Castiglione et al., 14 Feb 2026).

A plausible implication is that VeriSBOM is best deployed alongside complementary evidence systems rather than in isolation. Research on kernel-level dependency observability, runtime memory-based SBOM recovery, confidential exchange, and cross-tool SBOM validation suggests a layered architecture in which build-time evidence, runtime evidence, selective-disclosure proofs, and downstream scanner validation are combined rather than substituted for one another (Srinivasan et al., 3 Mar 2025, Alia et al., 22 Jun 2026, Ishgair et al., 16 Sep 2025, Bufalino et al., 7 Oct 2025). In that interpretation, VeriSBOM supplies the zero-knowledge verification layer for confidential sharing, while other systems supply stronger guarantees about artifact grounding, lifecycle completeness, and operational interpretation.