AI 助手推荐的依赖被投了毒

Mandiant 披露 AI 助手会话劫持致供应链投毒案例

9 月 16 日，The Hacker News 援引 Mandiant 报告披露了一起新型攻击案例：某 SaaS 厂商的 AI 编程助手会话遭攻击者接管。攻击者利用该活跃会话，诱导开发者安装已投毒的软件包，进而植入信息窃取木马并窃取 GitHub OAuth 令牌。随后，Shai-Hulud 蠕虫被注入该公司约一百个代码仓库，导致密钥及源代码泄露。更严重的是，公司官方命名空间内的包也被污染，引发内部二次感染。

Mandiant 未透露受害者名称、具体使用的 AI 工具及会话劫持细节。该案例揭示了一种完整的失败模式：受信任的 AI 助手给出依赖建议，开发者直接采纳，后续攻击全自动完成。值得注意的是，模型本身大概率未被攻破，攻击者仅需在推荐链上游投毒，等待助手“端送”恶意包即可。这种手段成本更低且更为稳定。

防御盲区：传统检测无法覆盖 AI 推荐路径

此次攻击暴露了现有防御体系的盲区。传统的供应链检测（如依赖扫描、SBOM、镜像检查）主要针对“从公共仓库拉取”这一路径，而"AI 助手推荐并通过校验”的行为不在任何规则覆盖范围内。即便包存在于公司自有命名空间，若缺乏针对 AI 推荐环节的审核，依然无法阻止风险。

Shai-Hulud 蠕虫升级：扫描范围大幅扩张

Shai-Hulud 蠕虫家族持续进化。继 8 月初 npm 生态投毒事件后，GitGuardian 于 9 月初发现其窃密变种显著扩大了扫描目标：

攻击核心在于获取有效凭据。一旦获得包发布令牌、GitHub Token 或 CI 凭据，攻击者即可横向移动，这解释了为何单次“接受建议”会导致百个仓库失守。

Mandiant 建议的三项关键控制措施

针对 AI 辅助开发环境，Mandiant 提出以下建议：

• 严格校验依赖：对 AI 推荐的第三方依赖，部署前必须核对校验和与白名单；关闭一键安装功能，将“采纳建议”转化为需审批的变更流程。
• 收敛凭据权限：避免将原始 API Key、长期 OAuth 令牌存储在插件易访问位置；优先使用短期 OIDC 令牌替代长期发布令牌。
• 管控流量路径：依赖流量应经由公司受控仓库中转，禁止直连公共源。

若怀疑已中招，首要措施并非立即删包，而是假定源码已泄露，立即按“同一身份关联范围”轮换所有相关密钥（包括仓库密钥、CI 凭据、云访问密钥等），随后再进行清理。

结语：重塑对 AI 助手的信任边界

此事件标志着信任入口的进一步前移。过往“不盲目复制 Stack Overflow 代码”的原则，需升级为“不直接安装 AI 助手递送的依赖”。区别在于，前者需人工审视，后者往往带有工具背书而被忽视。面对不断进化的 Shai-Hulud 等威胁，关键在于确保即使攻击者找到新的渗透点，也无法利用遗留的密钥打开大门。

信息来源：The Hacker News