TrustBOM: A Scalable Architecture for Confidentiality-Preserving SBOMs Across Organizations

TrustBOM: A Scalable Architecture for Confidentiality-Preserving SBOMs Across Organizations

arXiv:2609.21419v1 [cs.CR] 18 Sep 2026

Van Thang Nguyen1 , Frederic Rupprecht1 , Tom Lawrence1 , Lucca Di Benedetto1 , Sören Schubert1 , Amor Rezgui1 , Sebastian Werner2 , Maria C. Borges2 , and Stefan Tai2 Technische Universität Berlin, Germany {van.thang.nguyen, f.rupprecht, t.lawrence, di.benedetto, soeren.schubert, amor.rezgui}@campus.tu-berlin.de 2 Information Systems Engineering, Technische Universität Berlin, Germany {sw,mb,st}@ise.tu-berlin.de 1

Abstract. Software Bills of Materials (SBOMs) have emerged as a key mechanism for software supply chain governance in enterprise architectures. However, their adoption across organizations remains limited due to concerns about exposing sensitive dependency information. To address this limitation, we propose TrustBOM, a scalable architecture for confidentiality-preserving SBOMs integrated into enterprise CI/CD workflows. TrustBOM enables software providers to attest that specific vulnerabilities or restricted licenses are absent from their software without revealing the underlying dependency graph. This is achieved using zero-knowledge non-membership proofs, which are applied selectively based on consumer-defined policy constraints. The architecture ensures that proof generation scales linearly with the number of asserted constraints rather than with the size of the SBOM, enabling efficient operation in large-scale enterprise environments. Empirical evaluation demonstrates linear performance, with an average proof generation time of 0.9 seconds per constraint on commodity hardware, indicating the feasibility of deployment in enterprise platform ecosystems. Keywords: software supply chain security · software bill of materials · confidential compliance · CI/CD · enterprise governance

1

Introduction

Modern enterprise architectures are complex systems composed of many opensource components and third-party dependencies. Managing this growing software supply chain introduces several legal and security challenges. Each dependency carries its own licensing obligations, while simultaneously expanding the attack surface through vulnerabilities it may introduce.

This preprint has been accepted to the 30th International Conference on Enterprise Design, Operations, and Computing (EDOC 2026). This version does not reflect postsubmission improvements or corrections. 2026©

2

V. T. Nguyen et al.

Software Bills of Materials (SBOMs) have emerged as a way to tackle these challenges [6, 11]. For software providers, they enable systematic dependency tracking; for consumers, they provide visibility into what is deployed; for regulators, they facilitate compliance auditing across the supply chain. Their relevance has grown significantly following a U.S. executive order3 mandating SBOMs for all software sold to government agencies, and the EU Cyber Resilience Act4 , which similarly recommends SBOM generation for software providers. However, the disclosure of SBOMs for software providers introduces a critical tension between transparency and the protection of intellectual property. Despite regulatory pressure, providers frequently limit SBOM disclosure to protect proprietary information [11], as exposing a complete dependency graph may reveal sensitive algorithms or trade secrets [11, 12]. Dependencies may also signal strategic intentions: cloud platform SDKs could suggest infrastructure migration plans, analytics libraries may indicate upcoming tracking features, machine learning frameworks could reveal AI capabilities in development, and internationalization packages might hint at market expansion. From a security perspective, exposed dependencies on vulnerable versions also enable attackers to systematically identify targets before patches are deployed, as demonstrated during the Log4Shell crisis (CVE-2021-44228) [10]. Still, consumers require assurances that the software they purchase does not violate their security and compliance requirements (i.e., does not include specific vulnerable components, legally restricted licenses, or organizationally prohibited dependencies). Relying solely on the self-attestation of a software provider creates a trust gap [10]. Recent works attempt to bridge this gap through cryptographic techniques such as blockchainbased attestation and zero-knowledge proofs (ZKPs) [12]. This research suggests a promising direction but still leaves much of the solution space unexplored. Blockchain transactions and ZKPs introduce considerable computational and financial costs, which, if not considered carefully, can quickly become prohibitive in enterprise settings, where software is shipped frequently and dependencies are numerous. A further challenge is that any such mechanism must integrate naturally into existing enterprise platforms, rather than imposing additional operational burden on the software delivery process. In this paper, we propose TrustBOM, a confidentiality-preserving SBOM architecture embedded directly into enterprise CI/CD workflows. Using cryptographic non-membership zero-knowledge proofs, software providers can attest to different consumers that specific CVEs or restricted licenses do not appear in their software, while concealing the dependency graph entirely. TrustBOM operates on a public blockchain and leverages an efficient Sparse Merkle Tree for SBOM representation. Proofs are applied selectively and scale linearly with the number of non-membership constraints rather than with SBOM size. The result is a cost-efficient mechanism for verifiable compliance in software supply chains, addressing key practical barriers that have so far limited SBOM use across orga3 4

