article-5.md
title: “AI 编程助手成攻击跳板”
category: 3
从一次代码建议，到百个仓库沦陷
2026 年 9 月，Mandiant 发布了一份关于 AI 辅助开发环境安全风险的报告，披露了一起值得全行业关注的真实攻击案例：一名攻击者劫持了某 SaaS 公司开发者正在使用的 AI 编程助手会话，诱导其接受一个已被投毒的软件依赖，随后利用该依赖作为跳板，将名为 Shai-Hulud 的蠕虫程序散布至约 100 个内部代码仓库，最终窃取了公司仓库中的密钥和源代码。该报告没有披露受害者身份、被操控的 AI 助手具体是哪一款，也没有指明攻击者所属的威胁组织——但这恰恰说明，这不是某个产品的漏洞，而是一种新型工作流本身的缺陷。
攻击链拆解：被信任的建议
整条攻击链的核心只有一步：AI 编程助手在开发者的编辑会话中推荐了一个依赖包，开发者接受了。Mandiant 的记录在这里停顿了——它没有说明攻击者如何获取了活跃的会话控制权，也没有描述投毒依赖包的具体名称。但结果链条清晰：被接受的投毒推荐 → 会话被劫持 → 蠕虫部署 → 100 个仓库被感染 → 密钥和 OAuth Token 被盗。
Shai-Hulud 并非首次现身。这个以《沙丘》中的沙虫命名的蠕虫家族早在 2025 年 9 月就首次被记录，当时它通过 npm 包传播，感染了数十个库。2026 年 8 月，GitGuardian 逆向工程发现 Shai-Hulud 的最新变体已将凭证扫描范围从 189 个位置扩展到 469 个，覆盖开发者环境、CI/CD 工具、云配置，以及 Cursor、OpenClaw、Codex、Gemini、Hermes 等 AI 开发工具的配置文件。这意味着它不再只盯着 .env 文件和 shell 历史，而是开始扫描开发者日常使用的每一款工具。
攻击者不需要逐个攻破每台机器——他只需要找到那把能打开下一个入口的钥匙。
微软事件：蠕虫已进入大厂生产管道
同一时期，安全社区还追踪到另一条更贴近大厂的线索。2026 年 6 月 5 日，GitHub 在 105 秒内自动关闭了微软旗下 73 个仓库，涉及 Azure 和 Durable Task 生态中的核心组件。StepSecurity 的研究确认，这次攻击同样属于 Miasma 蠕虫（Shai-Hulud 的变种），其恶意代码专门针对 Claude Code、Gemini CLI、Cursor 和 VS Code 等 AI 编程工具进行凭证窃取。攻击者先通过 Red Hat 的 npm 包获得初始立足点，随后横向渗透到微软的 GitHub 组织。
一个关键细节是：Azure/functions-action 是其他团队工作流中引用的 GitHub Action，一旦被禁用，所有依赖它的 CI/CD 流水线同时中断。这说明供应链攻击的影响范围不再局限于单个仓库，而是可以穿透到整个生态的自动化管道。
防御实践：把 AI 助手当成特权系统
Mandiant 在报告中提出了三项控制建议，安全团队可以据此做一次自查：
- AI 推荐的依赖必须先校验。 不要仅凭助手的推荐就安装第三方包；确认内部是否启用了签名校验或白名单，且校验失败时是阻止安装而非只记录警告。
- 密钥远离助手会话。 长-lived 的 API 密钥和 OAuth Token 不应暴露在编辑器扩展或 AI 工具的访问范围内；优先使用短期凭证和最小权限令牌。
- 依赖流量走内部代理。 开发者的安装请求必须经过内部受控仓库，不能直接解析公共网络上的包；确认 AI 辅助安装也遵循这条规则。
此外，考虑到 Shai-Hulud 已经能扫描 AI 工具的配置文件，安全团队还应检查：开发者的工作站内是否同时存放了多个环境（测试、预发、生产）的密钥？是否启用了密钥扫描（secrets scanning）并配置了告警？
小结
AI 编程助手正在从”智能补全”演变为”特权操作层”——它能读取仓库、调用终端、安装依赖、访问密钥。Mandiant 和 StepSecurity 的报告共同指向一个结论：当助手拥有执行权限时，它本身就成了攻击面。防御的关键不是阻止 AI 辅助开发，而是把助手纳入供应链安全体系，用校验、最小权限和内部代理来约束它的行为半径。
— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn
