TU Berlin’s TrustBOM Lets Vendors Prove a Vulnerable Package Is Absent From Their SBOM Without Sharing It. Its Authors Assume the SBOM Is Complete.

September 18, 2026 – Researchers at Technische Universität Berlin posted a preprint describing TrustBOM, a system that lets a software provider prove that named vulnerable packages are absent from its software bill of materials (SBOM) without handing the SBOM over. An SBOM lists the components inside a piece of software. Customers use that list to check the software against vulnerability databases.

The preprint, arXiv:2609.21419, was accepted to the 30th International Conference on Enterprise Design, Operations, and Computing (EDOC 2026) in Enschede, the Netherlands, where the authors presented it on 17 September. Van Thang Nguyen is the first of nine authors. The co-authors include Maria C. Borges and Stefan Tai of TU Berlin’s Information Systems Engineering group, and Sebastian Werner, whom the conference program lists at the Technical University of Munich.

Whether a package missing from the provider’s SBOM is also missing from its software depends on how the SBOM was produced. The authors assume that the provider’s build pipeline records it correctly and proposed periodic audits to check that. They wrote that a customer has no way within TrustBOM to verify that it received the same software the provider committed on chain.

TrustBOM follows at least four earlier designs for sharing facts about an SBOM without sharing the SBOM, three of them built on zero-knowledge proofs.

How TrustBOM Works

In the first of TrustBOM’s two phases, the provider’s continuous integration (CI) pipeline builds each release and generates an SBOM in CycloneDX format. The pipeline also attests build provenance with the SLSA framework. A command-line tool converts the SBOM into a sparse Merkle tree of depth 256, in which each dependency’s package URL (PURL), the standard string that names a package and its version, is hashed with SHA-256 to pick a leaf. That leaf is set to 1, and every other leaf stays 0.

The pipeline then records the tree’s root on a public blockchain, together with hashes of the source code, the container image and the SBOM. The SBOM and the tree stay on the provider’s servers.

In the second phase, a customer sends the provider a list of PURLs it wants shown to be absent, which the authors call policy constraints. Services run by the provider build a Merkle non-membership proof for each entry and check them all inside the RISC Zero zkVM, a virtual machine that outputs a zero-knowledge proof of the computation it ran.

The proof, which the authors describe as a zk-STARK, has a public output containing only the tree root, a hash of the customer’s list and a single true-or-false flag for whether every listed package was shown to be absent. The provider stores the proof on IPFS and records its content identifier on the blockchain.

According to the paper, the customer verifies the proof locally: the proof must come from the expected program, identified by its RISC Zero ImageID; its root must match the on-chain commitment; and its list hash must match the list the customer sent.

The authors released the code on GitHub under the Apache 2.0 license, with services written in Python, Go and Rust. The project documentation shows a sample pipeline that generates the SBOM from a container image with Anchore’s open-source Syft tool and writes the tree root to a registry contract on a local Hardhat development chain.

Measured Performance

The authors tested TrustBOM on a CycloneDX SBOM from a production application of German software company adesso SE. They checked it against 200 Maven package versions that they describe as vulnerable. According to the authors, the list includes Log4Shell-affected versions of log4j-core and log4j-api, along with versions of Jackson databind, Apache Commons, Spring Framework, Struts and Tomcat.

They ran seven workloads of between 2 and 200 constraints, ten times each, on a server with an AMD EPYC 8224P processor, an NVIDIA L4 GPU and 188 GB of memory, using RISC Zero zkVM 3.0 with CUDA acceleration. The authors computed the Merkle proofs in advance and timed only zero-knowledge proof generation. Proving time rose from 2.4 seconds for two constraints to 178.9 seconds for 200, and proof size from 0.28 MB to 21.4 MB.

Each added constraint cost about 0.9 seconds, 0.1 MB and 0.4 million zkVM cycles, with a standard deviation below 1% across runs. Every non-membership check follows a fixed 256-step path through the tree, and the authors wrote that proving time therefore does not depend on the number of components in the SBOM.

