当供应链蠕虫学会用你的钥匙开门：tensorlake 投毒事件复盘

一条 npm 包被劫持，本身不算新闻。但当被投毒的包会偷走你的发布权限、再用你的身份去感染别人，事情的性质就变了。

10月8日，npm 生态中的 tensorlake 包被攻击者植入恶意版本 0.5.144，内嵌自复制供应链蠕虫 Shai-Hulud 的新变种[1][2]。它不只偷密钥——它把偷到的密钥变成下一轮传播的燃料。这件事值得每一个维护开源包、跑 CI/CD 的团队停下来看一眼：蠕虫已经学会了用开发者自己的钥匙开门。

⚠️ 一次投毒的完整链条

金句：最危险的供应链攻击，看起来就是一次再正常不过的版本发布。

先把事件本身拆干净。攻击者以 tensorlake 名义发布了 0.5.144 版本——这个版本号本身就是一个信号：它紧贴正常版本序列，混在常规迭代里几乎不引起注意。据 Snyk 威胁情报团队对样本的分析[2]，恶意代码嵌入后具备三类能力：窃取开发者环境中的机密信息、瞄准浏览器中存储的加密货币凭据、以及利用窃取到的发布凭据，沿关联的软件供应链继续扩散。

第三点是本次事件真正的分水岭。前两条是传统信息窃取的打法，属于「偷一次赚一次」；第三条意味着攻击不再是一次性事件，而是一个可以自续的循环——偷到 A 开发者的 npm 令牌，就能以 A 的身份污染 A 可控的其他包，再偷 B、C、D 开发者的令牌，指数级铺开。这正是 Shai-Hulud 首轮爆发（2025年9月中旬，波及超过 500 个 npm 包，包括 Zapier 等知名项目维护者的发布凭据）时被多家研究机构同时确认的传播机制[1][3][4]。

据 Socket、Snyk 等供应链安全研究团队对 2024—2025 年事件的跟踪复盘[1][5]，此类「凭据复用式传播」正是近一年多来供应链攻击最显著的变化：攻击者不再追求单点植入的隐蔽性，而是追求传播链的持续性。一次得手，等于拿到整个信任网络的路由表。

把这条传播链画出来是这样的：

“发布恶意版本 → 窃取开发者发布凭据 → 以开发者身份向其维护的其他包推送带毒版本 → 新版本被下游拉取 → 感染新的开发者环境 → 回到第一步继续循环

最后那步回环，是整个攻击的核心。判断一个团队是否真正理解供应链安全，就看它有没有为这根回环箭头做过防御设计。

从产业逻辑看，npm 这种「发布即分发」的机制，天然把包作者的个人凭据变成了整个生态的单点故障。包的下载量越大、被依赖越广，作者的一枚令牌的隐含价值就越高。这不是设计缺陷，是信任模型的结构性代价。

🦠 蠕虫化：从「埋雷」到「自己走路」

金句：木马在等人踩，蠕虫在自己爬。

Shai-Hulud 这个名字取自《沙丘》中的沙虫，业内给它贴的标签是「自复制供应链蠕虫」[1][3]。这个定语值得展开讲。传统投毒攻击的工作量模型是这样的：攻击者投毒一个包，等待下游项目更新依赖、构建、部署，然后收割。整个链条里，攻击者要做的是「埋雷」，扩散靠的是受害者自己的 CI 流水线。

而自复制蠕虫把「扩散」这一步也自动化了。新变种的传播路径非常清晰：感染开发者环境 → 抓取 npm 发布凭据 → 用该凭据向该开发者维护的其他包推送带毒新版本 → 新版本被下游拉取 → 再感染下一批开发者。每一环都不需要攻击者手动介入。首轮 Shai-Hulud 事件中，安全研究人员观测到的感染规模从数十个包扩张到五百余个，只用了约两天时间[1][3][4]。

这对防守方意味着两件残酷的事。

第一，响应窗口被压缩到小时级甚至分钟级。传统投毒事件里，安全团队通常有几天时间做通报、下架、排查；蠕虫化之后，从第一个恶意版本发布到第二波、第三波感染之间可能只隔几个小时。等你看到情报，传播树可能已经长了两层。

第二，排查边界从「一个包」变成「一张图」。应急响应时，问题不再是「0.5.144 有没有进我们的依赖树」，而是「过去 N 小时内，所有被感染的作者账号推送过的所有版本，哪些进了我们的依赖树」。排查对象从线变成了图，工作量不是一个量级。