https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity, [Accessed: 6 Feb. 2026] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202402847, [Accessed: 6 Feb. 2026]

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

3

nizations. This paper is based on the key insight that compliance can be verified without disclosure by shifting from data sharing to proof-based attestation. This paper makes the following contributions: – Architecture: We design a confidentiality-preserving SBOM architecture that enables verifiable compliance across organizations without disclosing dependency graphs. – Protocol: We introduce a two-phase protocol that decouples SBOM commitment from compliance verification, enabling on-demand proofs against evolving policy constraints. – Scalability: We demonstrate that zero-knowledge non-membership proofs scale linearly with the number of policy constraints rather than SBOM size. – Evaluation: We provide an empirical evaluation using real-world SBOM data, showing practical performance and cost feasibility in enterprise environments. The remainder of the paper is structured to first provide technical background and related work in Sections 2 and 3. Section 4 introduces the system architecture and threat model. Section 5 describes the implementation. Section 6 presents the empirical evaluation, followed by conclusions in Section 7.

2

Background

This section introduces the technical foundations underlying TrustBOM. 2.1

Software Bill of Materials

A Software Bill of Materials (SBOM) is a structured inventory of software components, including dependencies, versions, suppliers, and licenses [8]. SBOMs are typically generated during CI/CD pipelines and serve as a basis for vulnerability detection by matching component identifiers (e.g., PURLs) against vulnerability databases such as OSV5 or the National Vulnerability Database6 . They enable transparency and compliance auditing across software supply chains. 2.2

Zero-Knowledge Proofs

Zero-knowledge proofs (ZKPs) enable a prover to convince a verifier of a statement’s validity without revealing additional information [5]. Modern ZKP systems [4] and zero-knowledge virtual machines (zkVMs) such as RISC Zero7 allow proofs to be generated from programs written in general-purpose languages, reducing the complexity of constructing proof circuits. 5

https://osv.dev/, [Accessed: 6 Feb. 2026] https://nvd.nist.gov/, [Accessed: 6 Feb. 2026] 7 https://dev.risczero.com/, [Accessed: 6 Feb. 2026] 6

4

V. T. Nguyen et al.

2.3

Sparse Merkle Trees

Sparse Merkle Trees (SMTs) are cryptographic data structures that enable efficient membership and non-membership proofs over large key spaces [3]. By mapping identifiers deterministically to tree positions, SMTs allow proofs of absence to be constructed without revealing other elements in the dataset.

3

Related Work

Existing approaches support SBOM exchange with varying levels of security and functionality. Tools such as SBOM.sh8 and the CycloneDX BOM Exchange API9 enable standardized SBOM sharing but lack mechanisms for confidentiality or verifiable claims. Recent research explores blockchain-based SBOM management and selective disclosure. Xia et al. [12] propose a credential-based architecture for SBOM sharing, identifying zero-knowledge proofs as a potential mechanism for need-toknow disclosure, but do not implement scalable proof generation. Song et al. [9] introduce BC-SBOM, which stores SBOM data on-chain to improve availability, at the cost of confidentiality. CredChain [7] enables selective disclosure using verifiable credentials, but does not support proving the absence of components. In contrast, TrustBOM enables verifiable compliance without disclosure by using zero-knowledge non-membership proofs. Its two-phase architecture decouples SBOM commitment from verification, allowing providers to generate proofs for evolving policy constraints without revealing dependency information. To our knowledge, this is the first system to integrate non-membership proofs into enterprise CI/CD workflows with demonstrated constraint-linear scalability.

4

TrustBOM Architecture

This section presents the TrustBOM architecture, which enables confidentialitypreserving SBOMs with verifiable compliance across organizations. The design resolves the tension between protecting proprietary dependency information and providing cryptographic assurances about software composition. TrustBOM follows a two-phase architecture that decouples SBOM commitment from compliance verification. This separation allows software providers to capture the software state once during the build process and subsequently generate proofs for evolving policy constraints without rebuilding artifacts. Figure 1 illustrates the high-level architecture, which coordinates interactions between a software provider, a consumer, and a public blockchain. The system operates in two phases, separating software build and commitment from the generation of non-membership proofs for consumer-defined policy constraints. In the first phase, the provider’s CI pipeline builds the software artifact, generates an SBOM, and encodes it as a Sparse Merkle Tree (SMT). The root hash 8 9

