pith. sign in

arxiv: 2605.00076 · v1 · submitted 2026-04-30 · 💻 cs.CR · cs.SE

zkSBOM: Privacy-Preserving SBOM Sharing with Zero-Knowledge Sets

Pith reviewed 2026-05-09 20:48 UTC · model grok-4.3

classification 💻 cs.CR cs.SE
keywords software bill of materialszero-knowledge setsprivacy-preserving sharingcryptographic commitmentsvulnerability verificationsupply chain securityinclusion proofs
0
0 comments X

The pith

Zero-knowledge sets let consumers verify specific SBOM vulnerabilities through cryptographic proofs without revealing other components.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes a mechanism for sharing Software Bills of Materials that avoids full disclosure or total opacity. It uses zero-knowledge sets to create a cryptographic commitment to the list of components in an SBOM. Consumers can then issue targeted queries about known vulnerabilities and receive proofs confirming inclusion or exclusion. This binding prevents suppliers from altering or misrepresenting the SBOM after commitment while limiting what consumers learn to only the queried facts. The work quantifies the information leakage from these proofs and evaluates performance on realistic SBOM sizes to show operational feasibility.

Core claim

The paper claims that zero-knowledge sets provide a cryptographic commitment to SBOM components such that inclusion and exclusion proofs for specific items can be generated and verified. Consumers thereby determine whether a particular vulnerable component is present without learning any other contents, and suppliers cannot change the committed list after the fact. The mechanism operates by having the supplier publish the commitment, after which consumers submit queries and obtain short proofs that reveal only the answer to the query.

What carries the argument

Zero-knowledge sets, cryptographic structures that commit to a collection of elements and allow proofs of membership or non-membership for individual elements without exposing the rest of the collection.

If this is right

  • Suppliers can publish a single commitment that supports multiple independent queries over time without additional disclosure.
  • Consumers obtain cryptographic assurance that a queried component is or is not present, reducing the chance of being misled by a modified SBOM.
  • The quantified leakage analysis provides a concrete bound that can be checked against regulatory or threat-model requirements.
  • The evaluation on realistic scenarios indicates that the computational cost stays within practical bounds for typical software supply-chain sizes.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Adoption could lower barriers to mandatory SBOM sharing by addressing mutual distrust between suppliers and consumers.
  • The same commitment structure could support queries about other attributes such as license compliance without full exposure.
  • If proof sizes and verification times decrease with future zero-knowledge techniques, the approach would become viable for even larger SBOMs or real-time checks.
  • Integration with public vulnerability databases would allow automated, privacy-preserving scans without centralizing full SBOM data.

Load-bearing premise

The security and privacy rest on the premise that any information revealed by the structure of the inclusion and exclusion proofs remains too limited to enable practical attacks on the remaining SBOM contents.

What would settle it

An experiment showing that an adversary can extract additional component identities from a sequence of inclusion and exclusion proofs beyond the quantified leakage bound, or a measurement demonstrating that proof generation and verification times exceed acceptable limits for SBOMs containing several thousand entries, would falsify the practical claims.

Figures

Figures reproduced from arXiv: 2605.00076 by Aman Sharma, Eric Cornelissen, Javier Ron, Martin Monperrus, Musard Balliu, Tom Sorger.