业内私下流传一句话：「供应链攻击的止损速度，永远慢于蠕虫的传播速度。」这话有点悲观，但方向是对的——除非把防线从「事后下架」前移到「事前发布管控」。

💡 AI 基础设施，为什么先中枪

金句：谁离开发者的密钥最近，谁就先被蠕虫盯上。

tensorlake 并非消费级应用，它属于 AI 数据处理与 Serverless 数据管道方向的基础设施包，典型用户是构建 AI 应用和数据流水线的工程团队。这个定位决定了它的受害面：用户群小而精，但每一台开发机都是金矿。

理解这一点，要看清 AI 应用开发的工作流特征。AI 工程团队的开发环境里堆着什么样的东西？云厂商的长期访问密钥、模型 API Key、数据仓库凭据、CI/CD 令牌，还有——本次事件明确瞄准的[2]——浏览器里保存的加密货币钱包凭据（开发者的空投与链上收益，往往就躺在那里）。一枚被感染的包，等于在这类环境里开了一次全量清点。

更微妙的是 AI 包生态的结构性问题。AI 领域迭代快、包依赖链长、小作者多、版本发布频繁，许多包由个人维护者高频推送，发布流程里几乎没有摩擦。这对开发者是效率，对蠕虫是高速公路。背景数据可以佐证「密钥密度」这个判断：Sonatype《State of the Software Supply Chain》年度报告统计，2019 年以来累计发现的开源恶意包已超过 50 万个，且发布频率逐年加速，npm 是重灾区之一[6]；而其中与 AI、自动化工具链相关的包在近两年的占比持续走高[1][5]。原因不复杂：这里是密钥密度最高的地层。

从产业逻辑推演，AI 供应链会成为未来两三年攻防的主战场之一。原因是双向的：攻击侧，AI 开发环境的凭据价值密度全场最高；防御侧，AI 团队普遍年轻、跑得快，安全建设普遍滞后于业务速度。缺口就在这里。

对企业的直接启示是：如果你的团队在用 AI 数据处理、模型服务相关的第三方包，依赖清单里每一个高频更新的包，都值得做一次发布者身份与版本差异的核验。这不是偏执，这是本轮事件给出的最低成本功课。

🔐 防线要建在「发布」那一刻

金句：蠕虫偷的是钥匙，那防御就得管住每一把钥匙。

本次事件最值得记住的技术结论只有一条：一旦发布凭据可被盗取并复用，任何依赖「包内容审查」的防御都会被绕过——因为带毒版本是以合法作者身份、走合法发布流程上线的，签名是对的、账号是对的、版本号是连续的。

所以防御重心必须前移到凭据治理层。业界方向已经比较收敛：

• 短时凭据替代长期令牌：用 OIDC 类机制在发布时换取分钟级有效的临时凭据，蠕虫偷到的钥匙几分钟后作废。这条路径已经有成熟参照——PyPI 于 2023 年正式支持 Trusted Publishing[7]，npm 也在 2025 年下半年将 Trusted Publishing 与 provenance 机制推向正式可用[8]；
• 双因素与发布保护：对高下载量包强制 2FA，开启「可信发布」限制，新版本需通过既有环境签名验证；
• 最小权限的 CI：构建环境里的密钥按需授予、按包隔离，避免一个包被污染后全环境密钥裸奔；
• 发布延迟窗口：重要包的新版本设置数小时延迟可拉取期，给社区留出差异审计的时间；
• 行为侧检测：对「同一账号短时间向多个包推送版本」这类蠕虫特征签名建立监控。

这套防御清单里，OIDC 短时凭据和硬件密钥保护技术门槛不低，但它们是少数直接打在蠕虫传播机制上的手段。行为检测门槛更高但价值不稳定——蠕虫特征会变，凭据有效期这条腿是砍不断的。

对企业安全负责人，还有一个组织层面的判断：开源供应链风险不再只是工程师的个人卫生问题，而是公司级风险。开发者个人 npm 账号被盗，传导路径会直达公司的云基础设施和资金侧（加密货币凭据被盯上就是明证[2]）。把包发布凭据纳入公司密钥管理体系统一治理，是本次事件后应该立刻排上的事项。

📈 供应链安全，正从「卖点」变成「门槛」

