观察开源安全基金会制订中的软件包存储库安全框架

这两天 XZ Utils 所依赖的 liblzma5 函数库被卧底黑客植入木马的事情炒得沸沸扬扬，本质上依然是一次未遂的供应链攻击事件。但如果一旦得手，影响的深远和严重性是难以想象的。

笔者：	国际认证信息系统审计师（CISA）软考系统分析师

这让我想起来在2月（2024年），作为加强开源软件供应链安全的新举措，开源安全基金会（OpenSSF）联同美国网络空间安全与基础设施安全局（CISA）计划制订用于加强软件包存储库（以下或简称为包存储库）的安全实践框架。

具体到软件包存储库的安全风险，笔者在之前就已经从网络安全审计角度对如何缓解一些基础的实施风险进行了探讨：

很显然，作为开放源码软件分发体系中关键一环的软件包存储库，其安全性的严重性是所有安全从业人员和机构都会思考和关注的。因此，美国CISA就联同OpenSSF制订和准备发布称为《Principles for Package Repository Security》（有关包存储库安全的原则）的安全要求框架，使能从基础原则上强化开源软件包的管理和整个开放源码软件体系。

开放源码软件包存储库最早是随着 LINUX 发行版的出现而出现，并随着开源软件成为互联网软件构建基础体系的组成部分而产生了大量扩展模式，比如像 npm 这样的用于构建过程的存储库，也有用于运行态的 CDN 模式存储库，连微软也推出了 Windows Package Manager。

但很显然现有的各种包存储库主要关注点都是在于软件包的分发是否有效，而不是分发过程是否足够安全。

这是因为，发行版的软件包都是经过了数字签名的，作为用户，都会默认其经过了签名就是安全的。

但这次 XZ Utils 被植入恶意代码的事件足以否定了“软件包经过签名就是安全的”这个想法。

而且，很多开源软件包存储库都是由非盈利组织运营，在资源投放上会先天地存在不足，这也会导致在应对风险时往往会降低安全底线要求，从而加重了安全风险会带来的影响。

扯了那么多，其实懂的读者都会估计到 OpenSSF 这个框架是还未能应对这次 XZ Utils 事件的类似情况，因为这次的安全事件性质比较特殊。尽管如此，我们还是具体地看看 OpenSSF 拟制订的框架能应对和缓解何种网络安全风险。

又是这只大雁

一	安全成熟度的横向4个层次

《Principles for Package Repository Security》采取了安全成熟度的判定机制，共定义了横向4种层次的成熟度：

0级：只具备很低的安全成熟度，可以认为大多数包存储库都处于这个层次。

1级：具备基本的安全成熟度，例如用户登录实施 MFA 多因子强验证，允许安全研究员无风险报告软件漏洞等。任何包存储库都应该实现最低是1级的安全成熟度。

2级：具备中等的安全成熟度，例如对于关键软件包的操作需要实施 MFA 验证，对用户给出已知漏洞的警告等。

3级：具备高级的安全成熟度，例如对所有的维护者的行为都要求 MFA 验证，支持提供软件包构建来源信息等。

在笔者理解，0级成熟度并不代表不安全，只是实施的安全措施的比较有限。通读整个框架认为，如果是静态镜像的包存储库，要做到的就是介乎于0级和1级之间即可。

关于软件包构建来源信息，可以参考笔者之前的一些关于软件供应链安全的文章，例如：

二	安全成熟度的纵向4个轨道

框架中对于1~3级的安全成熟度，再分别从身份验证、角色授权、常规能力和命令行工具四种不同的纵向轨道形成3*4的矩阵，构成最佳实践，引导包存储库的管理者根据自身的功能特点对标实现安全。

不同的包存储库有不同的设计和使用目的。按其提供的功能和服务以纵向轨道方式进行分类，可以更具体地把安全要求结合到包存储库本身，避免无用功。

例如，包存储库需要管理用户账号，那么按框架的设计，就需要实现属于身份验证轨道的用户校验和账号恢复等安全要求才能达到1级成熟度。但如果软件包存储库不管理用户账号，那就可以忽略这些要求。

大致可以按下示例图理解。

级别/轨道	身份验证	授权	常规能力	CLI工具
0级	低成熟度，无要求
1级	基本成熟度高级成熟度
2级
3级

三	安全框架的具体内容

下面逐一介绍和评论。中括号内是笔者对框架内容的看法。

