恶意代码如何借供应链潜入你信任的软件

供应链攻击并不会强行闯入你使用的软件。它毒化构成这款软件的某个零件，然后等待正常的更新流程把它送到你的设备上。应用照常顺利安装，签名依旧通过，更新也依旧从官方渠道抵达。恶意代码就搭着它一起进来。正是这种反转让这种手法如此有效：它把让软件得以运转的信任，变成了被利用的那个点。

你今天运行的几乎没有一样东西，是由屏幕上署名的那家公司从头写到尾的。一个应用就可能拉进成百上千个开源软件包，每一个都由陌生人维护，每一个背后又拖着更多软件包。开发者很少去读那些代码；他们信任代码来自的仓库，以及随附的版本号。只要潜入这条链条的任意一环，就能一举触及下游的所有人，因此一个被毒化的零件，可能在有人察觉之前就影响成千上万个项目。

入口归结为几种套路。仿冒抢注摆出一个名字与流行包仅差一个按键的恶意包，等着有人打错字。依赖混淆利用构建工具解析名称的方式，诱骗它们抓取一个公共包，而不是公司的私有包。账号劫持夺取真正维护者的凭据，把恶意软件当作例行更新分发；2026 年初，广受使用的 axios 包在其主要维护者的电脑被社会工程攻破之后，曾短暂发布过一个被植入后门的版本。而构建流水线投毒瞄准的是组装并发布软件的自动系统，那里一个被破坏的步骤，就会波及每一个依赖它的项目。

构建流水线之所以成为最被觊觎的目标，恰恰因为它位于其他一切的上游。当流行的 GitHub Actions 组件 tj-actions/changed-files 于 2025 年被攻陷时，攻击者改写它的版本标签，使其指向恶意代码，并从两万多个仓库的构建日志中抽走机密：访问密钥、令牌和私钥，全都以明文出现。后来一场被研究者命名为 Megalodon 的行动，把 GitHub Actions 变成一个自我传播的后门，约六小时内触及 5561 个仓库。构建你软件的机器，可以像软件本身一样轻易被颠覆。

开发者每天使用的工具同样在波及范围之内。2025 年底首次被发现的 GlassWorm，通过 OpenVSX 和微软市场里的 Visual Studio Code 扩展传播。它用不可见的 Unicode 字符藏起载荷，于是恶意代码行在编辑器里几乎无法阅读，骗过了人工审查。一旦安装，它就窃取 npm、GitHub 和 Git 的凭据，再用这些凭据自动感染更多软件包和扩展——这正是蠕虫的定义性特征。由于编辑器在后台悄悄更新扩展，受害者无需点击任何东西就收到了被毒化的版本。另一个被投毒的 VS Code 扩展，则被用来窃取 GitHub 自家约 3800 个内部仓库。

让这些攻击如此难以捕捉的，是每个单独步骤看上去都合法。软件包有签名。更新来自真正的仓库。维护者账号是真的。传统防御寻找已知的恶意文件和明显的恶意软件，但供应链攻击藏身于可信、可预期、且往往不可见的代码之中，并且恰好在软件本该抵达的时刻、以本该有的方式抵达。更糟的是：那条一贯的安全建议——立刻更新——恰恰是攻击者所倚赖的机制。第一次，安装最新版本不再是毫无保留的安全选择。

防御者已经在少数几项确实有效的做法上达成一致。锁定文件把每个依赖固定到一个精确、经过核验的版本，于是安装器只取已审阅的内容，而不是一味取最新的。关闭自动安装脚本，切断了恶意包一落地就运行代码的最常见途径。把 GitHub Actions 固定到某个特定的提交哈希，而不是可移动的标签，能让改写标签的伎俩失效。一份软件物料清单，即构建之中每个组件的详尽列表，能让团队在下一起事件被披露时，几分钟内就知道自己是否受影响。许多躲过近期攻击的机构并没有做什么稀奇之事：他们从已提交的锁定文件构建，并在一个会隔离新发布软件包的仓库代理之后工作。

对不写代码的人来说，保护大多是间接的，但教训并非如此。软件供应链如今是第一线的战场，而保护它，是那些制造你手机和笔记本上应用的公司的责任。理智的回应既不是恐慌，也不是一有通知就把一切都更新的旧习惯。而是优先选择那些公开自己交付什么、又如何构建的团队的软件，并把可信来源当成在每一环上都要挣得的东西，而不是一种会自己顺着链条往下流的属性。

业界的答案正围绕来源逐渐成形：用密码学证明一段代码从何而来、如何构建，并在安装任何东西之前自动核验。这与一代人之前保护网络流量的，是同一个思路，如今被用到了软件自身的装配线上。在那种证明变得普遍之前，每一次安装，都仍是对你永远不会见到的人的一次信任。