金句：每一次蠕虫爆发，都是安全市场的一次需求确认。

回到产业视角。近两年，开源供应链安全赛道的产品形态大致分几层：依赖扫描（SCA）已经是红海，Snyk、Mend、各家云厂商原生方案卷价格；软件物料清单（SBOM）在合规推动下成为标配（美国行政命令 14028 与欧盟《网络弹性法案》都在推 SBOM 落地[9]）；而真正稀缺的是发布侧治理——短时凭据、可信发布、发布行为风控，这一层目前生态位还比较空。

需求侧的数据并不缺。Gartner 早在 2022 年就预测，到 2026 年将有 45% 的全球组织遭遇过软件供应链攻击，较 2021 年增长三倍[10]；Sonatype 的统计则显示恶意开源包的累积数量在近两年呈陡峭上升曲线[6]。Shai-Hulud 蠕虫化事件，客观上是在为发布侧治理「做需求教育」：当攻击从「污染一个包」升级为「劫持一个发布体系」，企业买单的理由就从「合规要扫依赖」变成了「业务会被打断」。安全行业的老规律：威胁进化一步，市场分化一层。

可以预判两个走向。其一，包管理平台会把可信发布、短时凭据从可选项变成默认项——就像 HTTPS 之于 Web，安全机制最终会沉淀为基础设施属性，而非增值服务（npm 与 PyPI 的 Trusted Publishing 路线已经在验证这个方向[7][8]）；其二，针对 AI 供应链的专项治理会成型，因为 AI 包生态的密钥密度和更新频率，决定了它需要一套独立的风险评级体系。

给从业者一句冷静的提醒：不要把希望寄托在「下一次情报通报更快」上。情报永远滞后于蠕虫，结构性的钥匙治理才是唯一跑得赢传播速度的防线。

小结：中招之后，钥匙必须立刻失效

tensorlake 事件的技术细节并不复杂，但它标记了一个转折：供应链蠕虫已经完成「偷凭据—用凭据—再传播」的闭环，攻击的自动化程度逼近真正的流行病模型。防守的核心不再是「别中招」，而是「中招后钥匙立即失效」。

给团队留一份可以今天就开始的动作清单：

1. 排查组织内所有 npm 账号是否启用了 2FA 与 Trusted Publishing；

2. 替换所有长期有效的 npm / CI 发布令牌为 OIDC 短时凭据；

3. 对照 0.5.144 版本与发布时间窗，审计本轮事件波及的依赖树；

4. 将包发布凭据纳入公司级密钥管理体系，与云凭据同权重治理。

接下来一年，短时凭据与可信发布能否成为 npm、PyPI 的默认能力，将决定这类事件的量级是「事故」还是「疫情」。

参考信源

[1] Socket Research Team, Shai-Hulud: The Second Coming — npm 蠕虫二度爆发分析， socket.dev/blog, 2025年10月

[2] Snyk Threat Intelligence, tensorlake 0.5.144 恶意版本与 Shai-Hulud 新变种技术分析， snyk.io/blog, 2025年10月

[3] Wiz Research, Shai-Hulud: npm 生态首个自复制供应链蠕虫事件复盘， wiz.io/blog, 2025年9月

[4] Aikido Security / Snyk 事件通报：首轮 Shai-Hulud 波及 500+ 个 npm 包（含 Zapier 等项目维护者凭据被复用），2025年9月

[5] CISA（美国网络安全和基础设施安全局）就 Shai-Hulud 蠕虫发布的公开安全预警， cisa.gov/news-events/alerts, 2025年9月

[6] Sonatype, State of the Software Supply Chain（2024/2025 年度报告），恶意开源包累计发现量超过 50 万个

[7] PyPI 官方文档与 PyPI 博客：Trusted Publishing（基于 GitHub Actions OIDC 的短时发布凭据）正式支持，2023年

[8] GitHub Changelog / npm 官方文档：npm Trusted Publishing 与包 provenance 签名机制发布说明，2025年

[9] 美国第 14028 号行政命令（Executive Order 14028, 2021）与欧盟《网络弹性法案》（Cyber Resilience Act, 2024）中关于 SBOM 的合规要求

[10] Gartner, How to Manage Software Supply Chain Security（2022）：预测 2026 年 45% 的全球组织将经历软件供应链攻击，较 2021 年增长三倍