Figure 1
Figure 1. Figure 1: Overview of the problem statement. Definition 1. Let 𝐻 be a cryptographic hash function that maps variable-length input to fixed-length output. We de￾note this operation as ℎ ← 𝐻(𝑚). The function 𝐻 must be cryptographically secure, namely collision-, preimage-, and second preimage-resistant. Definition 2. Let 𝐷𝑆 be a digital signature scheme that consists of algorithms 𝐷𝑆.KeyGen, 𝐷𝑆.Sign, and 𝐷𝑆.Verify: (𝑝… view at source ↗
Figure 2
Figure 2. Figure 2 [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: RQ2: Performance analysis of zkSBOM. All graphs show our measurements for both inclusion and non-inclusion proof. (a) Commitment creation time (box (1) in [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗
read the original abstract

Software Bills of Materials (SBOMs) are increasingly mandated by regulators, yet existing sharing mechanisms impose a binary choice between full disclosure and full opacity. This exposes software suppliers to attacks that can be deduced from the SBOM only, such as the presence of a vulnerable dependency. Conversely, software consumers can be fooled by software suppliers who modify or misrepresent published SBOMs. We present zkSBOM, a privacy-preserving SBOM sharing mechanism designed to address these threats. zkSBOM uses zero-knowledge sets to cryptographically commit to the components within an SBOM. Software consumers can query for known vulnerabilities and receive a cryptographic proof confirming whether the artifact described by the SBOM is affected, without revealing any additional SBOM content. We conduct a security analysis of zkSBOM by quantifying expected leakage from inclusion and exclusion proofs. We demonstrate real-world feasibility by applying it to realistic scenarios and evaluating its operation requirements. Our evaluation demonstrates that zkSBOM is a strong, secure, and privacy-preserving mechanism for SBOM sharing, protecting software suppliers and software consumers from one another.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript introduces zkSBOM, a privacy-preserving mechanism for sharing Software Bills of Materials (SBOMs) that uses zero-knowledge sets to cryptographically commit to SBOM components. Consumers can issue queries about known vulnerabilities and receive inclusion or exclusion proofs confirming whether the artifact is affected, without revealing any other SBOM content. The work includes a security analysis that quantifies expected leakage from these proofs and a feasibility evaluation on realistic SBOM scenarios, concluding that zkSBOM is a strong, secure, and privacy-preserving solution protecting both suppliers and consumers.

Significance. If the privacy and security claims can be substantiated, the result would address a practical tension in software supply-chain security between regulatory SBOM mandates and the need to limit exposure of proprietary dependency information. The application of zero-knowledge sets to this domain is a natural and timely idea, and the reported feasibility evaluation on realistic scenarios provides initial evidence of practicality that could support adoption in compliance contexts.

major comments (2)
  1. [Security Analysis] Security Analysis section: the quantification of expected leakage from inclusion and exclusion proofs is presented as heuristic expected-value calculations without a formal game-based privacy definition or reduction to a standard assumption (e.g., zero-knowledge property of the underlying set or collision resistance of the commitment). This is load-bearing for the central claim that zkSBOM is 'strong, secure, and privacy-preserving' against a malicious consumer issuing adaptive queries.
  2. [Feasibility Evaluation] Feasibility Evaluation section: the evaluation does not report concrete proof sizes, computation costs, or whether the zero-knowledge set construction requires a trusted setup, nor does it address potential side-channel leakage outside the quantified bounds; these details are necessary to assess whether the mechanism remains practical and private for typical SBOM sizes (hundreds of components).
minor comments (1)
  1. [Abstract] Abstract: the concluding sentence asserts that the evaluation 'demonstrates that zkSBOM is a strong, secure, and privacy-preserving mechanism' without qualification; this phrasing should be softened to reflect that the security analysis remains informal.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive and detailed review. We address each major comment below and indicate the revisions planned for the manuscript.

read point-by-point responses
  1. Referee: [Security Analysis] Security Analysis section: the quantification of expected leakage from inclusion and exclusion proofs is presented as heuristic expected-value calculations without a formal game-based privacy definition or reduction to a standard assumption (e.g., zero-knowledge property of the underlying set or collision resistance of the commitment). This is load-bearing for the central claim that zkSBOM is 'strong, secure, and privacy-preserving' against a malicious consumer issuing adaptive queries.

    Authors: We agree that the current heuristic expected-value analysis, while grounded in the collision resistance and zero-knowledge properties of the set construction, would benefit from a formal treatment to fully substantiate the privacy claims under adaptive queries. In the revised manuscript we will introduce an explicit privacy game capturing a malicious consumer's adaptive queries and show that the adversary's view is simulatable given only the quantified leakage, with a direct reduction to the zero-knowledge property of the underlying set and the collision resistance of the commitment. This addition will strengthen the central security argument without altering the existing leakage quantification. revision: yes

  2. Referee: [Feasibility Evaluation] Feasibility Evaluation section: the evaluation does not report concrete proof sizes, computation costs, or whether the zero-knowledge set construction requires a trusted setup, nor does it address potential side-channel leakage outside the quantified bounds; these details are necessary to assess whether the mechanism remains practical and private for typical SBOM sizes (hundreds of components).

    Authors: We acknowledge that the feasibility section currently presents high-level operation requirements on realistic SBOM scenarios. In the revision we will add concrete measurements of proof sizes and computation costs for SBOMs with hundreds of components. We will also state the trusted-setup requirements (or lack thereof) of the specific zero-knowledge set construction employed and discuss side-channel considerations, explaining that any such leakage is either outside the threat model or bounded by the same cryptographic assumptions used for the quantified leakage. These concrete details will allow readers to better evaluate practicality. revision: yes

Circularity Check

0 steps flagged

No circularity detected; derivation relies on standard cryptographic primitives

full rationale

The paper constructs zkSBOM by applying zero-knowledge sets (a standard primitive) to commit to SBOM components and enable inclusion/exclusion proofs for vulnerability queries. The security analysis quantifies expected leakage from proofs but introduces no self-definitional equations, fitted parameters renamed as predictions, or load-bearing self-citations that reduce the central claim to its own inputs. No uniqueness theorems, ansatzes smuggled via citation, or renamings of known results appear in the provided text. The evaluation on realistic scenarios is empirical and independent of the construction itself, making the derivation self-contained against external cryptographic assumptions.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

Only abstract available; ledger therefore limited to standard cryptographic assumptions.

axioms (1)
  • domain assumption Zero-knowledge sets provide the stated privacy and soundness properties against the described leakage model.
    Invoked when the paper claims cryptographic proofs reveal only the queried answer.

pith-pipeline@v0.9.0 · 5501 in / 1088 out tokens · 25452 ms · 2026-05-09T20:48:00.482106+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

30 extracted references · 30 canonical work pages

  1. [1]

    [n. d.]. Ecosyste.ms: Packages API.https://packages.ecosyste.ms/docs/ index.html. Accessed: 2026-04-27

  2. [2]

    CVE-2021-44228.https://nvd.nist.gov/vuln/detail/CVE-2021- 44228Accessed: 2026-04-27

    2021. CVE-2021-44228.https://nvd.nist.gov/vuln/detail/CVE-2021- 44228Accessed: 2026-04-27

  3. [3]

    The System Package Data Exchange (SPDX).https://spdx.dev/ Accessed: 2026-04-27

    2021. The System Package Data Exchange (SPDX).https://spdx.dev/ Accessed: 2026-04-27

  4. [4]

    CycloneDX Bill of Materials Specification (ECMA- 424).https://ecma-international.org/publications-and-standards/ standards/ecma-424/Accessed: 2026-04-27

    2025. CycloneDX Bill of Materials Specification (ECMA- 424).https://ecma-international.org/publications-and-standards/ standards/ecma-424/Accessed: 2026-04-27

  5. [5]

    Software Identification (SWID) Tagging.https://csrc.nist.gov/ projects/software-identification-swidAccessed: 2026-04-27

    2026. Software Identification (SWID) Tagging.https://csrc.nist.gov/ projects/software-identification-swidAccessed: 2026-04-27

  6. [6]

    Apache Maven Project. 2026. Introduction to the Dependency Mecha- nism.https://maven.apache.org/guides/introduction/introduction- to-dependency-mechanism.html#dependency-scopeLast published: 2026-04-26

  7. [7]

    Musard Balliu, Benoit Baudry, Sofia Bobadilla, Mathias Ekstedt, Mar- tin Monperrus, Javier Ron Arteaga, Aman Sharma, Gabriel Skoglund, César Soto-Valero, and Martin Wittlinger. 2023. Challenges of Produc- ing Software Bill of Materials for Java.IEEE Secur. Priv.21, 6 (2023), 12–23

  8. [8]

    Gianpietro Castiglione, Shahriar Ebrahimi, and Narges Khakpour. 2026. VeriSBOM: Secure and Verifiable SBOM Sharing Via Zero-Knowledge Proofs.arXiv preprint arXiv:2602.13682(2026)

  9. [9]

    Cisco. 2026. SBOM Request Form Instructions.https://sec.cloudapps. cisco.com/security/center/resources/sbom-form-instructions. Cisco Security Center. Accessed 2026-04-28

  10. [10]

    Santiago Cuéllar, Bill Harris, James Parker, Stuart Pernsteiner, and Eran Tromer. 2023. Cheesecloth: Zero-Knowledge Proofs of Real World Vulnerabilities. In32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023, Joseph A. Calandrino and Carmela Troncoso (Eds.). USENIX Association, 6525–6540

  11. [11]

    Jiarou Deng, Yang Yang, and Michael Rushanan. 2025. The SBOM Transparency v. Exposure Dilemma: A Case Study on Adversarial Access to Public SBOMs in Healthcare. (2025).https: //michaelrushanan.org/publications/HealthSec25___Paper___The_ SBOM_Transparency_v__Exposure_Dilemma__A_Case_Study_on_ Adversarial_Access_to_Public_SBOMs_in_Healthcare.pdf

  12. [12]

    Jiarou Deng, Yang Yang, and Michael Rushanan. 2025. A Zero- Knowledge Framework for Confidential and Verifiable SBOM Validation. (2025).https://michaelrushanan.org/publications/ ACSAC25___Abstract___A_Zero_Knowledge_Framework_for_ Confidential_and_Verifiable_SBOM_Validation.pdf

  13. [13]

    2024.Reg- ulation (EU) 2024/2847 on Horizontal Cybersecurity Requirements for Products with Digital Elements (Cyber Resilience Act)

    European Parliament and Council of the European Union. 2024.Reg- ulation (EU) 2024/2847 on Horizontal Cybersecurity Requirements for Products with Digital Elements (Cyber Resilience Act). Technical Re- port 2024/2847. Official Journal of the European Union.https://eur- lex.europa.eu/eli/reg/2024/2847/oj/engEntered into force 10 Decem- ber 2024; full appli...

  14. [14]

    John Fueyo, Jacob Glad, Charlie Shaw, and Richard Zins. 2023. SBOM Escrow.https://cltc.berkeley.edu/publication/sbom-escrow/. Cen- ter for Long-Term Cybersecurity, University of California, Berkeley. Accessed 2026-04-28

  15. [15]

    Shafi Goldwasser, Silvio Micali, and Charles Rackoff. 1989. The Knowl- edge Complexity of Interactive Proof Systems.SIAM J. Comput.18, 1 (1989), 186–208

  16. [16]

    Shafi Goldwasser, Silvio Micali, and Ronald L Rivest. 1988. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on computing17, 2 (1988), 281–308

  17. [17]

    Daniel Hugenroth, Mario Lins, René Mayrhofer, and Alastair R Beres- ford. 2025. Attestable builds: compiling verifiable binaries on untrusted systems using trusted execution environments. InProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Secu- rity. 4514–4528

  18. [18]

    Melara, and Santiago Torres-Arias

    Eman Abu Ishgair, Chinenye Okafor, Marcela S. Melara, and Santiago Torres-Arias. 2025. Trustworthy and Confidential SBOM Exchange. CoRRabs/2509.13217 (2025). arXiv:2509.13217

  19. [19]

    JungA Kim, Yiseul Choi, and Seongmin Kim. 2025. Attestation-Based SBOM Integrity Verification for Secure and Transparent Software Supply Chains. In2025 25th Asia-Pacific Network Operations and Man- agement Symposium (APNOMS). 1–4

  20. [20]

    Silvio Micali, Michael Rabin, and Joe Kilian. 2003. Zero-Knowledge Sets. In44th Annual IEEE Symposium on Foundations of Computer Science (FOCS 2003). IEEE, 80–91

  21. [21]

    Microsoft. [n. d.]. Ordered Zero-Knowledge Set - oZKS.https://github. com/microsoft/oZKSAccessed: 2026-03-20

  22. [22]

    Daniel Morales, Isaac Agudo, and Javier López. 2023. Private Set Intersection: A Systematic Literature Review.Computer Science Review 49 (2023), 100567

  23. [23]

    NTIA Multistakeholder Process on Software Component Trans- parency, Framing Working Group. 2021. Framing Software Compo- nent Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition.https://www.ntia.gov/sites/default/files/ publications/ntia_sbom_framing_2nd_edition_20211021_0.pdf

  24. [24]

    NTIA Multistakeholder Process on Software Component Trans- parency, Framing Working Group. 2021. Sharing and Exchanging SBOMs.https://www.ntia.gov/sites/default/files/publications/ntia_ sbom_sharing_exchanging_sboms-10feb2021_0.pdf

  25. [25]

    PainChek. 2025. Software Bill of Materials (SBOM). https://support.painchek.com/hc/en-us/articles/12219044018959- Software-Bill-of-Materials-SBOM. PainChek Support. Published 2025-03-20. Accessed 2026-04-28

  26. [26]

    CHAINS Project. [n. d.]. zkSBOM.https://github.com/chains-project/ zkSBOMAccessed: 2026-04-29

  27. [27]

    Luís Soeiro, Thomas Robert, and Stefano Zacchiroli. 2025. Wild sboms: a large-scale dataset of software bills of materials from public code. In2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, 164–168

  28. [28]

    Alin Tomescu, Vivek Bhupatiraju, Dimitrios Papadopoulos, Charalam- pos Papamanthou, Nikos Triandopoulos, and Srinivas Devadas. 2019. Transparency Logs via Append-Only Authenticated Dictionaries. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Com- munications Security(London, United Kingdom)(CCS ’19). Association for Computing Machinery, ...

  29. [29]

    Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. 2019. in-toto: Providing farm-to- table guarantees for bits and bytes. In28th USENIX Security Symposium (USENIX Security 19). 1393–1410

  30. [30]

    Answer to RQ1

    Chuan Zhao, Shengnan Zhao, Minghao Zhao, Zhenxiang Chen, Chong- Zhi Gao, Hongwei Li, and Yu an Tan. 2019. Secure Multi-Party Com- putation: Theory, practice and applications.Information Sciences476 (2019), 357–372. A Open Science zkSBOMartifacts are open source under the MIT License and are available athttps://github.com/chains-project/zkSBOM. Sorger et a...