功能轨道1：身份验证

适用于具有用户帐户的存储库。

1级：

要求用户验证电子邮件地址，确保当用户失去其帐户的控制时可以通过电子邮件方式恢复。帐户恢复策略需要被文档化。[基本要求了属于是。应该补充强调要求用户登记和验证不止一个电子邮件地址]

最低需要通过 TOTP（基于时间的一次性口令）支持 MFA 多因子强验证。仅提供较弱的 MFA 形式，如短信、电子邮件或基于电话的 MFA 是不满足这一要求的。[TOTP 技术上是强于诸如短信方式的验证码，但用户依然是可以被欺骗的，所以最好还是 TOTP 结合短信验证码等多种方式，其实MFA因子是越多越好虽然麻烦]

能通过电子邮件通知运维人员是否发生了关键的帐户安全因素更改操作，如密码更改或禁用 MFA 身份验证。这可以帮助用户检测他们的账户是否被入侵。[原文是通知 maintainers ，但我认为关键是通知到用户自己]

实现了帐户安全措施，典型如对密码爆破的防护，以及对 MFA 的破解尝试的防护等。[必须实现防爆，否则审计不通过]

2级：

需要具备能辨别已经被用户废弃不用的电子邮件域的能力，以防止黑客盗用冒充已经废弃的用户域名电子邮箱，通过邮件恢复过程获取对包存储库的控制。[现在很多用户注册都要提供公司域名邮箱以方便甄别用户性质进行营销，但很显然这是为黑客打开了另一扇窗]

需要通过能抵抗网络钓鱼的方式，比如 WebAuthn，支持 MFA 验证。[WebAuthn 是利用数字证书的无密码登录，可以避免用户被钓鱼而泄漏密码，但是用户的数字证书私钥依然是可能被盗取的，这里可能要补充提醒用户运用 GnuPG 之类软件]

需要明确地确定哪些是关键的软件包，并且在操作这些包之前必须经过 MFA 验证。[明确就是要策略化和公布，但我认为不要定义什么是关键，应该全部，不然就是在设计上留下了短板]

需要集成公共的泄露凭证检测数据库，如 Have I Been Pwned，以在用户注册或登录时检查是否使用了已知泄露的凭证，并提示用户更改。[很有意义的做法]

3级：

需要支持无密码身份验证技术，例如 Passkeys。[这里和2级的内容有点混淆，因为 WebAuthn 也是无密码身份验证技术，估计框架草案的意思是不使用 MFA 时必须使用无密码技术]

需要对所有的运维人员实现 MFA 验证。[这一条觉得应该挪到2级，运维人员的账号安全性远比用户要高]

需要对被认为是关键的软件包执行能抵抗网络钓鱼的 MFA 验证。如果可行，安全密钥由包存储库管理和向运维人员提供。[除了对“关键”软件包的看法和2级那里相同之外，安全密钥由包存储库自行管理这一点我认为并不合适，第三方CA机构在密钥管理上可能会比包存储库自己做得更好]

功能轨道2：授权

适用于具有用户帐户并接受已构建的包的包存储库。

1级：

需要能向运维人员提供针对特定软件包的API密钥，从而支持运维人员通过自动化的工作流实现维护软件包，而不需要使用帐户和密码。[让人马上想到 SBOMit 和 in-toto，所以这是必要的]

API 的令牌需要具有包存储库特定的前缀标识符。[规范化管理理应如此]

2级：

需要支持应用于运维人员的基于角色的访问控制（RBAC），并允许使用单独的角色来管理用户和发布程序包。[可以直接对标等保三员]

3级：

需要提供符合 OIDC 的令牌交换方式提供短寿命的API令牌，从而避免向他方提供长寿命的 API 密钥。[必须缩短对任何他方的信任期，即使认为是“可信”的源头软件发布商]

提供的API令牌能被集成到通用的第三方的秘密扫描程序中。需要对API令牌冠以特定前缀或命名组合，这样在集成利用时可以减少扫描检测结果的假阳性报告。包存储库还需要为秘密扫描程序提供了发现秘密的报告端点，在接收到泄漏凭据的报告时判断报告内容的有效性和自动撤销凭据。[直接把各种密码密钥嵌入到源代码导致秘密泄露的情况是经常发生，无论是开源社区抑或是大厂都有这种情况。确实要通过扫描程序才能有效解决，扫描、报告、处置全过程自动化也确实必要]

