文章总结： 2026年软件供应链攻击爆发，攻击者盗取维护者凭证横向渗透，利用Unicode隐写、潜伏型更新及Actions评论注入伪造签名等隐蔽手段绕过审查。防御须摒弃盲目信任，务必锁定版本至commit哈希、强制MFA与最小权限、全量审计依赖变更与外联行为，并严格隔离开发环境。
综合评分： 91
文章分类： 供应链安全,威胁情报,安全建设,漏洞分析,WEB安全
别把锅丢给开发者：当IDE插件和npm包都不可信，这场供应链战争该怎么打
原创
逍遥
逍遥
昆仑AI安全实验室
2026年5月4日 00:00
广东
在小说阅读器读本章
去阅读
2026年还没过半，软件供应链已经从“需要防范的风险”变成了“正在爆炸的火药桶”。
Sonatype一季度数据：21,764个恶意开源包被识别，平均每6分钟冒出一个新的。卡巴斯基追踪到2025年底已有近19,500个恶意包，较上年增长37%。ReversingLabs的年度报告则显示，2025年恶意开源包检测量暴涨73%，其中npm平台贡献了近90%的恶意活动。
这不是“趋势”，这是正在重写游戏规则的战争。而大部分企业和开发者，还拿着旧版规则书。
本文不讲理论，只讲2026年正在发生的事、已经打出的攻击链、以及几件你现在就得做的事。
一、攻击已移向上游：你的代码审查，已经失效
传统供应链防御的逻辑是“守住自己”——扫自己的代码、审自己的依赖、管好自己的发布流程。但2026年的攻击者根本没打算攻破你的防线。他们直接攻破那些你已经信任的工具和库。
IBM X-Force报告指出，过去五年重大供应链攻击事件数量增长了近4倍，攻击者正在以开发环境和构建管道取代传统终端为目标。
TeamPCP组织在2026年3月打出了一条教科书级别的连锁攻击链：
第一步，利用未完全撤销的凭证，强制推送恶意commits到Trivy（Aqua Security的开源漏洞扫描器）的76个版本标签，CVE-2026-33634，CVSS 9.4。第二步，从Trivy的CI/CD环境中窃取凭证，用这些凭证攻破Checkmarx KICS的Docker Hub仓库、OpenVSX插件和GitHub Actions工作流。第三步，在npm上部署一个自我传播蠕虫，感染至少60个包。第四步，将偷来的凭证用于入侵LiteLLM（聚合100+LLM API的统一网关，月下载量约9700万次）和Telnyx SDK。第五步，植入恶意.pth文件到Python的site-packages目录——每次Python解释器启动时自动执行，不需要任何import语句，即使卸载包也无法清除。
十天内，从一款安全扫描器打到两个主流生态系统、一个LLM API网关和一个通信SDK，最终目标只有一个：批量收割云密钥和LLM API Key。
更早时，SANDWORM_MODE蠕虫通过19个typosquatting包在npm上传播，专门针对AI开发工具链进行投毒。它的独特之处在于：部署恶意MCP服务器注册到AI编程助手，通过提示注入操纵AI系统泄露API密钥。
4月下旬再升级：同一组织攻击Namastex Labs，部署CanisterSprawl蠕虫。一个开发者的npm令牌被窃取后，恶意代码用该令牌重感染受害者所有可发布的包——全自主、完全不需要攻击者动手。外泄数据通过常规HTTPS和ICP区块链双通道传送，后者无法被执法或域名接管切断。
同期爆出的Bitwarden CLI供应链攻击中，@bitwarden/[email protected]植入凭据窃取器，约25万月下载者在约90分钟窗口内暴露于风险。其code中甚至出现了“Shai-Hulud: The Third Coming”的标识字符串。
同一轮攻击还把恶意包推到了SAP生态的核心npm包——@cap-js/sqlite、@cap-js/postgres、@cap-js/db-service、mbt，四个包周下载量合计约57万次。同周，机器学习框架PyTorch Lightning也遭入侵，2.6.2和2.6.3版本携带凭据窃取器，日下载量超31万次。
Alexandre Lavoie指出，看似毫不相关的项目和仓库实际上通过共享的令牌、工作流和服务账户在权限层面紧密相连。一个维护者的GitHub令牌被盗，可被用于攻击该维护者参与的多个项目。攻击者的目标不是某一个包，而是这个包的维护者所拥有的密钥和发布权限。
二、不可见的代码：你审不过来的新型投毒
2026年最令人不安的攻击技术，不是漏洞利用，而是“让你根本看不见恶意代码”。
GlassWorm蠕虫在第四波攻击中使用了一种极为隐蔽的手法：将payload编码为Unicode私有使用区字符，嵌入代码中。在编辑器、终端、GitHub的diff视图里，这些字符完全不显示，肉眼看不到，常规代码审查也看不到。一个看似无害的npm包或VS Code插件，装完就触发恶意行为。截至2026年3月，已有433个组件被确认感染，跨越OpenVSX、VS Code Marketplace、GitHub和npm。
另一个演进方向是“潜伏型”插件。攻击者先发布一个clean的版本，通过审核和积累下载量。几周或几个月后，推送一个更新，在extensionPack或extensionDependencies字段里悄悄加入一个恶意扩展作为依赖项，通过“传递安装”完成攻击。安全检查只看初版，根本不会发现后来的恶意更新。
Code滥用扩展依赖机制本身并没有边界：任何扩展都可以声明将任意其他扩展作为依赖自动安装，且这两者不需要共享任何命名空间、作者或组织归属。设计上用于“方便开发者一键安装整个开发工具包”的功能，现在被重构为蠕虫分发基础设施。
还有一类让安全人员更头疼的：攻击者用AI生成恶意npm包。ReversingLabs在2026年4月披露的PromptMink活动中，攻击者利用Claude Opus向npm仓库提交了包含恶意功能的包。包名是@validate-sdk/v2，号称提供哈希、验证、编解码能力，实际功能是窃取敏感数据。它被注入为一个自主交易AI代理的依赖项，导致攻击者通过泄露的凭证访问受害者的加密钱包和资金。
更隐匿的打法叫“分层恶意包”：第一层包完全clean，没有任何恶意行为。它唯一的“恶”是引入第二层依赖——那个依赖才是承载恶意payload的。只要第二层依赖被检测或下架，攻击者立刻替换一个新的，手法灵活、难以追踪。
API网关和管理工具也难逃一劫。3月16日的GlassWorm集中攻击浪潮中，博思艾伦被入侵的思科API管理平台产生的隐蔽信道流量绕过已有检测体系。根源在于攻击者对API网关的南北向流量进行降级——将一个看似合规的REST API调用改道指向了隐藏在数据面内部的东西向隐蔽端点。
曾几何时，攻击者靠Typosquatting骗开发者下载假包——这还算“需要受害者犯错”的攻击。现在攻击完全不需要开发者犯错：你安装的包名正确、版本正确、签名正确、代码审查通过。唯一的区别，是包在你看不到的地方多做了几件事。
三、供应端失守：连分发渠道都在骗你
攻击不仅针对开源包，连软件分发网站本身都在被入侵。
2026年4月，硬件检测工具CPU-Z和HWMonitor的官方网站被篡改约19小时，合法的软件下载链接被替换为携带恶意代码的安装包，超过150名受害者在多国被确认感染。
3月，Notepad++披露其基础设施因托管服务商事件被入侵。攻击者使用了至少三种不同的感染链，针对菲律宾政府机构、萨尔瓦多金融机构、越南IT服务商等多个目标。
更疯狂的是GitHub Actions评论区注入。攻击者在PR评论区提交一段被仓库工作流解析为命令的文本，触发GitHub Actions脚本注入，进而窃取GITHUB_TOKEN。该令牌随后用于伪造签名commit和tag，触发正常发布管道，最终将后门版本发布到PyPI和GitHub Container Registry。利用elementary-data包（月下载量110万次），攻击者用此手法成功推送恶意版本。
elementary-data事件是教科书式的信任外溢攻击——开发者提供了真实代码，CI/CD系统产生了真实签名，发布管道执行了真实流程，但其中一环输入缺乏对“不可信评论者”的上下文感知检查，导致了从PR评论到供应链攻击的直通链路。
Sonatype的Brian Fox把这轮攻击的本质说得很清楚：“第一季度的重大开源攻击之所以得手，不是因为手法新颖，而是因为它们滥用了软件生命周期中已经建立好的信任——信任的包名、信任的工具、信任的发布工作流。”
四、至少要做这几件事
第一，锁定版本和完整性校验。CI/CD中引用的GitHub Actions不要用浮动tag，全部钉住到commit hash。npm和PyPI依赖全部锁定版本并启用lockfile校验。
第二，强制多因素认证和最小权限。npm和PyPI发布者账号必须启用MFA，CI/CD令牌赋予最小必要权限。凭证轮换不能等“安全部门通知”——但凡用到Trivy、KICS、LiteLLM、Telnyx SDK、Axios（1.14.1/0.30.4）、@bitwarden/cli（2026.4.0）、SAP CAP相关npm包的环境中，所有CI/CD secrets、云AK/SK、LLM API Key都要视为已泄露并立即轮换。
第三，审计代码不能只看功能。代码审查不只审查“正常版本”，必须审计包发布后的每一个版本差异，包括其声明的依赖包的作者、命名空间和首页URL。对于VS Code和OpenVSX插件，检查extensionPack和extensionDependencies字段的更新，确认插件是否有不声不响地引入新依赖。对npm/PyPI项目，启用postinstall/preinstall监控。
第四，监控外部行为。恶意包往往在安装阶段、import阶段、或首次API调用时触发网络外联。审查依赖包的对外连接行为，拦截非必要的外部请求。
第五，签名不意味着安全。elementary-data事件证明，攻击者利用了项目发布流程的正常签名机制。签名仅用于验证发布者的身份，而不是供开发者鉴别恶意行为的机制。
第六，最小化开发环境的权限。开发者本机不要存储高权限云AK/SK、不要用个人GitHub Token跑CI/CD实验，开发环境与生产环境彻底隔离。
第七，审计OpenClaw生态供应链。截至2026年4月，Acronis TRU已在ClawHub上识别到575+个恶意skill，分布13个开发者账户，部分针对macOS AMOS窃密器。通过伪装为合法工具并诱导用户将恶意依赖安装到开发环境中，攻击者可进而触发预埋的间接提示注入逻辑。整合OpenClaw到工作流的团队需审计所有已安装的来源、校验skill的manifest和执行的网络请求，并评估AI辅助工具链在组织内的攻击面。
软件供应链战争从来不是“会不会发生”的问题，而是“什么时候轮到你的依赖”的问题。攻击者已经证明了：只要打穿一个维护者账号，就能同时污染十几个包、感染几万个下游项目、触达几百万终端用户。
而你手里那些“应该没问题”的信任，就是他们的下一个目标。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 逍遥
逍遥《别把锅丢给开发者：当IDE插件和npm包都不可信，这场供应链战争该怎么打》