https://sbom.sh/, [Accessed: 6 Feb. 2026] https://github.com/CycloneDX/cyclonedx-bom-repo-server, [Accessed: 6 Feb. 2026]

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

5

Fig. 1. High-Level System Architecture

of this tree is committed to a public blockchain, establishing a cryptographic commitment to the software’s dependency structure while preserving confidentiality. In the second phase, executed on demand by consumers, a consumer requests a zero-knowledge proof (ZKP) of non-membership with respect to specific policy constraints (e.g., known CVEs, restricted licenses, or organizationally prohibited components). The consumer verifies the proof locally, ensuring both its correctness and its consistency with the on-chain commitment and the specified policy constraints. The architecture is guided by the following design principles: 1. Decoupling: The architecture separates software build and commitment from compliance verification. The provider captures the software state once, enabling subsequent queries related to newly disclosed vulnerabilities or evolving license constraints to be resolved without rebuilding artifacts. This supports individualized assurances for consumers with distinct policy requirements. 2. Confidentiality: The provider can demonstrate the absence of specific policy violations without disclosing the full SBOM or the complete dependency graph. 3. On-demand Efficiency: Proofs are generated only when required, ensuring that computational resources are utilized only when verification is required. 4. Distributed Disclosure Control: Each consumer receives a proof tailored to their specific policy constraints. As a result, disclosed information is partitioned across independent consumers, preventing any single party from reconstructing the full dependency graph. 5. Integration Simplicity: The commitment and proving infrastructure are established once per organization. The CI/CD workflow remains generic and reusable across projects, thereby minimizing integration effort and adoption overhead.

6

V. T. Nguyen et al.

4.1

Threat Model

We consider a threat model in which the software provider acts as a potentially malicious prover that may attempt to generate invalid proofs to conceal the presence of policy-violating dependencies. Consumers are modeled as honest verifiers who correctly follow the verification protocol and seek only to validate compliance with specified policy constraints, without attempting to infer additional information about the SBOM. The adversary is assumed to have full control over the provider-side infrastructure, including the proving system and request handling logic, but cannot break standard cryptographic assumptions or tamper with the underlying blockchain. We make the following assumptions: – Blockchain Integrity: The public blockchain provides an immutable and publicly auditable ledger. Once commitments are recorded, they cannot be altered or removed. – Cryptographic Primitives: The employed hash function (SHA-256) is collisionresistant, and the zk-STARK construction provides computational soundness. – CI Pipeline Integrity: The provider’s CI pipeline correctly transforms the build artifact into its corresponding SMT representation. This assumption is supported through periodic audits (Section 5.1). Under these assumptions, the system satisfies the standard properties of zeroknowledge proofs: (1) Completeness: An honest provider can generate a valid proof that correctly attests compliance with the consumer’s policy constraints. (2) Soundness: A malicious provider cannot produce a valid proof asserting compliance Compliant = True if the SBOM contains dependencies that violate the specified policy constraints. (3) Zero-Knowledge: The proof reveals only the compliance outcome with respect to the queried policy constraints and does not disclose any additional information about the SBOM. In addition, TrustBOM provides non-repudiation, as blockchain-based commitments prevent providers from retroactively altering or denying prior claims. The model does not protect against information leakage through repeated queries or side-channel observations, which are addressed as deployment considerations in (section 7.1).

5

Implementation

This section describes the implementation of TrustBOM across the provider’s CI pipeline, the proving system, and the consumer-side verification process. The implementation10 and documentation11 are publicly available and open-source.

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

7

Fig. 2. Detailed TrustBOM Architecture | Dashed arrows for consumer initiated requests. All other arrows are for automated interactions

5.1

Provider CI Pipeline

