强化供应链安全：为下一波恶意软件攻击做好准备

开源生态系统持续面临有组织、自适应的供应链威胁，这些威胁通过受损的凭证和恶意的包生命周期脚本传播。最近的例子是多波次的Shai-Hulud攻击活动。

虽然个别事件在机制和速度上有所不同，但模式是一致的：攻击者学习迅速，针对维护者的工作流程，并利用发布管道中的信任边界。

本文提炼了持久的经验教训和行动，以帮助维护者和组织加固其系统，并为下一波攻击做好准备，而不仅仅是应对上一次攻击。我们还分享了未来两个季度npm安全路线图的下一步计划。

近期Shai-Hulud攻击活动

Shai-Hulud是一个针对JavaScript供应链的、协调的多波次攻击活动，已从机会主义的入侵演变为精心设计的有针对性攻击。

第一波攻击侧重于滥用受损的维护者账户。它注入恶意的安装后脚本，将恶意代码植入包中，窃取密钥并自我复制，展示了单一立足点如何能迅速波及依赖项。

第二波，即Shai-Hulud 2.0，加剧了威胁：其自我复制和通过受损凭证传播的能力已升级，能够实现跨受害者凭证暴露。第二波还通过自托管运行器注册引入了端点命令与控制，收集更广泛的密钥以助长进一步传播，并具有破坏性功能。这一波次还增加了对CI环境的关注，当检测到在CI上下文中运行时改变其行为，并包含针对某些构建代理的权限提升技术。它还使用了比上一波次有效载荷更难检测的多阶段有效载荷。各变种间时间间隔的缩短表明了一个有组织的攻击者正在研究社区防御并围绕其快速迭代。

Shai-Hulud攻击活动并非孤立的入侵，而是针对维护者工作流程和CI发布管道中的信任边界，重点关注凭证收集和安装时执行。我们在各波次中看到的显著特征包括：

• 凭证相关的入侵：攻击者通过受损的凭证或OAuth令牌获得初始立足点，然后转向收集更多密钥（npm令牌、CI令牌、云凭证）以扩大影响范围。这能够实现跨组织和未来波次的重用，而无需单点故障。
• 带有混淆的安装时执行：恶意的安装后或生命周期脚本被注入到包（或依赖链）中，仅在运行时才显现行为。有效载荷通常有条件地激活（例如，环境检查、组织范围），并使用根据其运行环境量身定制的技术来外泄数据。
• 针对受信任的命名空间和内部包名称：该活动影响了流行且受信任的包，并且蠕虫发布了带有现有包名称的受感染包。第二波还修补了包的版本号，使受感染的包看起来像是合法的更新，并与正常的维护者活动融为一体。
• 围绕防御的快速迭代和工程化：变种之间的短时间间隔以及为绕过先前缓解措施而进行的刻意更改，表明了一种有组织的攻击活动思维模式。其目标是持久的访问和可扩展的传播，而非一次性的机会主义行为。
• 审视发布管道中的盲点：源代码与已发布工件之间、生命周期脚本以及构建时转换的差异，造成了可能被注入行为利用的空白地带，如果团队缺乏工件验证或分阶段审批，这些行为就可能未被察觉。

这种模式的近期波次强化了一点：防御者应主动加固发布模型和凭证流，而不是针对任何单一变种定制缓解措施。

npm的下一步计划

我们正在加速安全路线图以应对不断演变的威胁态势。展望未来，我们的近期工作重点是增加对以下功能的支持：

• 批量OIDC接入：简化的工具，帮助组织大规模将数百个包迁移到可信发布。
• 扩展的OIDC提供商支持：除了GitHub Actions和GitLab之外，增加对其他CI提供商的支持。
• 分阶段发布：一种新的发布模型，在包上线前为维护者提供审查期，需要包所有者进行MFA验证的批准。这使团队能够在更改到达下游用户之前捕获意外更改——这是社区多年来一直要求的功能。

这些投资共同为维护者提供了更强大、更灵活的工具，以在发布过程的每个阶段保护其包。

给GitHub和npm用户及维护者的建议

像Shai-Hulud这样的恶意软件通常通过向npm包添加恶意代码来传播。恶意代码作为包安装的一部分被执行，因此任何安装了该包的npm用户都会受到侵害。恶意软件会扫描本地系统寻找令牌，然后利用这些令牌继续传播。由于npm包通常有许多依赖项，通过将恶意软件添加到一个包中，攻击者可以间接感染许多其他包。并且，通过囤积部分被扫描到的令牌而非立即使用，攻击者可以在最初入侵的数周或数月后发起新的攻击活动。

在下面的“参考文献”部分，我们包含了对近期攻击活动进行更详细分析以及提供安全建议的较长文章的链接，因此我们不会在此重复所有信息。相反，这里是我们最高建议的简短摘要：

给所有人的建议

• 在所有账户上启用防网络钓鱼的MFA（多因素认证），特别是像npm、PyPI、RubyGems或NuGet这样的GitHub包管理器账户，以及任何可能被用于账户接管或网络钓鱼的账户，如电子邮件和社交媒体账户。
• 始终为令牌设置过期日期，以确保它们定期轮换。组织可以强制执行最长寿命策略。
• 审计并撤销未使用的GitHub/OAuth应用程序的访问权限。
• 为开发工作使用沙箱，例如GitHub Codespaces、虚拟机或容器。这会限制你意外运行的任何恶意软件的访问权限。

给维护者的建议

• 启用分支保护，这样即使攻击者拥有有效的令牌，也无法直接将恶意更新推送到你的主分支。
• 使用npm可信发布，而不是令牌。其他包管理器如PyPI、RubyGems和NuGet也提供可信发布。
• 固定CI依赖项，启用代码扫描，并且不要忘记解决代码扫描警报！
• 监控包工件，并验证已发布的tarball/捆绑包与源代码的一致性（例如，使用SRI或工件构建证明）。

请注意，上述建议是预防性的。如果您认为自己是攻击的受害者并需要帮助保护您的GitHub或npm账户，请联系GitHub支持。

参考文献

• 在npm中报告恶意包
• 我们构建更安全的npm供应链的计划
• 强化npm安全性
• 在咨询数据库中查看恶意软件公告
• 保护您的代码库的快速入门指南
• GitHub上的依赖项审查
• OpenSSF针对npm的最佳实践
• 微软的检测和防御指南
• GitHub Actions的近期改进