Researchers at Technische Universität Berlin presented TrustBOM at the EDOC 2026 conference in Enschede, the Netherlands, on September 17, 2026. With TrustBOM, a software provider can use zero-knowledge proofs to show that named vulnerable packages are absent from its software bill of materials (SBOM) without handing the SBOM over.
An SBOM is a list of the components inside a piece of software. Customers check it against databases of known vulnerabilities. With a zero-knowledge proof, one party can convince another that a statement is true without revealing the information behind it.
The authors wrote that TrustBOM’s guarantees apply only to the SBOM as generated, and that dependencies the SBOM tool misses or versions it misidentifies undermine them. They also wrote that a customer has no way within TrustBOM to verify that the software it receives matches the build the provider committed.
Van Thang Nguyen is the first of nine authors, among them Maria C. Borges and Stefan Tai of TU Berlin. They posted the paper as a preprint on arXiv on September 18. On its first page, they noted that EDOC had accepted it and that this version does not reflect post-submission improvements or corrections.
How TrustBOM works
In the first of two phases, the provider builds each release in its continuous integration (CI) pipeline, an automated build system, and generates an SBOM in the CycloneDX format. The provider then converts the SBOM into a sparse Merkle tree. A sparse Merkle tree is a data structure that reduces a large set to one short value, its root, against which proofs of membership or absence can be checked.
The provider hashes each dependency’s package URL, a standard string that names a package and its version, with SHA-256 to pick the dependency’s place in the tree. A hash is a short digital fingerprint computed from a piece of data.
The provider records the tree’s root on a public blockchain, along with hashes of the source code, the container image, and the SBOM. It keeps the SBOM and the tree on its own servers.
In the second phase, a customer sends a list of package URLs it wants shown to be absent, entries the authors call policy constraints. The provider builds a Merkle proof of non-membership for each entry and checks all of them inside the RISC Zero zkVM, a virtual machine that produces a zero-knowledge proof that it ran a given program correctly.
The proof’s public output contains only the tree root, a hash of the customer’s list, and one true-or-false result. The authors wrote that the customer verifies the proof locally, checking the program’s identity, comparing the root with the on-chain record, and matching the list hash to its own list.
The researchers released the code on GitHub under the Apache 2.0 license, along with a sample pipeline that uses Anchore’s open-source Syft tool to generate the SBOM.
Measured performance and cost estimates
The authors tested TrustBOM on a CycloneDX SBOM from a production application at the German software company adesso SE. They checked it against 200 Maven packages they described as vulnerable, including Log4Shell-affected versions of Log4j. Log4Shell is a critical 2021 vulnerability in Log4j, a widely used Java logging library.
On a server with an NVIDIA L4 graphics processor, the authors ran seven workloads of between two and 200 constraints, 10 times each, after computing the Merkle proofs in advance. In the preprint, they reported that proving time rose from 2.4 seconds for two constraints to 178.9 seconds for 200, about 0.9 seconds per constraint, with a standard deviation below 1% across runs. They wrote that proof size grew from 0.28 to 21.4 megabytes and that proving time does not depend on the number of components in the SBOM.
The authors priced an L4 at about $0.70 an hour on major cloud platforms. They estimated that proving absence for the 6,125 known vulnerable Maven packages in Google’s Open Source Vulnerabilities (OSV) database as of January 2026 would take about 92 minutes and cost $1.07.
For the 214,233 vulnerabilities listed for npm, the JavaScript package registry, they estimated about 53 hours and $37.49. They described these registry-wide figures as a worst-case upper bound.
Threat model and limits
The authors modeled the provider as a potentially malicious prover with full control of its proving infrastructure and treated customers as honest verifiers that follow the protocol. They also assumed that the CI pipeline converts each build into its tree correctly and proposed periodic audits, needed once per pipeline version, to check it.
The authors wrote that flaws in the zkVM can compromise the system’s soundness. Soundness means that no one can produce a valid proof of a false statement.
They cited CVE-2025-61588, a flaw in RISC Zero’s sys_read call, and wrote that the flaw could be used to forge proofs. In an advisory published October 1, 2025, RISC Zero rated the flaw critical and listed versions 2.3.2 and 3.0.3 of risc0-zkvm as patched.
In the lock files for TrustBOM’s proving service and guest program, risc0-zkvm resolves to version 3.0.3, one of the patched releases. A lock file is a list of the exact library versions a program uses.
The authors also wrote that a customer could rebuild the SBOM from the answers to enough queries, a risk they proposed to limit with rate limiting, request authentication, and anomaly detection. They proposed configurable response delays separately, to prevent timing-based attacks.
Next steps
For future work, the authors proposed membership proofs for positive claims such as license compliance, along with recursive proof aggregation and multi-provider supply chains. To extend TrustBOM’s assurance from the committed SBOM to delivered software, they proposed trusted execution environments that would tie committed artifacts to running binaries. A trusted execution environment is a hardware-isolated area of a processor that can generate verifiable reports of the code it runs.