The commitment phase is executed within the provider’s CI pipeline (fig. 2) and establishes the cryptographic foundation for subsequent proofs. For each release, the pipeline builds the software artifact and generates an SBOM using CycloneDX-compatible tooling. Build provenance is attested using SLSA12 , binding the SBOM to the corresponding build process. To enable efficient non-membership proofs, the SBOM is deterministically transformed into a Sparse Merkle Tree (SMT) of depth 256 using a versioned, open-source CLI tool. Each dependency is represented by its PURL, hashed via SHA-256 to determine the leaf index. Presence is encoded by setting the corresponding leaf to 1, while all other leaves remain 0. This mapping supports fixed-size indexing for variable-length identifiers and accommodates extended identifiers such as dependency–license combinations. The cleartext SBOM and SMT are stored off-chain within the provider’s infrastructure. To bind these artifacts, the CI pipeline computes hashes of the source code, container image, and SBOM, and records them together with the SMT root on a public blockchain. This creates an immutable mapping between the software artifact and its committed dependency structure. Since the SBOM-to-SMT transformation is performed off-chain, correctness relies on the CI Pipeline Integrity assumption (section 4.1), which is validated through periodic audits. These audits verify that the SMT accurately reflects the built artifact and are required only per pipeline version rather than per proof. 10

https://github.com/tuberlin-blockchain-prototyping https://tuberlin-blockchain-prototyping.github.io/trustbom-docs 12 https://slsa.dev/, [Accessed: 26 Jan. 2026] 11

8

V. T. Nguyen et al.

5.2

Software Provider Proving System

Once the software state is committed on-chain, the proving system handles consumer requests for compliance verification (fig. 2). The system is implemented as a microservice architecture hosted by the provider, ensuring that sensitive data remains internal. Upon receiving a request containing an SMT root and a set of policy constraints (e.g., PURLs or license identifiers), the workflow proceeds as follows: 1. The Orchestrator Service retrieves the corresponding Sparse Merkle Tree (SMT) and invokes the Merkle Proof Service. 2. The Merkle Proof Service generates Merkle non-membership proofs for each constraint. Proofs are compressed using a bitmap that encodes empty subtrees, allowing default hashes to replace omitted siblings and reducing data size. 3. The Orchestrator submits the SMT root (public input) and compressed proofs (private inputs) to the Proving Service, which executes verification logic within a RISC Zero zkVM and generates a zero-knowledge proof. 4. Finally, the resulting proof artifact is stored via an IPFS Service, and its content identifier is anchored on-chain to provide a tamper-evident audit record. Algorithm 1: Compressed Non-Membership Verification Input: Proofs P, PublicInput Rootin Output: Commitment {Rootout , Hbanned , Compliant} 1 Hbanned ← SHA256({p.purl | p ∈ P}) 2 foreach proof ∈ P do 3 if proof.value ̸= ”0” then 4 return Commit(Rootin , Hbanned , False) 5 end 6 Leaf Index ← ParseHex(proof.leaf _index) 7 if Leaf Index ̸= SHA256(proof.purl) then 8 return Commit(Rootin , Hbanned , False) 9 end 10 Current ← Hash(proof.value) 11 Bitmap ← ParseHex(proof.bitmap) 12 SibP tr ← 0 13 for d ← 0 to 255 do 14 if BitAt(Bitmap, d) == 1 then 15 Sibling ← ParseHex(proof.siblings[SibP tr]) 16 SibP tr ← SibP tr + 1 17 else 18 Sibling ← DEF AU LT S[d] 19 end 20 if BitAt(Leaf Index, d) == 0 then 21 Current ← Hash(Current, Sibling) 22 else 23 Current ← Hash(Sibling, Current) 24 end 25 end 26 if Current ̸= Rootin then 27 return Commit(Rootin , Hbanned , False) 28 end 29 end 30 return Commit(Rootin , Hbanned , True)

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

9

Algorithm Overview: The algorithm 1 iterates over each non-membership proof, performing three checks: (1) the leaf value is zero (dependency absent), (2) the leaf index matches the SHA-256 hash of the queried PURL, and (3) the Merkle path reconstructs to the committed root. The bitmap compression allows skipping empty subtrees by substituting precomputed default hashes. ZK Circuit Logic: The zkVM guest code (Algorithm 1) verifies each nonmembership proof by checking (i) absence at the leaf, (ii) correctness of the leaf index derived from the PURL, and (iii) consistency of the reconstructed Merkle path with the committed root. Bitmap-based compression reduces proof size by omitting empty subtrees. The circuit aggregates all verified constraints and commits both the SMT root and a hash of the queried constraints to the public output. This ensures that the generated proof attests to the exact policy constraints requested, while enabling efficient batch verification within a single proof. This logic ensures that a valid proof serves as a guarantee that the exact policy constraints requested were checked. Consequently, this allows our system to create a Zero-Knowledge Proof (ZKP) over the correct verification of Merkle proofs and still provide the same assurances as iteratively proving nonmembership of policy constraints in a SBOM, effectively shifting complex logic outside the Zero-Knowledge Virtual Machine (zkVM) without sacrificing any trust guarantees. The use of RISC Zero’s pre-compiles for SHA-256 accelerates the verification further, since the majority of computation tasks during the ZKP generation are hash operations. 5.3

