引入OSS Rebuild：开源软件，重建以持久
发布日期：2025年7月21日
作者：Matthew Suozzo，谷歌开源安全团队（GOSST）
今天我们兴奋地宣布OSS Rebuild项目，这是一个通过重现上游制品来增强开源软件包生态系统信任度的新项目。随着供应链攻击持续针对广泛使用的依赖项，OSS Rebuild为安全团队提供了强大的数据来避免遭受攻击，同时不会给上游维护者增加负担。
项目组成
- 自动化工具，为现有的PyPI（Python）、npm（JS/TS）和Crates.io（Rust）软件包推导声明式构建定义
- 在我们支持的生态系统中为数千个软件包提供SLSA来源证明，满足SLSA构建级别3要求，无需发布者干预
- 构建可观察性和验证工具，安全团队可将其集成到现有的漏洞管理工作流中
- 基础设施定义，允许组织轻松运行自己的OSS Rebuild实例来重建、生成、签名和分发来源证明
挑战
开源软件已成为我们数字世界的基础。从关键基础设施到日常应用，OSS组件现在占现代应用程序的77%。估计价值超过12万亿美元，开源软件对全球经济的重要性前所未有。
然而，这种普遍性使得开源成为一个有吸引力的目标：最近备受关注的供应链攻击展示了危害广泛使用软件包的复杂方法。每起事件都削弱了对开放生态系统的信任，在贡献者和消费者中都造成了犹豫。
安全社区已通过OpenSSF Scorecard、pypi的Trusted Publishers和npm的原生SLSA支持等倡议做出回应。然而，没有万能药：每项努力都针对问题的某个方面，通常需要做出权衡，比如将工作转移给发布者和维护者。
我们的目标
OSS Rebuild的目标是通过使软件包消费像使用源代码仓库一样透明，赋能安全社区深入理解并控制其供应链。我们的重建平台通过利用声明式构建过程、构建检测和网络监控能力来实现这种透明度，在SLSA构建框架内产生细粒度、持久、可信的安全元数据。
基于我们通过OSS Fuzz在内存问题检测方面开创的托管基础设施模型，OSS Rebuild同样寻求使用托管资源来解决开源中的安全挑战，这次的目标是保护软件供应链。
我们的愿景超越任何单一生态系统：我们致力于为所有开源软件开发带来供应链透明度和安全性。我们最初对PyPI（Python）、npm（JS/TS）和Crates.io（Rust）软件包注册表的支持——为其许多最受欢迎的软件包提供重建来源证明——只是我们旅程的开始。
OSS Rebuild如何工作
通过自动化和启发式方法，我们确定目标软件包的预期构建定义并重新构建它。我们将结果与现有的上游制品进行语义比较，对每个结果进行规范化以移除导致逐位比较失败的不稳定性（如归档压缩）。一旦我们重现了软件包，我们就通过SLSA来源证明发布构建定义和结果。此证明允许消费者可靠地验证软件包在源代码历史中的来源，理解并重复其构建过程，并从已知功能基线自定义构建（或者甚至使用它生成更详细的SBOM）。
通过OSS Rebuild对PyPI、npm和Crates.io的现有自动化，大多数软件包无需用户或维护者干预即可获得保护。在自动化目前无法完全重现软件包的情况下，我们提供手动构建规范，使整个社区受益于个人贡献。
我们对AI帮助重现软件包的潜力感到兴奋：构建和发布过程通常用自然语言文档描述，虽然难以用离散逻辑利用，但对语言模型越来越有用。我们的初步实验证明了该方法在自动化探索和测试中的可行性，只需有限的人工干预，即使在最复杂的构建中也是如此。
我们的能力
OSS Rebuild帮助检测几类供应链危害：
未提交的源代码 - 当发布的软件包包含公共源代码仓库中不存在的代码时，OSS Rebuild不会对制品进行证明。 真实世界攻击：solana/webjs（2024）
构建环境泄露 - 通过创建具有全面监控的标准化、最小构建环境，OSS Rebuild可以检测可疑的构建活动或完全避免暴露于受损组件。 真实世界攻击：tj-actions/changed-files（2025）
隐蔽后门 - 即使是像xz这样复杂的后门，在构建过程中也经常表现出异常的行为模式。OSS Rebuild的动态分析能力可以检测异常执行路径或可疑操作，这些通过手动审查实际上难以识别。 真实世界攻击：xz-utils（2024）
对于企业和安全专业人员，OSS Rebuild可以…
- 通过丰富上游软件包的数据来增强元数据，而无需更改注册表。无需维护自定义注册表或迁移到新的软件包生态系统。
- 通过向现有的软件物料清单添加详细的构建可观察性信息来增强SBOM，创建更完整的安全图景。
- 通过提供使用我们可验证构建定义来供应、修补和重新托管上游软件包的路径，加速漏洞响应。
对于开源软件包的发布者和维护者，OSS Rebuild可以…
- 通过为消费者提供软件包构建完整性的独立验证来增强软件包信任度，无论原始构建的复杂程度如何。
- 为历史软件包提供高质量的构建证明，无论发布时是否存在或支持构建证明。
- 减少CI安全敏感性，允许发布者专注于核心开发工作。CI平台往往具有复杂的授权和执行模型，通过执行单独的重建，CI环境不再需要为软件包的安全性承担重任。
试用！
访问OSS Rebuild证明的最简单（但不是唯一！）方法是使用提供的基于Go的命令行界面。它可以轻松编译和安装：
|
|
您可以获取OSS Rebuild的SLSA来源证明：
|
|
…或探索特定软件包的重建版本：
|
|
…甚至为自己重建软件包：
|
|
加入我们，共同保护开源
OSS Rebuild不仅仅是修复问题；它旨在通过集体行动赋能最终用户，使开源生态系统更加安全和透明。如果您是开发人员、企业或安全研究人员，对OSS安全感兴趣，我们邀请您关注并参与！
- 在github.com/google/oss-rebuild查看代码、分享想法并发表反馈
- 探索数据并为改进对关键生态系统和软件包的支持做出贡献
- 在slsa.dev了解更多关于SLSA来源证明的信息