微软开源工具被植入窃密代码：AI 工程师成了供应链攻击的靶心

概述

微软切断了自己托管在 GitHub 上的几十个开源项目的访问，因为攻击者疑似攻入了这些项目、并往代码里注入了窃取密码的恶意软件。据 TechCrunch 报道，受影响的项目里很多与微软的云服务 Azure 相关，还有一批是开发者配合 AI 编码应用使用的工具，文中点名的就有 Claude Code、Gemini 的命令行界面、以及 VS Code。最先发出预警的安全公司 Cloudsmith 和社区恶意软件分析站 OpenSourceMalware 指出，当用户在自己的 AI 编码应用里打开这些被污染的工具时，恶意代码就会窃走用户的密码和其他敏感凭证。

这件事的判断很直接：攻击者没有去碰模型、没有去碰算法，而是去碰了 AI 工程师每天都要 import、要 npm install、要在终端里跑的那些工具。靶心不是技术的最前沿，是技术的最日常。一个开发者一天里要信任几十个不显眼的依赖，攻击者只需要污染其中一个被频繁拉取的，就能站在你的开发机里。微软确认下架了仓库，称这是「临时移除部分仓库以调查潜在恶意内容」，部分已在审查后恢复，部分仍可能下线。

发生了什么

按 TechCrunch 的梳理，事情的形状是这样的：攻击者攻入了微软在 GitHub 上的开源项目，把窃取凭证的代码塞进了项目代码里；这些项目相当一部分围绕 Azure，以及那些被开发者拿来配合 AI 编码工具用的组件。触发条件不是「下载即中招」那么夸张，而是当用户在 AI 编码应用里打开、加载这些被篡改的工具时，恶意逻辑随之运行，把密码和凭证回传给攻击者。报道明确说，目前还不清楚有多少人下载了受影响的工具。这是一个诚实的「未知数」，不是被淡化的数字。

规模上有一个能看见的硬数据：尝试访问这些项目页面时，GitHub 返回的提示显示，微软名下至少 70 个项目已被「停用」，提示语是「该仓库的访问已被 GitHub 工作人员因违反 GitHub 服务条款而禁用」。微软发言人 Ben Hope 对 TechCrunch 表示，公司已通知了「少量可能从受影响仓库拉取过内容的客户」，并称若后续发现需要客户采取行动的情况，会通过既有支持渠道直接联系。被问到具体有多少客户受影响时，微软没有立即给出数字。

70 这个数字值得停一下。它不是受害者人数，而是被下架的仓库数，这两者经常被混为一谈，但意义完全不同。70 个仓库被禁用说明的是污染面之广、清理动作之大，而不是有 70 个用户中招。真正的受害规模（多少人拉取、多少凭证外泄）按报道是个未知数，微软也没披露。把「下架 70 个仓库」读成「70 个受害者」或「70 万次下载」，都是源里没有的杜撰。建设者在评估自己是否受影响时，应该问的是「我有没有从这些仓库拉过东西」，而不是被一个仓库计数吓到。

还有一个细节决定了这次事件的性质。据 Ars Technica，这已是微软近几周内第二起已知的开源项目被攻破：五月中旬，安全研究者称微软的开源项目 Durable Task（一个帮开发者构建应用的工具）被黑；OpenSourceMalware 表示本次最新事件是对 Durable Task 项目的「再次攻陷」，暗示微软第一次可能没把攻击者彻底清出去，也可能是另一起独立的新入侵。无论哪种，结论都不乐观：要么残留没清干净，要么攻击者把同一资产当成了可反复利用的入口。

为何重要

先把这件事放进它所在的趋势里。报道说，这是近几个月里又一个例子：攻击者攻破广受欢迎的开源项目，目的是在大量「电脑里装了这些代码」的用户身上植入恶意软件。这类攻击被称为「供应链」攻击，因为它们瞄准的是那种被大量软件产品复用、或被某一类特定用户使用的代码。报道点破了攻击者的算计：这类用户「有时手握云系统的访问权和大量客户数据」，攻下他们很划算。这一句，就是整起事件的内核。

把这句话翻译成 AI 工程师的现实：你这台开发机不是一台普通电脑。它上面很可能存着云厂商的长期凭证、模型仓库的拉取/推送 token、生产数据库的连接串、CI 的部署密钥、以及一串能直接花钱的 API key（模型推理、向量库、各种 SaaS）。攻击者偷的从来不是「密码」这个抽象物，而是密码背后那串能调用算力、能动模型权重、能碰生产数据的权限。AI 工程师的开发机，正在变成一个权限密度极高的目标，一次得手的回报，远高于攻一台普通办公电脑。

这件事还重要在它击穿了一个长期被默认的信任假设。报道特意指出：开源项目的「单兵作者」被盯上并不稀奇，有时攻击者会用很长时间去骗取作者信任；但像微软这样有资源防御此类攻击的大科技公司被攻破，是罕见的。很多团队的供应链信任模型其实是「按来源打分」：来自微软/谷歌官方组织的包，默认更可信，审计更松。这次事件直接打掉了这个默认值。供应链信任不应该建立在「谁发布的」，而应该建立在「这个版本我验证过没有」。当一个被高度信任的来源被攻破，所有把信任外包给它的下游，同时暴露。