Consumer Verification

Consumer-side verification is performed locally to avoid reliance on the provider. The verification process consists of three steps: 1. The consumer uses a RISC Zero verifier to validate the proof and confirm it was generated by the expected guest code via its ImageID13 . 2. The SMTRoot included in the proof is checked against the corresponding blockchain commitment. 3. The consumer recomputes the hash of the requested policy constraints and verifies it matches the value included in the proof output. Together, these checks ensure that the software satisfies the specified policy constraints without revealing the underlying SBOM. In summary, TrustBOM enables confidentiality-preserving compliance verification by decoupling artifact commitment from proof generation. Consumers obtain cryptographic assurances tailored to their policy constraints, while providers retain full control over their dependency information. 13

https://dev.risczero.com/terminology#image-id, [Accessed: 2 Feb. 2026]

10

V. T. Nguyen et al.

6

Evaluation

TrustBOM relies on zero-knowledge proofs to provide confidentiality-preserving SBOM-based compliance; however, such proofs introduce computational overhead. This evaluation examines whether TrustBOM can support enterprise-scale software delivery by analyzing the scalability and cost of proof generation. Specifically, we investigate whether proof generation scales predictably with the number of policy constraints, whether latency remains compatible with enterprise workflows, and whether the associated costs are economically feasible for realworld deployment. 6.1

Methodology

In TrustBOM, a proof constitutes a cryptographic attestation that a given SBOM satisfies a set of consumer-defined policy constraints without revealing its contents. The computational cost of proof generation increases with the number of constraints to be verified. Preliminary benchmarking identifies the Proving Service as the dominant contributor to overall resource consumption, with all other system components incurring negligible overhead. Consequently, the evaluation focuses on proof generation performance, analyzing its behavior as the number of policy constraints increases. We measure three primary metrics as functions of policy constraint count (the number of policy constraints verified per proof request, serving as the independent variable): proving time (the total time required to generate a verifiable proof), proof size (the file size of the generated ZKP), and computational cycles (the number of zkVM execution cycles). Proving time directly affects the latency experienced by consumers waiting for attestation results, and therefore determines whether TrustBOM can fit within the time constraints of enterprise software delivery pipelines. Proof size affects transmission and storage costs relevant for providers. Computational cycles serve as a hardware-agnostic measure of circuit complexity, reflecting the underlying cost of the zkVM execution independent of the machine it runs on. This setup isolates proof generation as the dominant cost factor, allowing us to evaluate the scalability of the core cryptographic mechanism independent of auxiliary system components. 6.2

Experiment Setup

Table 1 summarizes the experimental configuration. The hardware utilized has GPU acceleration and is accessible on all major cloud platforms. We use a real-world SBOM generated from a production application from German software company adesso SE14 in CycloneDX format. The policy constraints comprise 200 vulnerable Maven packages, including Log4Shell-affected 14

https://www.adesso.de/en/, [Accessed: 2 Feb. 2026]

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

11

Table 1. Experimental Configuration Component Specification Processor AMD EPYC 8224P (24-Core, 48 threads) GPU NVIDIA L4 (23 GB VRAM) Memory 188 GB RAM Operating System Ubuntu 22.04.5 LTS RISC Zero zkVM Version 3.0 with CUDA acceleration CUDA Version 12.8

versions (log4j-core, log4j-api), Jackson databind, Apache Commons, Spring Framework, Struts, and Tomcat. Note that the specific PURLs used do not affect performance. 6.3

Experiment Protocol

The benchmark measures ZKP generation performance as a function of the number of non-membership proofs verified. Proofs are generated across seven experiments workloads of increasing constraint count: N ∈ {2, 5, 10, 20, 50, 100, 200}. For each experiment, the first N constraints are drawn from the reference set of 200, so that smaller experiments are strict subsets of larger ones. This ensures comparability across runs. Merkle non-membership proofs are pre-computed for all 200 constraints against the SBOM’s sparse Merkle tree before benchmarking begins, isolating zero-knowledge proof generation as the variable under measurement. The Proving Service receives a batch of N Merkle non-membership proofs along with the tree root and generates a single ZKP attesting to the validity of all proofs. Each proof demonstrates that a specific policy constraint (package identifier) does not exist in the SBOM’s Merkle tree. The Proving Service executes the verification logic and produces a cryptographic receipt that can be independently verified. For each workload N , measurements are repeated ten times to account for variance. This yields 70 experimental runs (7 workload × 10 repetitions). We report mean values with min-max ranges for all three metrics. 6.4

