💻 computer science

VeriSBOM: Secure and Verifiable SBOM Sharing Via Zero-Knowledge Proofs

本文提出了 VeriSBOM，这是一个利用零知识证明、向量承诺和折叠聚合技术构建的信任less 框架，旨在实现软件物料清单（SBOM）的隐私保护与选择性披露，使第三方能够在不泄露敏感信息的前提下，独立验证软件依赖的真实性和合规性。

原作者： Gianpietro Castiglione, Shahriar Ebrahimi, Narges Khakpour

发布于 2026-02-17

📖 1 分钟阅读☕ 轻松阅读

原作者： Gianpietro Castiglione, Shahriar Ebrahimi, Narges Khakpour

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 VeriSBOM 的新系统，它的核心目的是解决软件供应链中的一个两难困境：如何既让软件使用者放心（证明软件是安全的），又不让软件开发者泄露商业机密（比如他们用了哪些特殊的内部组件）。

为了让你更容易理解，我们可以把软件供应链想象成一家高端餐厅的厨房，把 SBOM（软件物料清单） 想象成菜单。

1. 现在的困境：要么全裸，要么不信任

现状：以前，餐厅（软件公司）如果想证明自己的菜（软件）是安全的，必须把完整的菜单（SBOM）贴在大门口，上面写着所有食材（代码库）的来源、品牌，甚至是谁种的菜。
问题：
- 商业机密泄露：如果一家餐厅的招牌菜用了某种特殊的“秘制酱料”（专有依赖库），把完整菜单贴出来，竞争对手（黑客或商业对手）就能偷学配方，或者专门针对那个酱料里的漏洞进行攻击。
- 信任危机：如果餐厅只说“我的菜很安全”，但不给看菜单，顾客（用户）又不敢吃，怕里面有毒（漏洞）。

2. VeriSBOM 的解决方案：神奇的“魔法验货箱”

VeriSBOM 就像是一个带有魔法的验货箱，它利用了一种叫“零知识证明”（Zero-Knowledge Proofs）的数学黑科技。

核心比喻：两个“大账本”和“魔法印章”

想象一下，系统里有两个巨大的、公开的账本（由可信的第三方维护）：

食材账本（Package Tree）：记录了市场上所有合法、真实的食材（官方软件包）。
安检账本（Shadow Tree）：记录了哪些食材通过了“安检”（没有病毒、符合许可证规定）。

VeriSBOM 的工作流程是这样的：

厨师（开发者）做饭：厨师做了一道菜，但他不想把完整的食谱（SBOM）给客人看，因为里面有他的独家秘方。
厨师去“魔法验货”：厨师拿着他的食谱，去一个魔法验货箱（零知识证明系统）里操作。
- 他不需要把食谱拿出来。
- 魔法箱会检查：你的食材是不是在“食材账本”里？（证明来源真实）
- 魔法箱会检查：你的食材是不是在“安检账本”里？（证明没有病毒、合规）
生成“魔法印章”：如果检查都通过，魔法箱会吐出一张小小的、不可伪造的“魔法印章”（零知识证明）。
- 这张印章上没有任何文字，你看不出他用了什么食材。
- 但是，任何人只要拿着这个印章，去核对那两个公开的“大账本”，就能100% 确定：这道菜用的食材绝对是真实的，而且绝对通过了安检。

3. 这个系统解决了什么大问题？

保护秘密（隐私）：就像你不需要把秘方告诉客人，客人也能相信菜是安全的。竞争对手无法通过这张“魔法印章”反推出厨师用了什么特殊食材。
防止造假（安全）：如果厨师偷偷用了过期的、有毒的食材，或者用了没在“食材账本”里的黑市食材，他就造不出那个合法的“魔法印章”。因为印章是数学上锁死的，必须和公开账本对得上才行。
快速验证（效率）：以前验证一万个食材可能需要很久，现在用一种叫“折叠”（Folding）的技术，就像把一万张检查单折叠成一张小纸条，验证的人只需要花几毫秒就能看完。

4. 论文里的关键创新点（用大白话解释）

