挑战
开源软件已成为数字世界的基石。从关键基础设施到日常应用，开源组件在现代应用程序中占比高达77%。开源软件估值超过12万亿美元，对全球经济的重要性前所未有。
然而这种普遍性也使开源成为诱人目标：近期高调供应链攻击事件展示了入侵流行软件包的复杂手段。每起事件都在侵蚀开放生态系统的信任度，导致贡献者和使用者产生顾虑。
安全社区已通过OpenSSF Scorecard、pypi可信发布者和npm原生SLSA支持等举措作出回应。但尚无万全之策：每种方案都针对特定问题层面，通常需要让发布者和维护者承担更多工作。
项目目标
OSS Rebuild旨在通过使软件包消费像使用源码仓库般透明，助力安全社区深入理解并控制其供应链。我们的重建平台通过声明式构建流程、构建插桩和网络监控能力实现这种透明度，在SLSA构建框架内生成细粒度、持久且可信的安全元数据。
基于我们通过OSS Fuzz在内存问题检测方面开创的托管基础设施模式，OSS Rebuild同样寻求使用托管资源解决开源安全挑战，此次重点聚焦软件供应链安全。
我们的愿景超越单一生态系统：我们致力于为所有开源软件开发带来供应链透明度和安全性。初期对PyPI、npm和Crates.io软件包注册表的支持——为其众多流行软件包提供重建溯源——只是我们征程的起点。
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能够：
- 通过丰富上游软件包数据增强元数据，无需维护自定义注册表或迁移至新软件包生态系统
- 向现有软件物料清单添加详细构建可观测性信息，完善安全态势
- 使用可验证构建定义提供供应商选择、修补和重新托管上游软件包的路径，加速漏洞响应
维护者价值
对开源软件包发布者和维护者，OSS Rebuild能够：
- 通过为消费者提供软件包构建完整性的独立验证来增强信任，无论原始构建复杂程度如何
- 为历史软件包提供高质量构建认证，无论发布时是否支持构建认证
- 降低CI安全敏感性，让发布者专注于核心开发工作。CI平台通常具有复杂的授权和执行模型，通过单独重建，CI环境不再需要承担软件包安全的重任
快速开始
访问OSS Rebuild认证的最简单（非唯一）方式是使用提供的基于Go的命令行界面：
|
|
获取OSS Rebuild的SLSA溯源：
|
|
探索特定软件包的重建版本：
|
|
甚至自行重建软件包：
|
|
加入我们
OSS Rebuild不仅关乎解决问题，更关乎通过集体行动赋能终端用户使开源生态系统更安全透明。如果您是开发者、企业或安全研究员，对开源安全感兴趣，我们邀请您关注并参与！
在 github.com/google/oss-rebuild 查看代码、分享想法并反馈意见。
探索数据并为改进关键生态系统和软件包支持做出贡献。
在 slsa.dev 了解更多关于SLSA溯源的信息。