Results

Figure 3 presents the benchmark results across three metrics: proving time, proof size, and computational cycles. All three metrics exhibit linear scaling with the number of policy constraints verified. Proving time increases from 2.4 seconds for 2 policy constraints to 178.9 seconds for 200 policy constraints, yielding approximately 0.9 seconds per policy constraint. Proof size scales from 0.28 MB to 21.4 MB, corresponding to roughly 0.1 MB per policy constraint. Computational cycles range from 1.0 million to 78.9 million, maintaining a consistent ratio of approximately 0.4 million cycles per policy constraint. The tight min-max bands visible in the figure indicate

12

V. T. Nguyen et al.

Fig. 3. Proof generation performance relative to policy constraint count, across 10 experiment runs. Note: error bands are present but largely obscured by the mean line due to low variance

low variance across runs (standard deviation below 1%), demonstrating highly reproducible performance. The linear scaling demonstrates that the Proving Service performs constant work per Merkle non-membership proof verification. This predictable relationship enables resource estimation for arbitrary policy constraint counts: verifying N constraints requires approximately 0.9N seconds and produces a proof of 0.1N MB. Utilizing Merkle Proofs also ensures that proving time is independent from the number of entries in the original SBOM. This confirms that the computational cost of TrustBOM is determined by the number of policy constraints rather than the size or complexity of the underlying SBOM, validating the architectural design principle of constraint-linear verification. These results confirm that TrustBOM is practical for production deployment. Verifying 200 policy constraints completes in under three minutes on an NVIDIA L4, available at approximately $0.70/hour15 on major cloud platforms. The linear scaling ensures that larger policy constraint sets remain tractable, and the low variance guarantees predictable execution times for integration into automated pipelines. In contrast to approaches that require full SBOM disclosure or repeated vulnerability scanning, TrustBOM enables targeted verification with predictable, constraint-linear cost. 6.5

Discussion

To contextualize these results against real-world vulnerability databases, we estimate proof generation times for full ecosystem coverage using data from Google’s OSV.dev16 . For the Maven ecosystem, which includes 6,125 known vulnerable packages, proving non-membership for all entries would require approximately 92 minutes at an estimated cost of $1.07. For PyPI, with 17,594 vulnerabilities, proof generation would complete in approximately 4.4 hours ($3.08). Even for the npm ecosystem, which includes 214,233 vulnerabilities, full coverage remains tractable at approximately 53 hours ($37.49). 15 16

https://modal.com/blog/nvidia-l4-price-article, [Accessed: 2 Feb. 2026] https://osv.dev/list, [Accessed: 26 Jan. 2026]

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

13

These results represent a worst-case upper bound in which proof generation covers all known vulnerabilities within an entire ecosystem. In practice, enterprise policies are typically defined over specific subsets of constraints, such as critical vulnerabilities, restricted licenses, or organizationally prohibited components, resulting in substantially lower proof generation times. Moreover, due to the decoupled architecture of TrustBOM, proof generation is performed independently of the software build process and can be executed on demand or within external verification workflows. As a result, proof generation does not impact build latency and can be scheduled according to application-specific performance requirements. Overall, these estimates indicate that comprehensive vulnerability attestation across entire ecosystems is economically feasible, while typical usage scenarios incur significantly lower computational cost. Organizations with stricter latency requirements can further reduce proving time by leveraging high-performance hardware, such as NVIDIA A100 or H100 GPUs. Blockchain transaction costs are negligible compared to proof generation costs. The smart contract stores only constant-size commitments per transaction, independent of SBOM size. Under current market conditions (ETH: $3,081; gas price: 0.051 gwei)17 , registering an SMT root costs approximately $0.03, while recording a compliance proof costs $0.04, resulting in a total cost of $0.07 per complete verification cycle on Ethereum Layer 1. These costs remain constant regardless of whether the SMT contains tens or thousands of dependencies. Furthermore, in light of the blockchain trilemma balancing decentralization, security, and scalability, organizations can further reduce transaction costs by deploying the system on alternative blockchains or Layer 2 solutions optimized for lower fees. This demonstrates that TrustBOM supports both interactive verification for targeted policy checks and batch-oriented compliance workflows at ecosystem scale.

7

Conclusion

