前言
上周一晚上，我工作到很晚，我三天前创建的监控工具发来了 Slack 警报。全球最受欢迎的 npm 软件包之一。
我的心跳开始加速，我知道每一秒都很重要，必须做出反应，限制伤害。但老实说，这太疯狂了，我以为一定是假阳性。尽管它看起来非常明显是恶意的，但我还是检查了好几次，又重新检查了一遍。
这不是假阳性。这是 npm 有史以来最大的供应链泄露事件之一，据推测是朝鲜国家行为者所为。我们利用人工智能读取差异的能力，在周五下午在我的笔记本电脑上运行了一个概念验证。
我想分享整个故事。我们是如何走到这一步的，我建造了什么，以及为什么我认为公开分享会让大家更安全。
我一直在担心供应链问题
最近发生的一些供应链事件着实让我彻夜难眠。供应链妥协是一个棘手的问题。在 Elastic，我们有这么多开发人员，我们的安全客户信任我们来保护他们。很显然，现状已经被打破，我们需要一些新的技术或程序来帮助我们。我曾有过一些想法，希望建立一个更值得信赖、经过人工智能审核的生态系统，以应用程序控制为原则，同时限制成本和摩擦。
但我真正注意到的是特里维的妥协。3 月 19 日，一个名为 TeamPCP 的组织入侵了aquasecurity/trivy-actionGitHub 行动（即流行的 Trivy 安全扫描仪，没错，一种安全工具）。他们注入了一个从 CI/CD 管道中获取机密的凭证窃取程序。大量凭证被盗。
这种情况迅速蔓延。3 月 24 日，LiteLLM 遭到袭击。TeamPCP 通过中毒的 Trivy 管道窃取了 LiteLLM 的 PyPI 发布凭据，并利用这些凭据推送恶意版本，这些版本是积极的凭据窃取者。SSH 密钥、云证书、API 密钥、钱包数据，应有尽有。
LiteLLM 是我自己使用过的一个软件包。因此可以说，那时我晚上完全"。"
我知道，由于 Trivy 漏洞泄露了所有证书，肯定还会有更多。我们需要做一些事情来保持领先。这既是为了我们的客户，也是为了保护 Elastic。
周五，红眼航班后
我刚从旧金山的RSAC 2026会议飞回来。周四晚上的红眼航班。如果你参加过四天的会议，你就会知道我当时的状态。不过，我还是一如既往地对新项目感到兴奋，所以我坐下来敲定了 v0.0.1。
设计理念：监控推送到软件包仓库的变更。运行差异，看看有什么变化。使用 AI/LLM 确定更改是否为恶意更改。基本上就是这样。
管道看起来像
- 从 PyPI 的更新日志 API 和 npm 的 CouchDB
_changesfeed 中查找新发布的版本。 - 根据下载次数排在前 15,000 位的软件包观察列表进行筛选
- 直接从注册表下载新旧版本（无需安装 pip、无需安装 npm、无需执行代码）
- 将它们转换成标记符报告
- 将差异发送至 LLM："，这是恶意的吗？"
- 如果是，向 Slack 发送警报
我想把重点主要放在顶级软件包上，因为无论如何，攻击者最有可能去的地方就是那里，而且在令牌和计算方面的成本要低得多。在我的笔记本电脑上运行完全没问题。
为什么选择光标
市场上有很多代理线束。我已经为人工智能恶意软件逆向工程等项目编写了自己的程序。但我的时间很紧，所以我选择使用Cursor，因为它是我的主要开发工具之一。Agent CLI 允许你以编程方式调用它：传递一个工作区、一条指令和一个模型。我在ask 模式（只读）下运行它，因此它只能读取差异，而不能修改任何内容。整个分析步骤是一个子进程调用。
提示很简单。我告诉它要查找什么（混淆代码、base64、执行/评估、意外网络调用、隐匿、持久性机制、生命周期脚本滥用），并要求它用Verdict: malicious 或Verdict: benign 进行回应。分析判决，采取行动。
关于模型选择
我通常使用 Opus 4.6 或 GPT 5.4 处理大部分事务。Opus 尤其适用于以网络安全为重点的任务。但对于每小时需要分析几十个版本的工作来说，我希望降低成本。
Cursor 团队最近发表了几篇非常不错的博文，一篇是关于代理工具的快速 regex 搜索，另一篇是关于他们的实时 RL 方法，在这种方法中，他们使用实际的生产推理标记作为训练信号，大约每五个小时部署一次改进的检查点。真正令人印象深刻的工程设计。
因此，我想试一试作曲家 2 。我使用的是快速模式，速度确实很快。非常适合实时使用。成本低、速度快、效果好（在我的测试中）。
在 Telnyx 上进行测试
你必须对这些东西进行测试，才能知道它们是否真的有效。这通常意味着要对提示进行大量调整。
我在时间上很幸运（或者说不走运）。就在我制作这个软件的同一个星期五， telnyx PyPI 软件包 被 TeamPCP 入侵了 。他们在_client.py 中注入了 74 行恶意代码：将有效载荷隐藏在 WAV 音频文件中（隐写）、base64 混淆、伪装成msbuild.exe 的 Windows 持久性植入以及向硬编码 C2 的渗透。
我使用合法软件包和恶意telnyx 软件包之间的差异来创建初始提示。该模型非常善于识别类似的恶意变化。我还想在检测到入侵时立即知道，因此我添加了 Slack 报警功能。
星期一晚上
我让它在周末运行。它翻阅了发布的信息，所有信息都是良性的。
如果你从事过网络安全方面的检测工作，就会觉得这很奇怪。我们通常会被 FP 淹没。我有意指示 LLM 只对"高置信度的" 供应链泄露事件发出警报，因为它们一般都是一触即发的。仍在捕捉 Telnyx 测试用例，没有 FP。样本量如此之少，可能是过度拟合，但没有时间建立更稳健的方法。
然后，周一晚上，工作到很晚的时候，Slack 上传来了警报。
🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4它真的发现了近期记忆中最大的供应链漏洞之一吗？
我检查了分析结果。重新检查。又检查了一遍。攻击者入侵了维护者的 npm 账户，将电子邮件更改为他们控制的 ProtonMail 账户，并发布了两个恶意版本（1.14.1 和 0.30.4）。他们没有直接向 Axios 注入代码。相反，他们添加了一个名为plain-crypto-js 的幽灵依赖项，该依赖项会运行安装后钩子，部署跨平台恶意软件。这显然是恶意的。
答复
我立即联系了我们的信息安全团队和 Elastic 的研究团队，让他们开始工作。我知道每一秒都很重要。原来，当我联系他们时，他们已经收到了安装了恶意软件包的主机上的 Elastic Defend 警报，并正在积极响应。但当时没有人意识到问题的严重性，也没有人从根本上了解机器是如何被感染的。监测工具提供了这一缺失的背景。
我试着给security@npmjs 发送电子邮件，结果被退回。尝试向其安全门户网站提交，但出现错误。我绝望地发了一条推特，希望能联系上一个人。我还迅速在 axios 软件仓库本身打开了一个安全问题。
后来，我看到了另一位研究人员的推文，他观察到了这一漏洞，我意识到我更多地是把它当作一个漏洞，而不是供应链事件来处理。脆弱的你悄无声息地协调着。目前，在人们的机器上安装恶意软件的破坏活动十分活跃，因此，采取广泛而开放的方式是正确的选择。于是，我立即把我整理的所有细节都告诉了 X。
我们甚至开始收到遥测警报，显示野外受影响的组织。那东西正在积极运行。
幸运的是，Axios 团队很快就发现了这一问题，并迅速撤下了包装。此外，攻击者的 C2 服务器也收到了大量请求，以至于服务器崩溃。情况可能会更糟。
我们的 Elastic Security Labs 团队发布了有关此次入侵的完整技术文章。第一部分涉及端到端攻击链、跨平台恶意软件和 C2 协议：Axios 供应链泄露内幕--一个 RAT 掌控一切。其次是跨 Linux、Windows 和 macOS 的狩猎和检测规则：Elastic 发布了针对 Axios 供应链漏洞的检测规则。
何去何从
现在的情况并不乐观，作为整个软件生态系统，我们需要做得更好，更不用说安全行业了。
三月的两周后
- Trivy（一款安全扫描仪）被入侵，窃取了 CI/CD 秘密
- LiteLLM 就是利用这些被窃取的机密被破解的
- Telnyx 也在同一行动中遭到破坏
- Axios 是 npm 中最受依赖的软件包之一，已被疑似朝鲜行为者入侵
- 还有更多
包裹登记处是重要的基础设施。运行 PyPI 和 npm 的团队做了大量工作，但威胁已经超出了当前信任模型所能应对的范围。我们需要更好地自动监控软件包的更改。不仅仅是签名扫描，还要真正理解代码的作用。正如这个项目所显示的，法学硕士在这方面确实很擅长。我们需要在漏洞发生后更快地进行凭证轮换。从特里维到利特尔姆再到泰尼克斯的连锁反应之所以会发生，是因为被盗信条的轮换速度不够快。
您现在可以做的一件实事是：不要立即拉入软件包更新。添加浸泡时间。让新版本放置一段时间，然后再进行构建。我们在 Elastic 的 CI/CD 系统中就是这么做的，这也是对 shai-hulud 的回应。这并不能阻止一切，但它能让社区有时间在入侵 CI/CD 管道和开发人员的机器之前捕捉到漏洞。好消息是，许多软件包管理器都为此添加了本地支持。例如，执行 7 天的延迟：
npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"我们正在开源
我们正在发布工具：供应链监控器
我想直言不讳。这是一个概念验证。我不眠不休，一个下午就完成了它。我并不指望任何人将其用于生产。它需要 Cursor 订阅来进行 LLM 分析，按顺序处理发布，并且监视列表是静态的。
但这种方法是行之有效的。实时比较软件包的发布情况，并使用人工智能对变更进行分类，捕捉到了针对 npm 中最流行软件包之一的供应链攻击。
我之所以与大家分享这些经验，是因为我们的经验对社区来说是最好的借鉴。如果有人采纳了这个想法，并创造出更好的东西，那就太好了。如果软件包注册团队将其纳入自己的管道，那就更好了。如果这意味着别人下次能省下一大笔钱，那就值得了。
工作原理（供好奇者参考）
监控：两个线程轮询 PyPI（通过changelog_since_serial() XML-RPC）和 npm（通过 CouchDB_changes feed）。符合 Top-N 观察列表的新版本会被排在队列中。状态持续到last_serial.yaml ，因此它可以从上次中断的地方继续运行。
差异化：直接从注册表 API 下载新旧版本。无需安装 pip/npm，无需执行代码。提取归档文件，对文件进行散列，以 markdown 格式生成统一的差异报告。
分析：Diff 报告以只读模式进入 Cursor Agent CLI。提示要求它查找供应链指标。为判决解析的输出。
警报：恶意判决会触发 Slack 消息，其中包含软件包名称、等级、注册表链接和分析摘要。
本项目之外的人工智能在安全领域的应用
供应链安全是个大问题，但我们并非无能为力。人工智能为我们提供了以机器速度进行大规模防御的新工具。这个项目是使用人工智能帮助解决安全问题的一个例子，但我们在整个 Elastic Security 更广泛的范围内使用人工智能开展了许多有趣的工作。我想强调的一点是：我们的团队最近发布了一篇关于使用攻击发现、工作流和代理生成器自动检测和确认 APT 级攻击的文章。这显示了 Elastic Platform 的强大功能，它提供了代理安全功能，在我们集体被攻击淹没的时候，有效地提高了 SOC 的效率和效力。
供应链监控器项目见github.com/elastic/supply-chain-monitor。
感谢 Elastic Infosec 团队的快速事件响应，感谢 axios 维护人员的快速拆除，感谢安全社区的集体努力限制了爆炸半径。