Cost Estimates in the Paper

The authors priced an NVIDIA L4 at about $0.70 an hour on major cloud platforms. They used that rate to estimate the cost of proving absence for every entry that Google’s OSV database listed for three package registries in January 2026.

For Maven, which the authors said had 6,125 known vulnerable packages, they estimated about 92 minutes and $1.07. PyPI’s 17,594 vulnerabilities would take about 4.4 hours and $3.08, and npm’s 214,233 about 53 hours and $37.49, figures the authors described as a worst-case upper bound.

They estimated blockchain costs for Ethereum’s main network using December 2025 prices, an ether price of $3,081 and a gas price of 0.051 gwei. Registering a tree root would cost about $0.03 and recording a proof about $0.04, or $0.07 per verification cycle regardless of SBOM size.

Threat Model and Stated Limitations

The authors model the provider as a potentially malicious prover with full control of its own proving infrastructure. They model customers as honest verifiers that follow the protocol and do not try to infer anything about the SBOM beyond the answers to their queries.

They also assume that the build pipeline converts each artifact into its tree correctly. They proposed periodic audits to check this, required once per pipeline version rather than once per proof.

Of the four limitations the authors listed, the first is that the guarantees cover only the SBOM as generated. If the SBOM tool misses transitive dependencies or misidentifies versions, a customer gets guarantees about an incomplete record.

Soundness also depends on the correctness of the zkVM. The authors cite CVE-2025-61588, a critical flaw in RISC Zero’s sys_read call that let a malicious host run arbitrary code inside the guest program. They wrote that it enabled forged proofs for invalid computations. RISC Zero fixed it in risc0-zkvm 2.3.2 and 3.0.3. The lock files for TrustBOM’s proving service and guest program resolve to 3.0.3.

The authors also wrote that a provider could pass every check and then ship different code, because a customer cannot verify that the software it receives matches the software committed on chain. A customer that sends enough requests could also rebuild the SBOM from the answers, a risk the authors proposed to limit with rate limiting, request authentication, anomaly detection, human review and deliberate response delays.

For future work, the authors proposed membership proofs for positive claims such as license compliance, recursive proof aggregation, and trusted execution environments that would tie committed artifacts to running software. They also proposed supply chains in which several providers commit to their own components.

My Analysis

In August I reviewed four designs for sharing facts about an SBOM without sharing the SBOM: TreeGap, VeriSBOM and zkSBOM, which use zero-knowledge proofs, and Petra, which uses attribute-based encryption. None of the four proves the SBOM complete: the zkSBOM and VeriSBOM authors assume it, the Petra authors rule malicious concealment out of scope, and the TreeGap team leaves it off its list of open challenges. TrustBOM is the fifth, and in my reading the closest of the five to something an enterprise could install, with a CI workflow, a cost model and open-source services.

Its authors assume completeness the same way. A customer who receives a TrustBOM proof learns that a package string does not appear in a tree the provider built from its SBOM tool’s output. Whether the package is in the software depends on the steps that produced the tree, and the proof does not cover them. The public code has a second problem: its verifier takes the identity of the program it checks from the provider’s own file.

TrustBOM Next to the Four Earlier Designs

Absence proofs over a committed SBOM existed before TrustBOM. The Johns Hopkins TreeGap prototype proves that a component is outside a designated set using a sorted Merkle tree and Groth16 proofs. The KTH team behind zkSBOM built absence proofs on zero-knowledge sets and measured how much each answer leaks. What the Berlin group adds is engineering: a GitHub Actions workflow that commits each release, a proving service, a verifier, and a cost per package that varied by less than 1% across runs.

