微软下线数十个开源仓库：AI 编程工具的钥匙链被盯上了

微软这次下线的，不是一个没人维护的小项目。

TechCrunch 报道称，至少 70 个属于 Microsoft 的 GitHub 项目一度显示被禁用。微软的说法是：为调查潜在恶意内容，临时移除部分仓库；部分项目经审查后已经恢复，另一些仍保持离线。

刺眼的地方在范围。受影响项目涉及 Azure、Claude Code、Gemini CLI、VS Code 等 AI 开发工作流。黑客盯的不是普通用户界面，而是开发者每天打开、也最容易接触凭据的入口。

被下线的仓库，问题还没完全摊开

目前能确认的事实不多，但已经够开发团队停一下手。

安全公司 Cloudsmith 和社区恶意软件分析站点 OpenSourceMalware 较早标记了这次问题。它们称，恶意代码会在用户通过 AI 编程应用打开受影响工具时，窃取密码和其他敏感凭据。

这里必须收住判断。材料指向的是微软开源项目被入侵，不是 GitHub 这个平台被整体攻破。也不能断言所有被下线项目都已经中毒。

但这不影响风险等级。

因为开发者凭据一旦被偷，后果不会停在本地机器。它可能顺着 token、云账号、代码仓库、CI/CD、客户环境继续往里走。对云服务工程团队来说，这类事故最麻烦的地方不是删一个包，而是确认钥匙有没有被复制过。

AI 编程工具把钥匙集中起来了

传统供应链攻击，常见路径是污染依赖包。下游项目自动安装，攻击者等着收网。

AI 编程工具让这条路径变短了。

现在的开发工具不只是补全代码。它会读仓库、跑命令、连云资源、调用模型、访问本地配置。工具越贴近开发现场，越容易碰到环境变量、token、SSH key、API key。

这就是关键变量：AI 编程入口正在变成权限入口。

过去，一个被污染的依赖像混进仓库的坏零件。现在，一个被污染的 AI 开发工具更接近车间门禁。它不一定直接破坏产品，却可能摸到更多上游权限。

“天下熙熙，皆为利来。”攻击者也一样。哪里信任集中，哪里自动化程度高，哪里就会被反复打。

对 AI 开发者和云团队，现实动作很具体：

• 轮换近期可能被相关工具接触过的 token 和 API key。
• 检查本地环境变量、配置文件、CLI 凭据缓存。
• 回看近期是否拉取过被下线或随后恢复的仓库内容。
• 收紧 AI 编程工具默认可访问的云权限。
• 把高权限凭据从日常开发环境里拆出去。

采购和平台团队也会变谨慎。涉及 AI 编程助手、云插件、CLI 工具的引入，不会只看功能演示。更要看签名、溯源、权限边界、异常监控，以及出事后多久能证明清干净。

工具越聪明，权限越要笨一点。少给，短给，可撤销。

微软要证明的不是发现问题，而是清场

更难看的，是时间线。

5 月中旬，安全研究人员曾披露微软开源项目 Durable Task 被入侵。OpenSourceMalware 把这次最新事件称为 Durable Task 的 re-compromise。

这句话不能直接推成“同一批黑客又来了”。证据不够。更稳妥的说法是：要么上一轮没有清干净，要么出现了新的独立入侵。

哪一种都不轻。

大厂资源不等于供应链免疫。微软有安全团队，有 GitHub，有云基础设施，也有企业客户通知渠道。这些资源能提高发现概率，不能自动保证清场彻底。

微软临时下线仓库、审查后再恢复，这一步是对的。宁可短期打断访问，也不能让有疑点的代码继续挂在那里。对掌握大量开发者信任的大公司来说，慢一点恢复，比快一点安抚更重要。

我不太买账的是另一层：如果 AI 编程工具已经成了新入口，大厂还按传统开源维护节奏管理它，就会慢半拍。

过去开源信任主要靠声誉、协作和社区审查。现在不够了。还要持续溯源、强制签名、凭据最小化、异常行为监控，以及事故后能否拿出可验证的清场结果。

铁路早期扩张时，真正让行业稳定下来的不只是更快的车头，还有信号系统、调度规则和事故责任。这个类比不完全一样，但有一点相通：速度越快，治理越不能靠手感。

AI 开发工具也是这样。模型能力是车头，供应链治理是轨道。车头再猛，轨道松了，事故只会更贵。

接下来最该观察三件事：微软是否披露更清楚的影响范围；被恢复仓库是否有可验证的清理和签名机制；企业客户是否开始把 AI 编程工具纳入更严格的供应链审查。

微软这次被推到台前，只是因为它足够大。真正被拷问的，是所有想把 AI 编程入口做成生态的人：你让开发者把钥匙交给你，就得证明自己守得住钥匙链。