Google推出OSS Rebuild项目，旨在通过重建上游工件来增强开源软件包生态系统的信任。该项目自动化生成PyPI、npm和Crates.io包的声明式构建定义，提供符合SLSA Build Level 3要求的数千个包的来源证明，并集成构建可观察性和验证工具，帮助安全团队管理漏洞。此外，项目还提供基础设施定义，使组织能够轻松运行自己的OSS Rebuild实例，以重建、生成、签名和分发来源证明，从而应对供应链攻击的挑战。

项目介绍：OSS Rebuild——开源软件的重建与安全保障

今天，我们很高兴宣布推出OSS Rebuild项目，旨在通过重新构建上游软件包来增强开源软件包生态系统的信任度。随着供应链攻击日益针对广泛使用的依赖项，OSS Rebuild为安全团队提供了强大的数据支持，帮助他们在不增加上游维护者负担的情况下避免安全威胁。

项目内容

OSS Rebuild项目包括以下核心功能：

1. 自动化构建定义：为现有的PyPI（Python）、npm（JS/TS）和Crates.io（Rust）软件包生成声明式构建定义。
2. SLSA Provenance：为数千个软件包提供符合SLSA Build Level 3要求的构建证明，无需发布者干预。
3. 构建可观测性与验证工具：安全团队可以将这些工具集成到现有的漏洞管理流程中。
4. 基础设施定义：允许组织轻松运行自己的OSS Rebuild实例，以重建、生成、签名和分发构建证明。

背景与挑战

开源软件已成为现代数字世界的基石，占现代应用程序的77%，其价值估计超过12万亿美元。然而，开源软件的普及也使其成为攻击者的目标。近年来，供应链攻击事件频发，削弱了开源生态系统的信任，导致贡献者和使用者都产生了犹豫。

尽管安全社区已经推出了诸如Security Scorecard、pypi的Trusted Publishers和npm的SLSA支持等举措，但这些解决方案往往需要在某些方面做出妥协，例如将工作负担转移到发布者和维护者身上。

项目目标

OSS Rebuild的目标是通过使软件包的使用像使用源代码仓库一样透明，帮助安全社区深入理解并控制其供应链。该项目通过声明式构建过程、构建工具和网络监控能力，在SLSA Build框架内生成细粒度、持久且可信的安全元数据。

工作原理

通过自动化和启发式方法，OSS Rebuild确定目标软件包的构建定义并重新构建它。随后，将重建结果与现有的上游软件包进行语义比较，去除导致逐位比较失败的不稳定因素（如压缩格式）。一旦成功重建软件包，项目将通过SLSA Provenance发布构建定义和结果，使消费者能够可靠地验证软件包的来源、理解并重复其构建过程，甚至生成更详细的SBOM（软件物料清单）。

项目能力

OSS Rebuild能够检测多种供应链攻击，包括：

1. 未提交的源代码：当发布的软件包包含未公开的代码时，OSS Rebuild不会为该软件包提供证明。
2. 构建环境被篡改：通过创建标准化、最小化的构建环境并进行全面监控，OSS Rebuild可以检测可疑的构建活动或避免暴露于被篡改的组件。
3. 隐蔽的后门：即使是复杂的后门（如xz），在构建过程中也会表现出异常行为。OSS Rebuild的动态分析能力可以检测到这些异常。

对企业和安全专业人士的帮助

• 增强元数据：无需更改注册表，即可为上游软件包丰富数据。
• 完善SBOM：通过添加详细的构建可观测性信息，增强现有的软件物料清单。
• 加速漏洞响应：提供可验证的构建定义，帮助快速修复和重新托管上游软件包。

对开源软件发布者和维护者的帮助

• 增强软件包信任：为消费者提供独立的构建完整性验证。
• 历史软件包完整性修复：为历史软件包提供高质量的构建证明。
• 降低CI安全敏感性：通过单独的重建过程，减少CI平台的安全负担。

如何参与

您可以通过Go命令行工具轻松访问OSS Rebuild的构建证明，获取SLSA Provenance，或探索特定软件包的重建版本。如果您是开发者、企业或安全研究人员，欢迎加入我们，共同为开源软件的安全和透明贡献力量。

• 访问github.com/google/oss-rebuild查看代码并分享您的想法。
• 探索数据并贡献改进对关键生态系统和软件包的支持。
• 了解更多关于SLSA Provenance的信息，请访问slsa.dev。

OSS Rebuild不仅是为了解决问题，更是通过集体行动使开源生态系统更加安全和透明。我们期待您的参与！

1. 对项目持久性的质疑：bgwalter认为该项目可能不会长久，因为它是Google的项目，暗示Google的项目往往寿命较短。

   • "It is a Google project, so I give it two years."（“这是Google的项目，所以我给它两年时间。”）

2. 对项目实用性的质疑：Weethet和WhatIsDukkha认为现有工具（如Nix和Guix）已经提供了类似或更强大的功能，质疑新项目的必要性。

   • "I fail to see any advantages of creating a more narrow version of it that has fewer uses and has to start from scratch."（“我看不出创建一个功能更少、需要从头开始的版本有什么优势。”）
   • "With guix I can bit for bit reproduce with my client machine the upstream binaries."（“使用Guix，我可以在客户端机器上逐位复制上游二进制文件。”）

3. 对项目功能的期待与改进建议：simonw和Flux159提出了对项目功能的期待和改进建议，如增加Web UI和解决构建一致性问题。

   • "I’m very excited about this project, but it could really do with a web UI of some sort!"（“我对这个项目非常兴奋，但它真的需要一个Web UI！”）
   • "I find that for many npm packages, I don’t know how builds were actually published to the registry."（“我发现对于许多npm包，我不知道它们是如何发布到注册表的。”）

4. 对项目安全性和完整性的关注：lrvick和WhatIsDukkha强调了构建过程中的安全性和完整性，建议使用不可变的操作系统和分布式构建能力。

   • "IMO you need an immutable appliance-like OS that is deterministic and full source bootstrapped to do reproductions with minimized trusting-trust attack risk."（“我认为你需要一个不可变的、确定性的、完全自举的操作系统来进行复制，以最小化信任攻击的风险。”）
   • "This seems flawed to assume that google’s servers are uncompromised, its vastly better to have distributed ability to reproduce."（“假设Google的服务器没有被攻破是有缺陷的，拥有分布式复制能力要好得多。”）