In their related-work section, the authors cite none of the four. Petra and TreeGap were public months before the paper’s latest cited access date of 12 February 2026; VeriSBOM appeared two days after it and zkSBOM on 30 April. They claim to be the first to integrate non-membership proofs into enterprise CI/CD with demonstrated constraint-linear scaling, and in that narrow form I have seen nothing that contradicts the claim. On the preprint’s first page they note that it does not reflect post-submission corrections, so they may cite more in the proceedings version.

What a Non-Membership Proof Covers

At each step between the software and the proof, a package can be left out of the record or written under a different name. A proof of absence looks the same whether the package is missing from the software or only from the record.

Syft, the SBOM generator in the project’s sample pipeline, reads package metadata from the container image. During Log4Shell, Rezilion tested open-source and commercial scanners against packaged Java files with log4j nested inside different archive formats, and no scanner found it in all of them. In the TOSEM study I cited in August, the authors measured inter-tool consistency on package detection across six SBOM tools at 7.84% to 12.77% in October 2024, depending on the language, and at 6.77% to 8.70% in a follow-up a year later.

The sample pipeline also generates the SBOM from the image’s mutable latest tag while recording the image digest returned by the build step. If someone pushes to the same tag between the build and the scan, the inventory of one image is recorded against the digest of another.

The project’s converter copies each component’s package URL into the tree exactly as the generator wrote it. It skips any component without a package URL and logs a warning. A proof of absence can never fail for a component skipped at that step.

Inside the zkVM, each constraint is an exact string. Syft appends architecture and distribution qualifiers to Debian package URLs, so it writes strings of the form pkg:deb/debian/[email protected]?arch=amd64&distro=debian-12. A customer who asks about the same package and version without the qualifiers receives a valid proof that it is absent. The Johns Hopkins team listed naming and version normalization as an open problem for TreeGap. TrustBOM does no normalization. Tidier strings would not be enough on their own: the converter would have to record each package under an agreed canonical form, for example without qualifiers, and customers would have to ask in that form.

The audit the authors propose runs once per pipeline version. An auditor can confirm that the generator and converter are configured as described. A customer still cannot learn from that audit whether the generator found every package in a particular release. SLSA provenance, which the authors also use, records how an artifact was built. It has no entry for a package the generator missed.

As in the proof-of-solvency failures I described in August, each proof was valid for the set it was given, and the party being checked chose the set.

The Reference Verifier Reads the ImageID From the Proof File

In RISC Zero, every guest program has an ImageID derived from its compiled code. A receipt verifies against whichever ImageID the verifier supplies. In the paper’s threat model, the provider has full control of its proving system. A customer protects itself against a provider that runs a different program by accepting only the ImageID of the published TrustBOM guest.

At the latest commit, of 8 August 2026, the repository’s verifier service does not hold the expected ImageID, although the README describes it as validating proofs against that value. It reads the ImageID from the same JSON document as the proof, which the provider’s proving service writes. It does compare the root, list hash and flag in that document with the receipt’s output. A match means only that the document is consistent with itself.

A provider could compile a program that outputs the real tree root, the hash of the customer’s own list and a compliant flag set to true, and the reference verifier would accept the result. Running a self-hosted copy of the same service, which the guide recommends for maximum trust, does not change that.

The customer verification guide tells customers that a proof_verified: true response means, with cryptographic certainty, that none of their banned packages is in the SBOM, that the root matches the vendor’s commitment and that the authentic TrustBOM program produced the proof. The service confirms none of those three. It returns proof_verified: true for a receipt whose flag is false, and it checks neither the root against the chain nor the program’s identity against a fixed value. The guide calls the comparison of the list hash with the customer’s own list optional. Its only mention of the chain is that the root can also be retrieved from it.

The registry contract accepts roots from any address and records the sender, so a customer also has to learn the provider’s account address from the provider and check it. Its keys are global, and the contract accepts only the first registration of each root. Roots are indexed only by their hash, so anyone can register a root before the provider does. A provider cannot register two releases that share a dependency set, and two providers with identical dependency sets cannot both register.