双重树结构（Dual-Tree）：
- 就像有两个独立的保安。一个保安只管“这东西是不是真的”（食材账本），另一个保安只管“这东西有没有毒”（安检账本）。这样分工明确，效率高，而且互不干扰。
折叠技术（Folding）：
- 想象你要证明你有一万个苹果都是好的。传统方法要一个个检查，累死人。VeriSBOM 的方法是：每检查一个苹果，就把结果“折叠”进上一个结果里。最后，你手里只拿着一个折叠好的小纸团，就能证明那一万个苹果全是好的。
动态更新：
- 如果“安检账本”里突然说某种苹果有毒了（新发现的漏洞），账本会更新。厨师如果还拿着旧的“魔法印章”来证明苹果是好的，客人一核对账本，发现印章对不上，立刻就会拒绝这道菜。

5. 总结

VeriSBOM 就像是在软件世界里建立了一套**“只验货，不看货”**的信任机制。

对开发者：你可以放心地保护你的核心代码和供应链细节，不用担心被抄袭或针对。
对用户/企业：你不需要懂技术，也不需要看到代码，只要看到那个“魔法印章”是有效的，就可以放心地下载和使用软件，因为数学保证了它绝对安全、合规。

这就好比你去买药，不需要知道药厂的具体配方（保护知识产权），但药瓶上有一个防伪二维码，扫一下就能证明这药确实是正规药厂生产的，且没有过期、没有变质。这就是 VeriSBOM 想要做到的事情。

以下是关于论文 VeriSBOM: Secure and Verifiable SBOM Sharing Via Zero-Knowledge Proofs 的详细技术总结：

1. 研究背景与问题 (Problem)

软件物料清单 (SBOM) 是软件供应链透明度的关键组件，列出了软件工件的所有组件、依赖项和元数据。然而，全面公开 SBOM 存在两大主要风险，导致许多组织不愿完全披露：

技术风险：暴露专有依赖项或未修复的漏洞，可能被攻击者利用。
商业风险：暴露架构策略，可能被竞争对手利用以绕过中间商或获取商业情报。

现有挑战 (C1 & C2)：

隐私与合规的矛盾 (C1)：现有的选择性披露方案（如基于属性的加密）通常需要解密数据才能验证，或者依赖复杂的密钥管理，无法在保护隐私的同时实现盲验证（Blind Verification）。
验证缺口 (C2)：如果只披露部分信息，发布者可能隐瞒漏洞依赖或篡改元数据。消费者需要一种机制，在不查看完整 SBOM 的情况下，通过密码学证明验证依赖项的真实性和策略合规性。

2. 方法论 (Methodology)

VeriSBOM 提出了一种无信任（Trustless）、选择性披露的 SBOM 共享框架，核心利用向量承诺 (Vector Commitments, VC) 和 零知识证明 (Zero-Knowledge Proofs, ZKPs) 技术。

核心架构：双树架构 (Dual-Tree Architecture)

系统维护两棵并行的、同构的 Merkle 树（向量承诺）：

包树 (Package Tree, $PT$)：由包管理器（Package Manager）维护。
- 功能：承诺依赖项的存在性和真实性。
- 叶子节点：存储每个包版本的哈希元数据。
- 作用：证明 SBOM 中的依赖项确实存在于官方仓库中（真实性证明 P1）。
影子树 (Shadow Tree, $ST$)：由独立审计员（Auditor）维护。
- 功能：承诺包对特定策略的合规性。
- 叶子节点：存储合规状态标志（1 表示合规，0 表示不合规）。
- 作用：证明依赖项满足安全策略（如无漏洞、许可证合规）（合规性证明 P2）。

关键技术组件

稀疏 Merkle 树：用于确定性的索引映射，确保包的位置不随仓库中其他包的增减而改变，保证路径的稳定性。
策略传播引擎 (Policy Propagation Engine, PPE)：审计员使用此引擎遍历依赖图，将底层依赖的合规状态（如漏洞）向上传播到父包。如果子依赖不合规，父包自动标记为不合规。
基于折叠的零知识证明 (Folding-based ZKPs)：
- 使用 Nova 折叠方案（Recursive Folding Scheme）。
- 原理：将针对每个依赖项的多个验证步骤（检查 $PT $和$ ST$ 中的存在性及合规性）递归地折叠（Fold）成一个常数大小的证明。
- 优势：无论 SBOM 包含多少个依赖项，生成的证明大小和验证时间保持恒定，解决了大规模系统的可扩展性问题。