This paper introduced TrustBOM, a confidentiality-preserving SBOM architecture for verifiable compliance across organizations. It enables software providers to attest to the absence of specific vulnerabilities or restricted licenses for different consumers, while fully concealing proprietary dependency graphs. By decoupling disclosure from assurance, TrustBOM transforms compliance verification into a constraint-linear process whose cost depends on the number of policy constraints rather than the size of the SBOM. The resulting commitments serve as durable, tamper-evident audit artifacts aligned with enterprise platform engineering and long-term governance requirements. Our evaluation demonstrates the practical feasibility of this approach in production environments. Proof generation scales linearly at approximately 0.9 seconds per policy constraint on commodity hardware (NVIDIA L4), with pre17

https://etherscan.io/, [Accessed: 14 Dec. 2025]

14

V. T. Nguyen et al.

dictable resource consumption that supports capacity planning in DevSecOps workflows. Even ecosystem-wide vulnerability attestation remains economically feasible: verifying the absence of all known Maven vulnerabilities, for example, incurs a cost of approximately $1.07. These results indicate that TrustBOM provides a cost-efficient and scalable mechanism for confidentiality-preserving SBOMs with verifiable compliance across software supply chains, addressing key barriers that have so far limited the adoption of SBOMs in cross-organizational settings. By decoupling disclosure from verification, TrustBOM demonstrates that strong confidentiality guarantees and practical supply chain assurance are not inherently conflicting, but can be achieved simultaneously within enterprise architectures.

7.1

Limitations

Several limitations warrant discussion. First, the proposed approach inherits the fundamental limitations of SBOMs themselves. The system assumes a complete and accurate SBOM representation of the software; however, if SBOM generation tools fail to capture transitive dependencies or misidentify component versions [13], the resulting guarantees apply only to this incomplete or incorrect representation. Improving SBOM fidelity remains an orthogonal challenge that is not addressed by our architecture. Second, the security guarantees depend on the correctness of the underlying cryptographic implementation. While we rely on RISC Zero, a mature and actively audited platform, vulnerabilities in the zkVM can compromise soundness properties. For example, CVE-2025-6158818 exposed a critical flaw in RISC Zero’s sys_read system call that allowed arbitrary code execution within the guest, enabling malicious hosts to forge proofs for invalid computations. Such vulnerabilities underscore that cryptographic guarantees are contingent on implementation correctness; production deployments must track security advisories and maintain updated dependencies. Third, the system cannot verify that the provided software corresponds to the software committed in the SMT. A malicious provider could generate a valid commitment, pass all compliance checks, and subsequently deploy different software. While periodic CI pipeline audits mitigate this risk, they cannot provide continuous assurance. Even with auditor access, verifying runtime deployment fidelity in cloud environments remains challenging. Finally, the proof-request interface introduces potential information leakage vectors. An adversarial consumer could submit excessive proof requests to incrementally reconstruct the SBOM through repeated non-membership queries. Production deployments may implement rate limiting, request authentication, anomaly detection, or a human-in-the-loop to prevent such reverse-engineering attacks. Additionally, proof responses should incorporate configurable delays to prevent timing-based attacks that could exploit response latency variations. 18

https://nvd.nist.gov/vuln/detail/CVE-2025-61588, [Accessed: 12 Feb. 2026]

TrustBOM: Confidentiality-Preserving SBOMs Across Organizations

7.2

15

Future Work

Several directions merit further investigation. First, extending the system to support membership proofs would enable positive attestations such as license compliance verification. This can be achieved using the same SMT representation and Merkle proof construction, requiring only modifications to the constraint logic in the proving service. Second, recursive proof aggregation19 could enable compliance dashboards that verify multiple releases with a single proof, reducing verification overhead. Third, bridging the gap between committed artifacts and runtime deployment could leverage confidential computing. If providers deploy within trusted execution environments (TEEs) supporting remote attestation, consumers could obtain hardware-signed evidence of which binary is running. Aligning TEE measurements with the artifact hashes committed on-chain would require careful design of the deployment pipeline, but could extend cryptographic assurance from CI commitment through to runtime. More broadly, integrating build-time integrity guarantees with post-build compliance verification represents a promising direction. Approaches based on deterministic builds and TEE-based attestation can provide verifiable evidence of artifact provenance within CI pipelines [1], while TrustBOM enables confidentiality-preserving verification of software composition after artifact generation. Combining these techniques could enable end-to-end verifiable supply chains spanning build, distribution, and deployment. Finally, extending the architecture to multi-provider supply chains (beyond the single-provider setting considered in this work), where sub-providers also issue cryptographic commitments for their components, would enable end-to-end supply chain verification while preserving confidentiality at each tier. Frameworks such as the Trusted Compute Unit (TCU) [2] provide a foundation for this setting, supporting interoperable proofs across heterogeneous technologies (TEEs and zkVMs) with blockchain-based traceability. As regulatory frameworks increasingly mandate software supply chain accountability, architectures that balance compliance requirements with confidentiality concerns are becoming essential. TrustBOM demonstrates that zero-knowledge proofs provide a practical foundation for this balance, enabling verifiable supply chain assurance without compromising proprietary information.