对建设者的影响

第一，把供应链审计从「上线前跑一次」改成「持续的、有版本钉死的」。这次的教训不是「别用微软的包」，而是「别因为是微软就跳过校验」。落地动作很具体：依赖锁定到带哈希校验的精确版本（lockfile + integrity），让一次悄悄的重新发布无法在你不知情时被拉进来；对关键依赖开启版本钉死，不自动跟最新；在 CI 里加一道依赖差异审查，新增或跳版的依赖要有人看一眼。本次事件被描述为对 Durable Task 的「再次攻陷」，意味着「这个包上次没事」不能成为这次免检的理由。

第二，按最小权限重排你开发机和 CI 上的每一份凭证。攻击者的目标是凭证，那防御的重心就该是「就算这台机器被攻下，攻击者能拿到的权限尽量小」。具体来说：开发机上不要躺着生产环境的长期密钥；云凭证用短时效、按需获取，而不是写死在环境变量或 ~/.aws/credentials 里长期生效；模型仓库和包仓库的 token 拆成只读拉取与可写推送两套，日常只给只读；CI 的部署权限收敛到具体仓库、具体环境，而不是一个能动一切的万能 token。最小权限不会阻止入侵，但它决定了入侵的爆炸半径。这次「窃取凭证」之所以是重灾，正因为太多凭证权限过大且长期有效。

第三，把密钥轮换当成例行操作，而不是事故后的应急。如果你近期从受影响的微软仓库拉取过内容（报道说微软已主动通知了「少量」这样的客户），那么稳妥的做法是当作凭证可能已外泄来处理：轮换那台机器上触手可及的所有 token 和密码，尤其是云、模型仓库、生产数据库、以及计费型 API key。更重要的是把轮换变成习惯：定期轮换、凭证泄露时能一键吊销重发，这样未来任何一次类似事件，你的应对都是「轮换一遍」而不是「赔上一切」。同时建议给计费型 API key 设上用量与花费告警，凭证被盗后最先冒头的信号，往往是账单异常。

第四，给「凭证被读取」这件事加一层可观测。终端里打开一个工具就被偷走密码，可怕之处在于它悄无声息。建设者能做的是让悄无声息变得可见：监控对凭证文件、.env、密钥目录的异常读取；监控开发机和 CI 的异常对外网络连接（凭证总要被回传到某个地址）；给关键账户开启登录与异常行为告警。检测不能替代预防，但它把「我们什么时候才知道出事了」从几周缩短到几小时，而对供应链攻击来说，这段时间差就是损失的大小。

该忽略什么

别忽略，但要正确解读那个 70。前面说过：70 是被下架的仓库数，不是受害人数，更不是下载量。看到这个数字时，正确的反应是去核对自己的依赖清单和拉取记录，而不是按这个数字去估算「行业有多少人中招」。源里没有这个数字，任何换算都是编的。

忽略「微软被黑所以微软的东西不能用了」这种过度反应。这次罕见正是因为微软这种体量的公司有资源防御却仍被攻破，但结论不是「弃用微软生态」，那既不现实也不解决问题，因为下一个被攻破的可能是任何一个你高度信任的来源。正确的结论是把「信任来源」换成「信任经过校验的版本」，这个改动对所有供应链依赖通用，与是不是微软无关。

忽略一切「这是某国家级 APT、用了某 0day、某 CVE」的细节加戏。截至报道，公开事实就是：攻击者攻破了微软的开源项目、注入窃取凭证的代码、至少 70 个仓库被停用、受害规模未知、且本次疑为对 Durable Task 的再次攻陷。归因、漏洞编号、攻击手法的具体技术细节，源里都没有。在这些信息坐实之前，把精力花在「按上面四条把自己的供应链和凭证收拾干净」，比追攻击者是谁有用得多。你能控制的是自己的爆炸半径，不是别人的攻击意图。

技术要点

这起事件把「供应链信任」最脆弱的一环摆到了台面上：开发者对依赖的信任是传递性的，而传递性信任默认是不设防的。你信任微软，于是信任微软发布的包，于是在 AI 编码应用里打开它时不假思索地给了它运行权限，而那个运行环境里就放着你的凭证。攻击者要做的，只是攻破这条信任链上游的一个点。Durable Task 的「再次攻陷」更说明，被攻破的资产如果没被彻底清理，会成为可反复利用的入口。

工程上能落地的对策有清晰的优先级。先做收敛爆炸半径的事，因为它即使在你已经中招的情况下也仍然有效：开发机与 CI 上凭证最小权限、短时效、可快速吊销轮换。再做缩短依赖信任窗口的事：lockfile + 完整性校验把版本钉死，关键依赖的更新走人工审查，不盲目跟最新。最后补上可观测：监控凭证文件的异常读取与异常外联，给计费型 key 设花费告警。这三层的关系是：预防降低中招概率，最小权限决定中招代价，检测决定你多快知道。三者都不完美，但叠起来，能让下一次同类事件从「赔上密钥库」变成「轮换一遍、当天收工」。

来源

1. Microsoft's open source tools were hacked to steal passwords of AI developers / news
2. Hacker News discussion (551 points) / hn

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。