加强供应链安全：为下一次恶意软件行动做准备

Source: GitHub Blog

概述

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

我们看到的情况

• 快速学习: 对手迅速适应其战术。
• 针对性维护者工作流: 攻击者聚焦于包维护的人为和流程要素。
• 信任边界利用: 利用发布流水线注入恶意代码。

持久的教训

1. 假设泄露： 将每个凭证视为可能已被泄露。
2. 保护流水线： 对谁可以发布以及可以运行哪些脚本实施严格控制。
3. 监控异常： 关注 CI/CD、发布和凭证使用中的异常活动。

可操作的建议

• 定期轮换凭证 并将其存储在机密管理器中。
• 为所有维护者账户启用双因素认证 (2FA)。
• 限制写入权限 仅授予需要的人员；遵循最小权限原则。
• 在合并或执行之前审计包生命周期脚本。
• 实施供应链扫描 工具，以检测恶意代码模式。
• 设置警报，以监控包下载量或发布频率的突增。

展望前景

我们将在接下来的两个季度扩展 npm 安全路线图，内容包括：

• 加强的 凭证泄漏检测 机制。
• 新的 策略即代码 功能，用于自动执行安全规则。
• 改进的 可视性，以了解依赖来源和完整性检查。

本文提炼了持久的经验教训和行动，帮助维护者和组织加固系统并为下一次攻击做好准备——不仅仅是应对上一次。

最近的 Shai‑Hulud 攻击活动

Shai‑Hulud 是一场针对 JavaScript 供应链的协调式、多波次攻击。它已从机会主义的妥协演变为工程化、针对性的攻击。

第 1 波 – 被妥协的维护者账户

• 向包中注入恶意的 post‑install 脚本。
• 目标：将恶意代码渗透到依赖中，窃取机密，并自我复制。
• 展示了单一立足点如何在生态系统中产生连锁效应。

第 2 波 – Shai‑Hulud 2.0

• 自我复制 功能升级，可实现跨受害者的凭证泄露。
• 通过自托管 runner 注册添加 端点指挥控制。
• 收集更广泛的机密以推动进一步传播，并引入破坏性功能。
• 重点转向 CI 环境：
  • 检测自身是否在 CI 流水线中运行。
  • 对特定构建代理实施特权提升技术。
• 使用 多阶段载荷，比第一波载荷更难检测。
• 变体之间的时间间隔缩短，表明对手组织有序，研究社区防御并快速迭代。

各波的共同特征

• 凭证相关的妥协

  • 通过被盗的凭证或 OAuth 令牌获取初始立足点。
  • 进一步收集其他机密（npm 令牌、CI 令牌、云凭证）。
  • 实现跨组织、跨后续波次的复用，避免单点失效。

• 安装时执行并进行混淆

  • 在包（或依赖链）中注入恶意的 post‑install 或生命周期脚本。
  • 载荷在特定条件下激活（例如环境检查、组织范围）。
  • 数据外泄技术针对运行时环境进行定制。

• 针对受信任的命名空间和内部包名

  • 受影响的是流行且受信任的包。
  • 被感染的包以已有名称发布。
  • 第 2 波通过修补版本号伪装成合法更新，混入正常的维护者活动。

• 快速迭代并围绕防御进行工程化

  • 变体之间间隔短。
  • 有意更改以规避之前的缓解措施。
  • 目标是保持持久访问并实现规模化传播，而非一次性机会主义。

• 审查发布流水线中的盲点

  • 源代码与发布产物之间存在不一致。
  • 生命周期脚本和构建时转换会产生漏洞。
  • 若缺乏产物验证或分阶段审批，注入的行为可能悄然通过。

结论

最近的波次再次强调，防御者必须 主动加固发布模型和凭证流，而不是仅针对单一变体制定缓解措施。对产物进行持续验证、严格的 CI 流水线控制以及对凭证的警惕管理，都是破坏 Shai‑Hulud 供应链威胁的关键。

npm 的下一步

我们正在加速安全路线图，以应对不断演变的威胁形势。接下来，我们的首要任务是添加以下支持：

• 批量 OIDC 入职 – 精简工具，帮助组织在大规模上将数百个包迁移到受信任的发布。
• 扩展的 OIDC 提供商支持 – 为 GitHub Actions 和 GitLab 之外的更多 CI 提供商添加支持。
• 分阶段发布 – 一种新的发布模型，让维护者在包上线前拥有审查期，并通过 MFA 验证的包所有者批准。这使团队能够在更改到达下游用户之前捕获意外更改——这是社区多年来一直在请求的功能。

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

GitHub 与 npm 用户和维护者的建议

恶意软件（如 Shai‑Hulud）常通过向 npm 包注入恶意代码进行传播。代码会在安装期间执行，进而危及安装该包的任何用户。由于 npm 包通常拥有大量依赖，攻破单个包可能间接影响许多其他包。攻击者还可能囤积被窃取的令牌，并在数周或数月后发起新一轮攻击。

以下是我们核心建议的简要概述。欲获取更深入的分析和更多指导，请参阅下文的“参考资料”章节。

给所有人的建议

• 为所有账户启用防钓鱼的 MFA，尤其是以下包管理平台的账户：

  • GitHub
  • npm
  • PyPI
  • RubyGems
  • NuGet

• 设置令牌过期日期 并定期轮换。组织可以强制执行 最大生命周期策略。

• 审计并撤销 未使用的 GitHub/OAuth 应用的访问权限。

• 在沙箱环境中开发（例如 GitHub Codespaces、虚拟机或容器），以限制意外执行的恶意软件的影响。

给维护者的建议

• 启用分支保护，防止直接推送到主分支，即使攻击者获得了有效令牌。

• 使用受信任的发布 而非长期令牌。受信任的发布已在以下平台提供：

  • npm
  • PyPI
  • RubyGems
  • NuGet

• 锁定 CI 依赖，启用代码扫描，并及时处理所有警报：

  • 锁定依赖：
  • 代码扫描：
  • 处理警报：

• 验证已发布的制品（例如使用子资源完整性（SRI）或制品构建证明），确保分发的 tar 包/捆绑包与源码一致：

  • SRI：
  • 制品证明：

如果您怀疑账户被攻破，请联系 GitHub Support 获取帮助。

参考文献

• 报告 npm 中的恶意包
• 我们对更安全的 npm 供应链的计划
• 加强 npm 安全性
• 在 Advisory Database 中查看恶意软件通报
• 保护代码库的快速入门指南
• GitHub 上的依赖审查
• OpenSSF 对 npm 的最佳实践
• Microsoft 关于检测与防御的指南
• GitHub Actions 的最新改进

作者简介

Madison Oliver 是一位漏洞透明度倡导者，现任 GitHub 高级安全经理，负责 Advisory Database 的策展工作。她热衷于漏洞报告、响应与披露，并共同主持相关的开源安全基金会（OpenSSF）工作组，同时在 CVE 项目委员会任职。她的观点受益于此前在 GitHub 担任产品事件响应分析师以及在卡内基梅隆大学软件工程研究所 CERT 协调中心担任漏洞协调员的经验。

相关帖子

(未列出)

Explore more from GitHub