软件包存储库支持为包提供构建来源。[显然接下来要多关注 SBOMit]

功能轨道3：常规能力

适用于所有软件包存储库的常规安全能力。

1级：

制订和发布漏洞公开策略，允许安全研究人员识别和报告影响包存储库的漏洞，并在该策略的庇护下作为合法的安全港。软件包存储库应努力在90天内缓解所报告的漏洞。[安全港对于研究员来说很重要。这条的问题是在我看来90天是否太长了，即使不能源代码级别修补，起码也要找些别的办法来尽快缓解]

包存储库采取步骤防止围绕包名实施的别名攻击（typosquatting attack）。这包括需要定义命名空间、检测类似的名称或其他操作。[用高度相似的软件包名称误导下载恶意软件包，对于警觉性先天不足的用户确实是个坎，但这里的描述还不够，还要防范使用unicode中不同语言的相似字符实施名字冒充攻击，系统管理员在命令行时使用TAB键补全文件名的操作很容易中这个招]

2级：

制订和发布软件包更替和取消的策略，以防止冒用软件包的特定版本。如果软件包被删除，则还要能防止其他软件包重用相同的名称和版本。[软件包要用清单来维护跟踪，不能只有纯文件方式]

允许用户通过用户界面、工具CLI和API报告软件包的可疑或恶意情况。[用工具CLI和API报告问题这种做法还比较少，此条值得关注]

具备检测恶意软件的能力，包括扫描已知的恶意软件代码片段和比对校验值等方法。[不仅包存储库，在软件构建过程内集成ClamAV是至少需要的了]

能对构成用户UI界面的依赖项中已知的安全漏洞提出告警。[各种 Javascript 前端库确实漏洞不少，此告警有意义，但作为安全框架内容显得比较单一]

3级：

运维人员应对包存储库的基础结构进行定期安全审查，对安全风险进行整改，并在完成整改后选择是否公布所执行的风险缓解措施。[公布属于结构性的风险可以为业界提供安全实践参考，应该鼓励]

维持和发布事件透明性日志，以支持检测异常行为。[原文举了replicate.npmjs.com 为例子，但说得不清不楚。按我的理解，是指包存储库可以公开一些系统后台的运行事件信息，通过这些信息可以动态地检测出是否存在异常的情况，比如不应该有巨量写入的数据库产生了巨量写入的事件，或者本应是相对空闲的系统时间产生了大量读操作之类]

基于互操作性考虑，使用标准化的机器可读格式发布针对恶意软件包的建议措施。典型如使用 OSV Schema 格式并利用 OSV 服务提供的聚合功能。[很显然，osv.dev 漏洞数据库的重要性越来越高，但osv-scanner 的发展有点慢，且功能上还和笔者的期望有点差距]

功能轨道4：CLI工具

适用于所有的包管理生态系统，但主要关注CLI工具的实现，而不是生态系统本身。这是因为虽然安全措施的实施主要在包存储库一侧，但由于包存储库的用户和客户端基本都是通过CLI工具获取软件包，所以CLI工具的安全能力也需要明确。

1级：

CLI工具可基于哈希值、版本号等软件包的元信息固化确定其依赖项并自动安装。[这属于包存储库的基操，典型如 YUM]

2级：

CLI工具会在安装软件包时就已知的依赖项安全漏洞给出警告。[这需要集成安全漏洞信息库，依然是需要加大运用 osv.dev ]

3级：

CLI工具需要具有生成 SBOM 清单的功能。[CLI工具通常用于获取软件包，生成 SBOM 清单对其有点超越，我认为在这个阶段用CLI工具只能生成 SBOM 清单的一部分，在项目构建时还要实现整合]

CLI工具可以通过版本升级，实现自动识别和修复依赖项中的已知漏洞。[实践过就会知道，自动识别和修复是不同的能力层次，这里感觉是混为一谈了，但当然是能自动修复就更好]

CLI工具能够使用静态分析方法减少已识别出的漏洞的误报，确定存在漏洞的代码执行路径是否真的是可达到的。例如 Golang 的漏洞检查功能。[这个要求也相当高，因为不同的开发语言对此的实现能力不相同。尤其是对于像这次 XZ Utils 被篡改，是在编译构建阶段才会对最终生成的运行代码嵌入预先编译的恶意代码，那么仅对源代码进行静态分析就完全无法识别出这种攻击]