为Homebrew添加可验证构建来源,提升软件供应链安全

Homebrew与Alpha-Omega、OpenSSF合作,为homebrew-core引入密码学可验证的构建来源,确保软件包来自官方CI/CD,符合SLSA Build L2标准,防御供应链攻击。

为Homebrew添加构建来源 - Trail of Bits博客

作者:William Woodruff
日期:2023年11月6日
分类:密码学、生态系统安全、工程实践、开源

这是一篇与Alpha-Omega的联合文章——请阅读他们的公告文章

我们正在与Alpha-Omega和OpenSSF合作启动一个新项目,以提高Homebrew的透明度和安全性。这个为期六个月的项目将为homebrew-core带来密码学可验证的构建来源,允许最终用户和企业证明Homebrew的软件包来自官方的Homebrew CI/CD。简而言之,Homebrew的软件包将符合SLSA Build L2(以前称为Level 2)标准。

作为主导的macOS包管理器以及在Linux上流行的用户空间替代方案,Homebrew每年促进数亿次软件包安装,包括开发工具和工具链,数百万程序员依赖这些工具来构建可信的软件。这种关键地位使Homebrew成为供应链攻击的高调目标,而本项目将有助于阻止这些攻击。

供应链中的脆弱环节

软件供应链由单个环节构建而成,攻击者的目标是通过找到并颠覆最薄弱的环节来破坏整个链条。相反,防御者的目标是加强每个环节,因为攻击者只需破坏一个环节即可获胜。

之前加强整个链条的努力集中在各种环节上:

  • 软件本身的安全性:静态和动态分析,以及旨在消除整个漏洞类别的编程语言的兴起
  • 传输安全性:使用HTTPS和其他经过身份验证、保持完整性的通道来检索和发布软件工件
  • 包索引和管理器安全性:包索引采用双因素认证(2FA),以及像PyPI的Trusted Publishing这样的技术,以减少软件包发布工作流的“爆炸半径”

通过这篇文章,我们希望关注另一个急需加强的环节:不透明和复杂的构建过程。

用可验证来源驯服复杂的构建

软件随着时间的推移变得越来越复杂,构建也不例外;现代构建过程包含了软件供应链中薄弱环节的所有迹象:

  • 不透明、不可审计的构建主机:当今许多软件构建在托管的CI/CD服务上,形成隐式的信任关系。这些服务将它们的依赖注入构建环境,并经常变化——通常出于重要原因,比如修补有漏洞的软件。
  • 庞大、密集的依赖图:我们比以往更依赖小型第三方依赖,这些依赖通常由对安全开发兴趣或经验有限的爱好者维护(或不维护)。我们期望的开发速度需要这种密集的小依赖网络。尽管如此,它们的兴起(以及自动依赖更新的兴起)意味着我们所有的项目都包含数十个等待发生的left-pad事件。
  • 复杂、不可复现的构建系统和过程:未声明和隐式的依赖、无法在本地复现的环境、错误的假设和竞争条件只是构建可能行为不当或无法复现的几种方式,让工程师陷入困境。这些可靠性和可用性问题在我们CI/CD和实时安全发布的世界中也是安全问题。

驯服这些复杂性需要对它们有可见性。我们必须能够枚举并正式描述构建系统的组件,以自动分析它们。这有许多名称并涵盖许多技术(SBOM、构建透明度、可复现性等),但基本思想是来源。

同时,收集来源为我们的链条增加了一个新环节。如果没有完整性和真实性保护,来源只是攻击者可能操纵的另一条信息。

这引出了我们的最终目标:我们可以密码学验证的来源,让我们对构建的起源和完整性的声明有信心。

幸运的是,可验证来源的所有构建块已经存在:Sigstore为我们提供了绑定到机器(或人类)身份的强数字签名,DSSE和in-toto为制作签名证明提供标准格式和签名程序,而SLSA为评估我们声明的强度和可信度提供了正式的分类法。

Homebrew的可验证来源

这对Homebrew意味着什么?一旦完成,homebrew-core提供的每个bottle都将以数字签名的方式证明它是在Homebrew的可信CI/CD上构建的。这些数字签名将通过Sigstore提供;背后的证明将使用in-toto证明框架执行。

即使攻击者设法破坏Homebrew的bottle托管或以其他方式篡改homebrew-core公式中引用的bottle内容,他们也无法为他们的更改伪造真实的数字签名。

这种保护补充了Homebrew现有的完整性和源端真实性保证。一旦homebrew-core的来源完全部署,运行brew install python的用户将能够证明以下每一项:

  • 用于安装Python的公式元数据经过身份验证,得益于Homebrew的签名JSON API。
  • bottle在传输过程中未被篡改,得益于公式元数据中的摘要。
  • bottle是在公共、可审计、受控的CI/CD环境中针对特定源修订构建的。

最后一个属性是全新的,相当于SLSA安全级别分类中的Build L2。

关注我们!

这项工作是开源的,并将公开进行,因此您可以关注我们的活动。我们积极参与Sigstore和OpenSSF的Slack频道,请加入并打个招呼!

Alpha-Omega是OpenSSF的一个关联项目,正在资助这项工作。Alpha-Omega的使命是通过催化对最关键的开源软件项目和生态系统的可持续安全改进来保护社会。OpenSSF为其工作组和项目定期举行会议,我们将参加。

如果您喜欢这篇文章,请分享:


页面内容
最近文章

  • 用Deptective调查您的依赖
  • 系好安全带,Buttercup,AIxCC的评分回合正在进行中!
  • 将智能合约成熟度提升至私钥风险之外
  • Go解析器中意外的安全隐患
  • 我们审查首批DKL23库的收获

来自Silence Laboratories的库
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计