我最怕的不是拼错包名，而是 CI 日志里那行看起来太正常的安装命令。
包挂在 @redhat-cloud-services 下面，组织是 Red Hat 官方，名字不像山寨货。流水线也不会因为“来源太可信”停下来多问一句。它只会照着 package.json、lockfile 和安装脚本继续跑。
Aikido 研究人员披露，这起供应链攻击从周一开始。原文发布时，攻击仍被称为 active。受影响的软件包数量还没最终确认，原文写的是：
More than 30 packages seem to be affected.
也就是超过 30 个包似乎受到影响。
更刺眼的是另一句：
“Official Red Hat NPM accounts have been compromised and used to push a malicious worm...”
Red Hat 官方 NPM 账号被攻破，并被用来推送恶意蠕虫。
先把边界说清楚。现在能说的是，官方 NPM 账号和相关命名空间被用于发布恶意包。不能据此推断 Red Hat 整个软件体系都被植入后门，也不能说攻击者已经控制了 Red Hat 内部系统。至少从目前披露的信息看，范围仍落在官方 NPM 渠道和相关包上。
麻烦在于，这已经够了。
平时的投毒包，常见套路是“差一个字母”：把热门包名改得很像，赌开发者手滑。这次不是。开发者看到的是 Red Hat 官方 NPM 渠道，重点命名空间是 @redhat-cloud-services。这几个字，对很多人来说已经足够让手指放过回车键。
CI 也一样。它不会琢磨“官方账号怎么也可能出事”。它只会安装、构建、上传产物。
攻击者如果拿到这里的发布权限，就不需要伪装成 Red Hat。它已经站在 Red Hat 的牌子下面了。
坏包真正想要的是钥匙
这次恶意代码被描述为 wor
m，蠕虫。
普通坏包会让人想到“某台机器中毒了”。蠕虫更麻烦。它不只想在一台机器上拿点东西，它想从一台机器跳到下一台机器。
它运行后会寻找敏感凭据：NPM token、GitHub token、SSH key、云厂商 AK/SK、内部制品库账号、容器仓库密码。平时这些东西藏在环境变量、配置文件、CI secret、开发机目录里。工程师把它们放进去，是为了自动化；攻击者找它们，是为了继续拿发布权、代码权和云资源权。
Aikido 披露里还有一个判断：攻击者如何控制这个命名空间尚不清楚，但“几乎可以肯定”涉及访问凭据被攻破。
这个判断并不意外。现在很多供应链攻击，已经不是“写个恶意包等人下载”那么简单。更有效的办法，是先拿一个可信账号，再去污染更可信的包。
我自己踩过类似的坑，不是 Red Hat 这次，而是模型部署时的构建环境。
为了让镜像自动拉私有仓库、自动上传产物、自动调用模型服务，我们把 token 配得很顺手。顺手到后来谁也说不清，一个 npm install 阶段到底能读到多少东西。
这些凭据通常比代码更值钱。
代码被偷，当然很糟。但发布 token 被偷，攻击者可以替你发包。云密钥被偷，可以开机器、拉数据、扫内网。模型 API key 被偷，可以刷账单，也可以冒用你的产品身份去请求外部服务。
所以这件事最危险的地方，不是“某几个包坏了”，而是坏包运行后还能不能拿到别人的钥匙。
感染一台构建机，偷到一个发布 token，再污染下一个包。拿到一个 GitHub token，再读更多私库。拿到一个云密钥，再去找对象存储和数据库。这个循环一旦跑起来，就很难靠“删掉坏包”解决。
AI 团队别只盯着模型
目前没有证据表明这起事件专门针对 AI 公司，也没有证据表明它专门针对中国公司。攻击者身份没有披露，Red Hat 官方完整回应和最终受害企业名单，在现有材料里也看不到。
但国内 AI 团队不该把它当成别人的事。
一个普通 AI 应用团队，前端可能用 React 或 Vue，构建用 Vite、Webpack、pnpm，后端脚本里有 Node.js。项目里可能接 OpenAI、Claude、通义千问、豆包、智谱，也可能接向量数据库、对象存储、MLOps 工具、监控 SDK。
它不一定直接用 @redhat-cloud-services。但它一定在用大量第三方包和自动化构建。
秘密也经常堆在这些地方：模型 API key、云算力账号、客户数据接口 token、GitHub 私库权限、容器镜像仓库凭据。很多都能在 CI/CD 里找到。
恶意依赖不需要理解 Transformer，不需要会提示词攻击，也不需要知道你的 RAG 怎么做。它只要在安装阶段执行，读环境变量，扫配置文件，把能拿的 key 发走，就够了。
我见过一些团队对安全的理解还停在“生产环境别开公网端口”。但现在很多事故根本不用碰生产机器。构建机、发布机、开发机、私有 NPM 仓库、镜像源同步节点，都可能是入口。
AI 项目还有一个问题：迭代快，依赖加得快，demo 变线上也快。临时 token 很容易变成长期 token。
这不是说别用开源，也不是说官方包都不能碰。现实做法很笨，但有效：
- 依赖版本要锁住，异常升级要有人看；
- CI 里的 token 要最小权限，能短期就别长期，能只读就别读写；
- 发布令牌要能轮换，离职、事故、异常发布后立刻换；
- 构建环境要隔离，不能让任意安装脚本读到全局密钥；
- 私有制品库和镜像源不能只是缓存上游包，也要有扫描和审批。
官方命名空间可以提高可信度，但不能替代权限控制。
NPM、GitHub、云服务 SDK、模型平台，任何一个地方的凭据被拿走，都可能让攻击从“我装了一个坏包”变成“别人用我的身份继续发东西”。
下次构建失败时，工程师会盯着日志找语法错误、依赖冲突、网络超时。真正该多看一眼的是另一件事：这台构建机上，到底有哪些 token，是一个被信任的 NPM 包在安装瞬间就能读到的？