工作流程

设置阶段：包管理器发布 $PT $的根哈希 ($ g_{PT} $)，审计员发布$ ST $的根哈希 ($ g_{ST}$)。
证明阶段：软件供应商（Prover）遍历 SBOM，针对每个依赖项生成包含 $PT $和$ ST$ 路径的 Merkle 路径证明。利用折叠方案将这些证明压缩为一个单一的、简洁的 ZK 证明 ( $\pi$ )。
验证阶段：消费者（Verifier）使用公开的 $g_{PT}$ 和 $g_{ST}$ 验证 $\pi$ 。验证通过意味着：所有依赖项均存在于官方仓库，且均符合审计策略，而无需知晓具体的依赖项名称或版本。

3. 主要贡献 (Key Contributions)

隐私保护的属性验证：提出了一种利用 ZKPs 共享 SBOM 的方法，允许客户端验证依赖项的策略合规性，同时完全不暴露敏感信息（如具体的私有依赖列表）。
安全性分析：在概率多项式时间 (PPT) 敌手模型下分析了系统安全性，证明了其能抵抗位置绑定攻击、并行树攻击（防止供应商伪造私有根节点）和重放攻击。
可扩展性：通过递归折叠方案（Folding Schemes）和策略引擎，实现了证明生成的线性扩展和验证的常数时间复杂度，能够处理包含数百万个包的大型生态系统。
原型实现与评估：构建了 VeriSBOM 原型，集成了 Rust (加密核心) 和 Python (策略引擎)，并在真实世界的包注册表（如 crates.io）上进行了评估。

4. 实验结果 (Results)

研究在 Intel i5 处理器和 16GB RAM 的机器上进行了评估，主要发现如下：

存储开销：
- 即使仓库包含 1000 万个包，向量承诺 (VC) 的额外存储开销也低于 1GB。
- 即使扩展到 1 亿个包，总开销也仅在 4GB 左右，现代基础设施完全可承受。
证明大小：
- 无论依赖项数量多少，生成的 ZK 证明大小保持恒定，约为 13 KB。
生成时间：
- 证明生成时间主要取决于依赖项的数量（线性增长），与仓库总大小关系不大。
- 对于包含 300 个依赖项的库，在 100 万包规模的系统中，生成时间约为几秒（例如 4 秒左右），具有实际可行性。
验证时间：
- 验证时间极快且恒定，约为 80-95 毫秒，不受包仓库规模或依赖项数量的影响。
互操作性：
- 系统成功在 Rust 和 C 语言项目之间进行了跨语言依赖验证，证明其不依赖特定语言生态。

5. 意义与结论 (Significance)

解决隐私与透明的矛盾：VeriSBOM 首次实现了在不披露完整 SBOM 的情况下，对软件依赖项的真实性和策略合规性进行密码学验证。这消除了组织因担心泄露商业机密或漏洞信息而拒绝共享 SBOM 的障碍。
无信任验证：验证者不需要信任 SBOM 发布者，只需信任公开的根哈希（由包管理器和审计员发布）和底层密码学原语的安全性。
供应链安全增强：通过防止“版本等价攻击”（即发布合规证明但交付恶意软件）和“重放攻击”，确保了软件工件与其声明的依赖关系严格绑定。
落地潜力：该方案作为现有包管理器（如 crates.io, Homebrew）的外部层，无需修改现有基础设施即可集成，为大规模软件供应链的隐私保护合规验证提供了可行的技术路径。

局限性：

系统假设 SBOM 输入本身是准确的（即供应商不会故意隐瞒依赖项）。
证明生成涉及较高的计算成本（相对于对称加密），尽管折叠方案已大幅优化。
依赖可信的第三方（包管理器和审计员）来维护根哈希的更新。

总体而言，VeriSBOM 为构建更安全、透明且尊重隐私的软件供应链提供了一套完整的、经过验证的密码学解决方案。