The authors specify the right checks in the paper, so these are implementation gaps. The change to the verifier is small: compare against the expected ImageID, accept only a compliant result, and require the list and root checks. The project’s build already generates the expected ImageID as the constant SBOM_VALIDATOR_ID. Distributing the expected ImageID to customers through a trusted channel, handling upgrades of the guest program and tying releases to authenticated commitments take more work. Anyone evaluating a zero-knowledge attestation product should ask where the verifier gets the identity of the program it checks.

What the Published Records Reveal

The authors model customers as honest verifiers and so leave out the party a confidentiality system most needs protection from: a competitor posing as a customer. Zero knowledge is a property of each proof on its own. A customer who collects enough answers can still reconstruct the SBOM, and the authors list that reconstruction among their limitations.

TrustBOM generates RISC Zero’s default composite receipts. RISC Zero’s security model says that proofs which have not gone through its recursion prover leak the length of execution. The guest program stops at the first package that fails its check, so anyone holding a failed proof can estimate from its length where in the list the failure occurred. I have not measured how precisely. A provider cannot hide that by delaying responses. A provider that compresses the receipt through recursion would hide it, and would also stop the proof growing with the length of the list.

The proof orchestrator in the repository writes every result to the registry contract, compliant or not, together with the tree root, the IPFS content identifier and a hash of the customer’s list. The authors’ architecture figure marks both the chain and the IPFS store as public. Their principle of distributed disclosure control depends on each customer’s answers staying with that customer.

Anyone can recompute the hash of a one-entry list, or of a standard list in a standard order, and match it to a record. A compliant: false record against such a list does not prove that a listed package is present. The guest reports false for malformed input as well, and it rejects a nonzero leaf before checking it against the root. The contract stores whatever flag the caller submits. Under honest operation, though, any reader of the chain can infer from such a record that the release very likely contains a listed package.

The tree also has no salt. Its root is a fixed function of the set of package URLs, so anyone holding a candidate SBOM, from an earlier release or a leak, can compute its root and confirm whether the provider committed to exactly that set.

Package Versions Missing From the Registry-Wide Estimates

I find the measured results credible: a real SBOM, seven workloads, ten runs each and less than 1% variation. The authors measured up to 200 constraints, with the Merkle proofs computed in advance, so everything beyond that is extrapolation. They multiply 0.9 seconds by OSV’s counts, of packages for Maven and of vulnerabilities for PyPI and npm. Because a TrustBOM constraint is an exact package-and-version string, covering one advisory takes one constraint for every affected version.

OSV’s Log4Shell record lists 33 affected versions of log4j-core, plus copies of the same code packaged under other Maven names, such as pax-logging-log4j2. Because advisories overlap, the total is not a simple multiple. The authors do not show how they turned vulnerability records into the strings their implementation checks, so their registry-wide figures are not established as worst-case upper bounds. The dollar amounts are GPU-hour arithmetic at $0.70 an hour. The hours grow with the number of strings. At the paper’s 0.1 MB per constraint, an npm-wide proof would also run to about 21 GB before any version expansion.

Building the list correctly is the customer’s job. The authors’ description of their own benchmark list has an error: they say it includes Log4Shell-affected versions of log4j-api, but Apache says an application that uses log4j-api is not affected unless it also uses log4j-core. TrustBOM would prove the absence of those entries as faithfully as any other.

Which Parts of TrustBOM a Quantum Computer Would Break

The authors describe their commitments as durable, tamper-evident audit records. The proof side is built from hash-based components designed to resist quantum attacks: SHA-256 trees, and STARKs, whose designers called them post-quantum secure in the title of the 2018 paper that introduced them. RISC Zero’s security model lists its STARK provers as not known to be vulnerable to quantum attacks, with security based on the random-oracle model and a conjecture that the best known attack on STARKs is the best possible one.

