文章总结： 2025至2026年软件供应链攻击呈指数级增长，进入自我繁殖的蠕虫时代，攻击者从投毒软件转向攻击构建工厂，劫持信任组件并窃取CI/CD凭证。核心风险在于恶意包与漏洞包本质不同，且攻击面已扩展至开发者端点、流水线及云运行时。防御需从依赖锁定、内存凭证保护及构建物料清单（PBOM）入手，应对信任模型错配与长期凭证泄露问题。 综合评分： 92 文章分类： 供应链安全,威胁情报,安全运营,安全建设,数据安全
每 3 天一起投毒：软件供应链攻击正式进入「蠕虫时代」
原创
威胁情报中心 威胁情报中心
奇安信威胁情报中心
2026年8月24日 15:22 北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
供应链安全 · 深度复盘
每 3 天一起投毒 软件供应链攻击正式进入「蠕虫时代」
复盘 2025–2026 年开源供应链攻击：当攻击者不再投毒软件，而是投毒「制造软件的工厂」
· 深度技术报告 · 供应链安全 · 2026
npm install 大概是今天全球开发者执行次数最多、思考次数最少的一条命令。
敲下回车，几百上千个依赖包顺着依赖树倾泻而下，装进你的笔记本，或者装进某台 CI 构建服务器。没有人会逐个审计这些包的代码——我们默认它们就是它们自称的样子。
过去 12 个月发生的一切，正在把这份默认的信任变成攻击者最廉价的入场券。安全机构 StepSecurity 的威胁情报团队在过去一年里确认并告警了 56 起真实的供应链攻击；Palo Alto Networks Unit 42 的研究则指出，过去 12–18 个月，这类攻击的规模和速度发生了「断崖式的转变」——攻击者不再执着于在成品软件里找漏洞，而是直接把矛头对准了构建软件的工厂本身：开发者的笔记本、CI/CD 流水线、以及流水线上流淌的凭证。
这篇文章不谈理论，只复盘事实：这一年里攻击是怎么演化的、钱和凭证是怎么被偷走的、以及为什么传统的「扫描一下依赖」已经拦不住它们了。
01 从「每月一起」到「每三天一起」
先把时间轴拉直。2025 年 8 月到 2026 年 8 月，StepSecurity 逐月统计了经人工确认、并实际向客户发出告警的供应链攻击数量：
· 2025 年 8 月 – 2026 年 2 月：大约每月一起，属于「偶发事件」级别；
· 2026 年 3 月：单月暴增至 13 起；
· 此后维持高位：4 月 9 起、5 月 9 起、6 月 10 起、7 月 6 起——平均每月 9 起，约每 3 天一起。
把这个周期切成两半对比会更刺眼：2025 年 8 月到 2026 年 1 月的半年里只有 6 起；而 2026 年 2 月之后的六个半月里有 50 起。增幅超过 8 倍，且没有回落的迹象。
图 | StepSecurity 威胁情报逐月确认的供应链攻击数（2025.08–2026.08），2026 年 3 月起明显跃升（图：StepSecurity）
频率之外，单起事件的「战果」也在膨胀。2026 年 3 月 19 日至 24 日，威胁组织 Team PCP 用五天时间跑完了一个简单粗暴的循环：投毒一个被广泛信任的组件 → 植入凭证窃取器 → 收走 CI/CD 构建机加载进内存的密钥 → 用这些密钥投毒下一个组件。2026 年 8 月，CloudSEK 公布了这次行动的受害者数据集，StepSecurity 分析后得到的总数是：
78,330 个被盗密钥，涉及 2,186 家组织，其中包括 92 家上市公司——合计市值约 6.2 万亿美元。
一个攻击者，五天时间。这就是 2026 年供应链攻击的单价。
图 | Team PCP 五天行动的关键数字（图：StepSecurity，数据源 CloudSEK 受害者数据集）
02 一个重要的概念分界：「恶意包」≠「有漏洞的包」
在讨论怎么防之前，必须先厘清一个被反复混淆的概念，因为它直接决定防御应该放在哪里。
有漏洞的包（vulnerable package）是一个诚实的错误。 Log4j 是经典例子：代码里有个缺陷，攻击者将来可能利用它——前提是漏洞代码路径在你的生产环境里真的可达。所以传统软件成分分析（SCA）盯着生产环境扫描，逻辑上是对的，因为那是漏洞真正会被利用的地方。
恶意的包（malicious package）就是攻击本身。 它不需要等你部署到生产——在开发者笔记本或 CI 构建机执行 npm install 的那一刻它就运行了，凭证当场被偷走，窃密行为甚至发生在依赖解析完成之前。等一个恶意依赖「到达生产环境」时再被发现，凭证早就不在了。
图 | 漏洞包与恶意包的本质区别（图：StepSecurity）
还要注意统计口径：这 56 起事件不包含 CVE 漏洞披露，也不包含从第一个版本就是恶意的抢注包（typosquat）——那些李鬼包从未获得过任何人的信任。真正造成大规模破坏的，是攻击者劫持你已经在信任的组件：要么发布可信包的下一个恶意版本，要么在允许静默改标签的生态里直接重定向现有版本，然后顺着既有的信任通道，直接开进成千上万条构建流水线。
03 蠕虫编年史：攻击开始「自我繁殖」
这一年攻击加速的最大推手，是自我传播。时间线值得完整列一遍，因为每一代蠕虫都带来了新东西：
图 | 一年间的自我传播供应链蠕虫时间线（图：StepSecurity）
2025 年 9 月 · Shai-Hulud——第一只生态级 npm 蠕虫。 通过 postinstall 钩子执行一个约 3.6 MB 的 bundle.js，调用合法密钥扫描工具 TruffleHog 搜刮 GitHub/npm 令牌和 AWS/GCP/Azure 云凭证，用受害者的 npm 令牌自动污染其维护的所有其他包——一个被钓鱼的维护者，瞬间变成几十个被污染的包。超过 500 个包遭殃，CISA 为此专门发布警报。
2025 年 11 月 · Sha1-Hulud（第二波）。10 MB 级混淆载荷，伪装成 Bun 安装器的 setup_bun.js 经 preinstall 触发，受害者包括 Zapier、ENS Domains 等知名项目；除了窃取多云密钥管理服务中的机密，还会把受害主机注册成名为 SHA1HULUD 的自托管 GitHub Actions Runner 实现持久化，并带有「死亡开关」——一旦无法正常外联就销毁宿主数据。后来它甚至在 CNCF 的 Backstage 仓库里被检测到。
2026 年 3 月 · CanisterWorm。在 npm 传播后门，技术上最大的亮点是使用 Internet Computer Protocol（ICP）区块链容器（canister）作为 C2 地址解析器——由于区块链基础设施无法通过常规滥用投诉或注册商渠道下架，这一手直接提高了基础设施反制的门槛。
2026 年 4–5 月 · Mini Shai-Hulud 系列（TeamPCP）。4 月底先打 SAP 相关包，5 月 11 日打 TanStack（42 个包、84 个恶意版本，发布窗口仅约 6 分钟），5 月 19 日打 AntV 生态（600+ 恶意版本，其中 317 个包在约 22 分钟内集中发布）。TanStack 事件尤其值得记住：攻击者滥用了 pull_request_target 工作流配置缺陷和 GitHub Actions 缓存投毒，直接从 Runner 进程内存中提取 OIDC 令牌发布恶意包——这些恶意包携带的是完全合法、能通过验证的 SLSA Build Level 3 来源证明。只靠来源验证，根本无法区分它们和正常版本。
2026 年 6–7 月 · Miasma。Mini Shai-Hulud 的变种，把触发器从「安装时脚本」扩展到了「打开仓库即触发」：它在源码仓库里种下针对 Claude Code、Gemini CLI、Cursor、VS Code 和 npm test 的五个配置文件，开发者用这些工具打开仓库，4 MB 级的混淆凭证窃取器就会自动执行。6 月 5 日，微软 Azure、Azure-Samples、Microsoft、MicrosoftDocs 四个组织的 73 个仓库被波及，GitHub 在 105 秒内批量禁用——被禁用的包括 Azure/functions-action，全球大量依赖它的部署流水线当场瘫痪。7 月，它又在 AsyncAPI 生态重现。
2026 年 8 月 · ChainDrop。投毒 keyv、cacheable-request 等被广泛使用的缓存库——CSA（新加坡网安局）通告称超过 1,300 个包版本被污染，合计对应约 20 亿次月下载量。这只蠕虫代表了当前技术的集大成者，值得单独解剖（见下一节）。
蠕虫改变的是数学。过去的供应链攻击是「一次投毒、一个受害包」；现在是「一个维护者被钓鱼 → 他能发布的所有包被污染 → 装这些包的受害者的令牌又被偷走 → 他们能发布的所有包继续被污染」。每一次事件不再是孤立的点，而是会自我增殖的感染源。
图 | 蠕虫传播引擎
04 解剖 ChainDrop：一只蠕虫的三段式攻击链
Unit 42 对 ChainDrop 的技术分析，几乎是当前 npm 蠕虫标准战术的教科书样本。先把全流程展开成一张图，再逐段拆解：
图 | ChainDrop 三段式攻击链全流程
整条攻击链分三步：
1钩子（The Hook） —— 攻击者篡改包的清单文件，植入一个恶意的 preinstall 脚本。这个脚本会下载合法的 Bun 运行时（一个正规、带签名的 JavaScript 运行时），用它静默启动一个 727 KB 的混淆载荷。用合法运行时执行恶意代码，既能绕过依赖 Node.js 环境的假设，也让杀软看到的只是一个正常程序在运行。
2窃取（The Theft） —— 蠕虫没有满足于扫磁盘文件——一个隐藏的 Python 脚本会直接读取 GitHub Actions Runner 的活进程内存，抓取临时的 OIDC 令牌和各类机密，同时对本地开发者凭证做地毯式搜刮。这一步的技术含义很清楚：现代 CI 的高价值凭证是临时的、不落盘的，想偷它们就必须读内存，磁盘扫描根本找不到目标。
3传播（The Payload） —— 蠕虫用偷来的 npm 和 GitHub 令牌自动感染、重新发布更多包，并且完整保留这些包的合法功能——开发者不会察觉任何异常，蠕虫就在「正常更新」的掩护下指数扩散。
除此之外还有两个值得记住的工程细节：
· 持久化：ChainDrop 在 VS Code 和 Claude Code 等开发者工具内部建立了交叉引用的钩子（例如篡改 VS Code 的 tasks.json）。即使构建结束、恶意包被清除，攻击者仍能通过这些工具配置保留对开发者机器的访问。
· C2 基础设施：整个指挥控制地址通过以太坊区块链交易动态管理——智能合约充当「死信箱」（dead drop）存放 C2 地址，想靠传统域名查封手段拆掉它的基础设施，基本没有抓手。
最终的杀伤面分三层，恰好覆盖开发到交付的全路径：云端机密收割（构建机内存里的明文凭证）、本地端点后门（开发工具配置持久化）、自动化传播（被盗令牌创建流氓仓库，把被攻陷账户变成新的发射台）。
05 三条战线：攻击面早已不限于「你的代码库」
结合Unit 42 的 SDLC 视角，攻击面清晰地分成三个战场。先看分发渠道的全景：StepSecurity统计的56 起事件里 npm 占 27 起、GitHub Actions 占 10 起、PyPI 占 9 起、IDE/编辑器扩展占 6 起，其余生态 4 起——npm 是主战场，但绝不是唯一战场。
图 | 56 起事件按分发渠道分布（图：StepSecurity）
图 | 第三方包在 SDLC 中的旅程
战线一：开发者端点——没有沙箱的执行环境。 今天的开发者要在 npm、pip、cargo、go、maven 等一堆包管理器之间来回切换，IDE 里还同时装着 10–30 个扩展。关键在于：浏览器访问网页时会把页面关进沙箱，而安装脚本和编辑器扩展没有任何隔离——它们一旦运行就拥有和你完全相同的权限，可以读你的文件、偷你的密钥、在你的机器上执行任意命令。GlassWorm 等针对 IDE 扩展市场的攻击活动，利用的正是这个结构性缺口。
战线二：CI/CD 流水线——密钥最密集、监控最稀少的地方。 构建机里塞满了临时密码、云访问密钥、签名密钥。连安全工具本身都成了目标：2026 年 3 月的 Trivy 事件（CVE-2026-33634，CVSS 9.4）中，Team PCP 强制重定向了 aquasecurity/trivy-action 全部 77 个版本标签中的 76 个，并发布恶意 v0.69.4 版本，把一台被上万条流水线使用的漏洞扫描器变成了凭证窃取器——载荷从 Runner.Worker 进程内存（/proc/
GitHub Actions 上的攻击全年呈现三种固定形态：篡改可变版本标签（Trivy、Checkmarx KICS 等）、借被污染的包转储 Runner 内存凭证（Shai-Hulud 家族、Team PCP、ChainDrop 均如此）、用被盗开发者凭证向仓库批量推送恶意工作流（Miasma、Hades 均如此）。
图 | GitHub Actions 的三种攻击形态及对应规模（图：StepSecurity）
战线三：云运行时——应用 SBOM 照不到的深水区。 标准应用级 SBOM 只列出开发者显式引入的代码库，但云上跑的是容器。容器镜像里还有操作系统层的组件——OpenSSL 这类基础密码学库、系统安全工具——它们完全不在应用层扫描的视野内。Unit 42 以 2026 年初披露的 OpenSSL 零日漏洞波次为例说明了这个盲区：应用代码干干净净、仓库扫描全部通过，而底层云工作负载却对远程接管敞开着大门。
由此得出的资产管理结论也很直接：构建结束后生成一份 SBOM 只能满足合规，终点线上的清单抓不到构建过程中已经执行过的恶意软件。除了应用 SBOM，你还需要 PBOM（流水线物料清单，记录构建系统里运行的每一个工具）和容器 SBOM（覆盖镜像里的 OS 层组件）。
06 为什么这些攻击总能得手
56 起供应链攻击事件中，反复出现的是同一批结构性弱点——没有一个是高深莫测的。StepSecurity 将其归纳为三根支柱：机密就坐在 CI/CD 流水线与开发者机器里、构建总是拉取未锁定的最新版本、构建机的出站网络访问无人看管。
图 | 攻击持续得手的三个结构性弱点（图：StepSecurity）
1. 信任模型错配。 GitHub Actions 的版本标签是可变引用，攻击者控制维护者账户后可以把每个现有标签重新指向恶意代码，所有引用它的工作流下次运行时自动中招，仓库里看不到任何变更。npm 的浮动版本号同理。
2. 长期凭证是蠕虫的燃料。 长期有效的 npm 发布令牌、个人访问令牌（PAT）一旦被盗，就是永动的传播引擎。axios 事件里，攻击者甚至用偷来的 npm 令牌手动发布恶意版本，绕过了 GitHub Actions 的 OIDC 可信发布机制——官方仓库里干干净净，没有任何痕迹。
3. 执行没有护栏。 生命周期脚本、IDE 扩展、AI 编码工具的钩子配置，全部以用户最高权限裸奔。
4. 来源证明存在盲区。 TanStack 和 Miasma（经被盗 OIDC 令牌发布、携带有效 SLSA 证明）证明了一件事：SLSA 这类框架验证的是「构建者身份是否属实」，而不是「构建者的凭证是不是刚被偷走」。当威胁模型是被攻陷的维护者而非被攻陷的构建系统时，签名照样有效，包照样是毒。
顺带一提 AI 这个变量：它已经出现在攻防两端。攻击侧，AI 驱动的机器人 hackerbot-claw 主动在微软、Datadog、CNCF 的项目里利用 GitHub Actions 工作流漏洞；受害侧，Miasma 是首批把 AI 编码代理（Claude Code、Gemini CLI、Cursor）当作执行触发器来武器化的蠕虫之一。开发工具链越智能，「打开即执行」的面就越大。
07 防御：从「事后扫描」转向「全程执行控制」
核心思路是一句话：别再指望在终点线扫描，要在整条构建路径上控制「什么能执行、能联网、能拿到什么凭证」。
环境加固侧：
· 禁用生命周期安装脚本（npm install –ignore-scripts 等）——绝大多数依赖根本不需要在安装时执行代码；
· 依赖钉死到完整 commit SHA，拒绝浮动标签和可变引用；
· 给新发布的包设「冷静期」——axios 恶意版本存活不到 3 小时、ChainDrop 从发布到被通报也很短，冷却期能挡掉大部分「抢鲜安装」的暴露窗口；
· 限制 CI/CD 出站流量（egress 管控）——凭证窃取得手的前提是能把数据传出去，封死外联通道，窃密就是无的放矢；
· 使用一次性的临时 Runner——构建完即销毁，不留持久化土壤。
凭证与信任链侧：
· 用短期 OIDC 认证取代长期令牌——Shai-Hulud 这类自传播蠕虫吃的是长期凭证，凭证短命化等于抽掉燃料；
· 建立端到端的加密来源链：从开发者端点的签名提交，到生产环境的签名制品与 SBOM，任何一环被替换都会断链报警；
· 打通三域遥测：开发者端点、CI/CD 流水线、云运行时的行为数据必须关联分析——单点的静态扫描看不到跨域传播的蠕虫，只有关联才能在下钻到下游之前截断它。
08 结语
十年前，一个项目可能只依赖几十个外部库；今天，一个简单应用会间接拉入数千个依赖，开源代码占现代代码库的 80–90%。我们没有退路地站在了「组装式开发」的时代，而攻击者比我们更早想明白了一件事：与其攻陷一个软件，不如攻陷生产软件的流水线。
56 起、每 3 天一起、五天卷走 7.8 万个密钥——这些数字的含义不是「开源不安全了」，而是「信任不能再是默认的」。每一条 npm install 背后，都该有一套配得上它的执行控制和凭证纪律。
参考链接
- https://unit42.paloaltonetworks.com/sdlc-supply-chain/
- https://stepsecurity.io/blog/state-of-open-source-supply-chain-attacks
- https://www.stepsecurity.io/blog/teampcp-supply-chain-attack-cicd-secrets-cloudsek-disclosure
- https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-009/
- https://www.hivepro.com/threat-advisory/chaindrop-shai-hulud-npm-supply-chain-worm-compromises-keyv-ecosystem
- https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
- https://unit42.paloaltonetworks.com/axios-supply-chain-attack/
- https://www.trendmicro.com/zh_hk/research/26/c/axios-npm-package-compromised.html
- https://labs.cloudsecurityalliance.org/research/csa-research-note-teampcp-supply-chain-ci-cd-20260324-csa-st/
- https://github.com/aquasecurity/trivy/discussions/10462
- https://www.stepsecurity.io/blog/10-layers-deep-how-stepsecurity-stops-teampcps-trivy-supply-chain-attack-on-github-actions
- https://www.stepsecurity.io/incidents
- https://www.uvcyber.com/resources/reports/threat-advisory-tanstack-supply-chain-attack
- https://securityaffairs.com/193367/malware/miasma-worm-compromises-73-microsoft-github-repositories.html
- https://github.com/Legit-Labs/supply-chain-playbooks/blob/main/antv_supply_chain/playbook.md
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：奇安信威胁情报中心 威胁情报中心 威胁情报中心《每 3 天一起投毒：软件供应链攻击正式进入「蠕虫时代」》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论