一行安装脚本就能偷走云上凭据：依赖投毒的四道防线

很多人把供应链安全理解成"依赖里有没有漏洞"，实际发生的攻击往往更简单：在安装环节执行一段代码。业务代码一行没改，漏洞扫描全绿，凭据却已经流出去了。攻击者要的从来不是漏洞，而是构建机上那串能直接调用云 API 的密钥。

一、安装那一刻，信任已经被交出
Node.js 生态的 postinstall、Python 的 setup.py、Maven 的构建插件、容器基础镜像的构建阶段，本质上都允许第三方代码在本地自动执行。一旦执行，它就有和构建用户一样的权限：读环境变量、读 ~/.npmrc、读挂载的密钥文件。

这意味着"只用了一个小工具库"这种判断没有意义。依赖树里任何一个传递依赖，都拿到了同样的执行权。2021 年的 ua-parser-js 事件就是典型：攻击者接管维护者账号后发布带后门的新版本，postinstall 脚本同时投放挖矿程序和密码窃取逻辑，影响的是数以百万计的安装。

二、三个案例，指向同一个入口
2018 年 event-stream 依赖链中的 flatmap-stream 模块被植入窃取加密货币钱包的代码；2022 年 colors.js 与 faker.js 的作者主动破坏自己的包，造成大量构建失败；2024 年的 xz-utils 后门 CVE-2024-3094 更隐蔽，攻击者用了近两年经营维护者身份，最后在构建脚本里做手脚。

手法不同，落点一致：发布权限、维护者账号、构建脚本。

三、云环境把后果放大了一个量级
本地开发机上中招，最多赔一台笔记本。CI/CD 上中招，赔的是整个云账号。流水线里通常放着三类高危资产：能长期使用的 AccessKey、可写生产的部署权限、能覆盖历史产物的镜像仓库。

更糟的是构建缓存和镜像分层会帮助扩散：被污染的依赖固化进基础镜像，后续服务全部继承这份"脏"层，排查时很难定位到最早那次安装。

四、四道可以今天就落地的防线
第一，锁定与隔离。全部使用 lockfile 并开启完整性校验，私有 registry 代理只允许白名单包通过，阻断 typosquatting 类仿冒包。

第二，限制安装脚本。CI 中统一加 --ignore-scripts 或等价的安装脚本白名单，确实需要编译的包单独评审。这一条能挡掉绝大多数"装完即执行"的攻击。

第三，缩短凭据寿命。构建任务不落盘长期 AK，改用 OIDC 换取分钟级临时凭据，权限只给当次构建需要的资源。凭据即便被读走，也很快失效。

第四，留痕与可追溯。产物做签名，生成 SBOM 并归档，构建机的出站流量做域名级审计。出现异常外联时，能快速回答"是哪次构建、哪个依赖、哪条流水线"。

结语
依赖投毒的本质是信任传递：你信任的包，信任了它的维护者，维护者又信任了自己的账号安全。这条链上任何一环松动，云上凭据就可能成为代价。防线不必滴水不漏，但要保证某一环失守时损失有限——锁定版本、禁用自动脚本、使用短期身份、留下可查痕迹，这四件事成本很低，收益却直接落在账号安全上。

标签：云安全、供应链安全、依赖投毒、CI/CD