Customers verify the STARK receipts directly, with no conversion to the Groth16 format that RISC Zero offers for on-chain verification and that its security model marks as vulnerable to quantum computers. TreeGap uses Groth16 throughout, so a cryptographically relevant quantum computer (CRQC) would break the soundness of its proofs.

The quantum exposure is in the account key the provider uses to sign each registration. The registry contract ties a root to whichever Ethereum account submitted it. The prototype uses externally owned accounts, whose transactions are signed with ECDSA over secp256k1, which Shor’s algorithm breaks. An attacker with a CRQC could recover such an account’s private key from the public key exposed in any of its past transactions and then register new roots and compliance records in the provider’s name, the pattern I call Trust Now, Forge Later. Records already on the chain stay where they are in its history, so the forgeries would be new registrations. Because the registry accepts any submitter, verifiers would have nothing else to tell those forgeries apart from the provider’s own records.

The EU Cyber Resilience Act requires manufacturers to draw up an SBOM covering at least the top-level dependencies of their products, and it applies in full from 11 December 2027. Manufacturers must keep the technical documentation, which includes the SBOM when a market surveillance authority asks for it, for at least ten years after a product goes on the market or for its support period if that is longer. A provider that adopts such a registry for CRA evidence would still be registering commitments after the end-2030 target that the EU’s coordinated PQC roadmap recommends for high-risk use cases.

A provider that also signs each root together with the artifact digest and release identity using ML-DSA would protect attribution independently of the Ethereum account, as long as verifiers require that signature and obtain the provider’s ML-DSA key through a channel they trust. A transparency service would need to authenticate the provider in the same way, instead of recording whatever is submitted.

Requirements for a CBOM Version of TrustBOM

Several of my clients are being asked to hand their cryptographic bills of materials (CBOMs) to regulators and to their own customers. In the companion piece to my August article I explained what can go wrong once they do. A provider could use the same proving setup to answer a product CBOM question such as whether an RSA-1024 entry appears in a firmware image’s committed CBOM, because an algorithm-and-parameter identifier can key a sparse Merkle tree as easily as a package URL can. That answer would cover the committed CBOM, not every place the firmware might use RSA-1024.

For a CBOM version, a provider would need a hiding commitment, with secret random values mixed into each leaf so that the root reveals nothing to someone holding a plausible guess. CBOM identifiers come from a small vocabulary, dozens of algorithms and parameter sets rather than hundreds of thousands of packages, so with an unsalted root anyone with a good prior can confirm a candidate inventory. The provider would also need to keep proofs, list hashes and results off any public ledger. From a public non-compliance record against a list of quantum-vulnerable algorithms, attackers would learn which product to look at first.

An enterprise CBOM has no build pipeline to bind its commitment to. Cryptographic discovery tools also disagree with one another. For CBOMbench, a 2025 University of Bern bachelor’s thesis, Simon Egli ran IBM’s CBOMkit, cdxgen and an LLM-based approach over 100 Java repositories. The three tools reported between 516 and 38,354 components, classified in different ways, and Egli had no ground truth to say which was right. In an enterprise estate, discovery tools also have to read binaries, configurations and network traffic. I have found no measurement of how completely a combined discovery process captures the cryptography of an estate.

Executive Order 14412 gives CISA, working with NIST, until 19 March 2027 to publish guidance on the minimum elements of a CBOM. The regulators asking for CBOMs want to know what an inventory covers. Four of the five designs prove statements about a committed list, and none of the five shows that the list is complete. In their future-work section the Berlin authors propose deterministic builds and trusted execution environments to tie the committed artifact to the code that runs. That would close the gap between committed and delivered software. It would still leave open whether the SBOM generator recognized every dependency, which no proof over the SBOM can settle. I would treat a TrustBOM proof as evidence about the vendor’s SBOM and ask the vendor separately how it knows the SBOM is complete.

From the author