References 1. Castillo, F., Brito, E., Pullonen-Raudvere, P., Werner, S., Tai, S.: An evidencedriven protocol for trustworthy ci pipelines. In: 30th International Conference on Enterprise Design, Operations, and Computing (EDOC) (2026) 2. Castillo, F., Heiss, J., Werner, S., Tai, S.: Trusted compute units: A framework for chained verifiable computations. In: 2025 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). pp. 1–9 (2025). https://doi.org/10.1 109/ICBC64466.2025.11114627 19

https://risczero.com/blog/proof-composition, [Accessed: 26 Jan. 2026]

16

V. T. Nguyen et al.

3. Dahlberg, R., Pulls, T., Peeters, R.: Efficient sparse merkle trees. In: Brumley, B.B., Röning, J. (eds.) Secure IT Systems. pp. 199–215. Springer International Publishing, Cham (2016) 4. Eberhardt, J., Tai, S.: Zokrates - scalable privacy-preserving off-chain computations. In: 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). pp. 1084–1091 (2018). https://doi.org/10.1109/Cybermatics_2018.2018.00199 5. Goldwasser, S., Micali, S., Rackoff, C.: The knowledge complexity of interactive proof systems. SIAM Journal on Computing 18(1), 186–208 (1989). https://do i.org/10.1137/0218012 6. Group, F.W.: Framing software component transparency: Establishing a common software bill of material (sbom). Tech. rep., NTIA (2019), https://www.ntia.gov /files/ntia/publications/framingsbom_20191112.pdf 7. Mukta, R., Martens, J., Paik, H.y., Lu, Q., Kanhere, S.S.: Blockchain-based verifiable credential sharing with selective disclosure. In: 2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). pp. 959–966 (2020). https://doi.org/10.1109/TrustCom50675.20 20.00128 8. National Telecommunications and Information Administration: The minimum elements for a software bill of materials (sbom). Tech. rep., U.S. Department of Commerce (July 2021), https://www.ntia.gov/files/ntia/publications/sbo m_minimum_elements_report.pdf 9. Song, A., Seo, E., Kim, H.: Bc-sbom: Blockchain-based sbom management system. In: 2025 27th International Conference on Advanced Communications Technology (ICACT). pp. 169–174 (2025). https://doi.org/10.23919/ICACT63878.2025.1 0936765 10. Williams, L., Benedetti, G., Hamer, S., Paramitha, R., Rahman, I., Tamanna, M., Tystahl, G., Zahan, N., Morrison, P., Acar, Y., Cukier, M., Kästner, C., Kapravelos, A., Wermke, D., Enck, W.: Research directions in software supply chain security. ACM Trans. Softw. Eng. Methodol. 34(5), 146:1–146:38 (May 2025). https://do i.org/10.1145/3714464 11. Xia, B., Bi, T., Xing, Z., Lu, Q., Zhu, L.: An empirical study on software bill of materials: Where we stand and the road ahead. In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). pp. 2630–2642 (2023). https://doi.org/10.1109/ICSE48619.2023.00219 12. Xia, B., Zhang, D., Liu, Y., Lu, Q., Xing, Z., Zhu, L.: Trust in software supply chains: Blockchain-enabled sbom and the aibom future. In: Proceedings of the 2024 ACM/IEEE 4th International Workshop on Engineering and Cybersecurity of Critical Systems (EnCyCriS) and 2024 IEEE/ACM Second International Workshop on Software Vulnerability. pp. 12–19. EnCyCriS/SVM ’24, Association for Computing Machinery, New York, NY, USA (2024). https://doi.org/10.1145/ 3643662.3643957 13. Yu, S., Song, W., Hu, X., Yin, H.: On the correctness of metadata-based sbom generation: A differential analysis approach. In: 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). p. 29–36 (2024). https://doi.org/10.1109/DSN58291.2024.00018