标题：一个 AI 编程助手会话演变成了供应链攻击

Mandiant 的最新案例研究表明，一个被劫持的 AI 编程助手会话让攻击者能够向一家软件公司的代码库中注入恶意包，导致 100 个内部代码库遭到破坏，窃取了 GitHub OAuth 令牌，并外泄了源代码和机密信息。 这次违规事件证明，开发者不能将 AI 生成的建议视为安全代码。

事件经过

在一次实时开发会话期间，攻击者控制了嵌入在团队编辑器中的 AI 助手。被劫持的助手随后建议使用一个恶意包。开发者出于对工具的信任，在没有进行额外检查的情况下接受了该建议。

该恶意包植入了一个信息窃取程序，用于搜集存储在工作站上的 GitHub OAuth 令牌。利用这些令牌，攻击者部署了“Shai-Hulud”蠕虫，该蠕虫在 100 个内部代码库中进行了自我复制。由于恶意代码带有公司自身的命名空间，随后拉取相同包的其他开发者也受到了感染。

为何重要

AI 编程助手可以读取项目文件、生成安装命令、编辑依赖清单，甚至运行终端命令。这种广泛的访问权限使其成为供应链攻击极具吸引力的向量。当开发者对 AI 建议的信任超过了对陌生人建议的信任时，攻击者的工作就会变得更加容易：助手可以悄无声息地插入看起来合法的恶意代码。

供应链攻击允许攻击者在组织的整个代码库中进行横向移动、窃取凭据并外泄专有资产——而受害者在损害发生之前往往毫无察觉。

攻击是如何展开的

  1. 会话劫持 – 攻击者接管了一个正在进行的 AI 助手会话。
  2. 恶意推荐 – 被劫持的助手被迫建议使用一个恶意包。
  3. 开发者接受 – 由于相信 AI 的建议，开发者添加了该包并运行了生成的安装命令。
  4. 载荷执行 – 该包安装了一个信息窃取程序，用于读取本地 GitHub OAuth 令牌和其他机密。
  5. 蠕虫传播 – 利用窃取的令牌，攻击者部署了 Shai-Hulud 蠕虫，该蠕虫传播到了 100 个内部代码库。
  6. 数据外泄 – 源代码、内部库和密钥被窃取到攻击者的基础设施中。

开发者现在可以做什么

将每一个 AI 建议都视为不可信代码。对其应用与对待任何第三方依赖项相同的验证步骤。

  • 验证软件包

    • 检查官方文档和版本历史。
    • 确认发布者的身份和声誉。
    • 审查源代码仓库和最近的提交。
    • 检查完整的依赖树是否存在异常链接。
    • 仔细检查任何安装脚本中是否存在隐藏命令。

  • 加强凭据管理

    • 为每个令牌授予尽可能小的权限。
    • 优先使用短期令牌，而非长期令牌。
    • 不要将生产环境的机密存储在本地开发机上。
    • 限制编辑器扩展访问其不需要的凭据。

  • 应对疑似违规事件

    • 立即隔离受影响的环境；仅删除 node_modules 或类似目录是不够的。
    • 轮换所有 GitHub、npm、PyPI 和云端凭据。
    • 审计代码库活动，检查是否存在异常的提交或拉取请求（pull-request）合并。
    • 审查 CI/CD 日志和 Git-hook 脚本是否存在异常行为。

展望未来

AI 助手将继续为许多开发者提高生产力，但其功能也伴随着信任成本。组织应当将 AI 生成的代码纳入现有的安全审查流程中，就像对待任何外部库一样。自动化策略检查、经过签名的 AI 助手输出以及运行时沙箱化可以降低被悄无声息入侵的风险。

Mandiant 的案例清楚地表明，一旦 AI 助手遭到破坏，攻击者就获得了一条进入软件供应链的直接通道。将 AI 建议视为威胁模型的一部分，而不是一种“免检通行证”，对于保障代码库安全至关重要。

核心要点：AI 生成的建议并不比任何其他第三方代码更值得信任。必须对其进行严格的验证、限制和监控，否则就有可能让一个得力的助手变成大规模供应链攻击的渠道。