npm 供应链攻击后，开发者要怎么检查依赖、lockfile 和 CI 密钥

正文

npm 供应链攻击最麻烦的地方，不是“装错一个包”这么简单。恶意包通常会在安装阶段自动运行，读取开发机和 CI 环境里的 GitHub token、npm token、SSH key、云厂商凭据、.env、Actions secrets，再把这些凭据拿去继续污染其它包或仓库。

所以一旦项目可能装过被投毒的 npm 包，第一反应不要是 rm -rf node_modules。node_modules 只是结果之一。你要先确认恶意版本有没有进入 lockfile、有没有在本机或 CI 里执行过生命周期脚本、有没有接触过密钥、有没有把恶意版本缓存进构建环境。

先看几个真实案例

2026-03-30，StepSecurity 披露 Axios npm 包被投毒。攻击者通过被劫持的维护者账号发布了 axios@1.14.1 和 axios@0.30.4，并加入一个伪装成正常加密库的依赖 plain-crypto-js@4.2.1。这个依赖没有被 Axios 源码引用，作用是通过 postinstall 执行跨平台 RAT dropper。StepSecurity 记录称，恶意版本在 npm 上存活了约 2 到 3 小时，GitHub issue axios/axios#10604 也记录了这两个版本被确认 compromised。

这个案例的危险点是：GitHub 仓库源码看起来可能没问题，npm registry 上的发布物却已经被污染。只看 GitHub tag 或源码 diff，不足以判断你是否安全。

2026-05-19，TechRadar 转述多个安全团队的发现：Mini Shai-Hulud 相关攻击在 1 小时内发布了 639 个恶意版本，覆盖 323 个独立 npm 包，目标包括开发者、开源维护者和 CI/CD 环境。报道提到相关攻击会利用被盗登录凭据和 access token 发布恶意包，窃取 GitHub、云和 CI/CD 相关凭据。

2026-06，Red Hat Cloud Services 命名空间下的 npm 包也被报道遭到污染。TechRadar 报道称，攻击者通过被攻陷的 GitHub 账号向多个 npm 包注入恶意内容，目标包括 GitHub Actions secrets、npm tokens、SSH keys 和 cloud credentials。

这些案例说明，npm 投毒已经不只是“浏览器里偷加密货币钱包地址”这种前端风险。现在攻击者更关心开发者工作台和 CI/CD：那里有发布权限、云权限、仓库权限和更多下游项目。

先确认你有没有装过恶意版本

第一步是查 lockfile，而不是只看 package.json。package.json 里可能只有范围版本，真正装过什么要看锁文件。

PowerShell 里先查已知包名和版本：

Select-String -Path package-lock.json,pnpm-lock.yaml,yarn.lock -Pattern "axios@1.14.1|axios@0.30.4|plain-crypto-js|@tanstack|@mistralai|@redhat-cloud-services" -ErrorAction SilentlyContinue

再查最近一次依赖变更：

git diff -- package.json package-lock.json pnpm-lock.yaml yarn.lock

重点看这些变化：

如果你使用 pnpm，继续看具体路径和版本：

Select-String -Path pnpm-lock.yaml -Pattern "version:|resolution:|integrity:|dependencies:|optionalDependencies:" -Context 0,3

如果你使用 npm，确认 CI 是否用的是 npm ci。npm 官方文档说明，npm ci 面向 CI 和部署这类自动化环境，要求已有 package-lock.json 或 npm-shrinkwrap.json；如果 lockfile 和 package.json 不匹配，它会报错，而不是更新 lockfile。这能减少 CI 悄悄装到新版本的概率。

查生命周期脚本和安装时执行

npm 包最危险的入口之一是生命周期脚本：preinstall、install、postinstall、prepare。恶意包常用这些脚本在你安装依赖时自动执行。

先查项目直接依赖里有没有新增脚本：

Get-Content package.json | Select-String -Pattern '"preinstall"|"install"|"postinstall"|"prepare"'

再查 lockfile 里是否出现可疑包名后，进入临时目录解包查看发布物：

npm pack <package-name>@<version> --dry-run

需要看真实 tarball 内容时，用隔离目录，不要在含密钥的项目里直接运行安装：

mkdir .tmp-npm-check
cd .tmp-npm-check
npm pack <package-name>@<version>
tar -tf .\<package-name>-<version>.tgz

看到这些内容要暂停：

如果你只是想先让 CI 跑静态检查，可以临时禁用安装脚本：

npm ci --ignore-scripts

这不是永久修复。有些合法包需要构建脚本。它的作用是先阻止未知脚本自动运行，让你有机会检查依赖树。

查本机和 CI 是否接触过密钥

只要恶意包可能执行过，就要按“它能读到当前进程权限范围内的内容”处理。开发机和 CI runner 的风险不一样。

先查本机敏感文件是否可能被安装脚本读取：

Get-ChildItem -Force $HOME -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object {
    $_.FullName -match "\\.npmrc|\\.ssh|\\.aws|gcloud|azure|credentials|config"
  } |
  Select-Object FullName

不要把这些文件内容贴到聊天、issue 或日志里。这里只确认路径和暴露面。

再查 CI secrets 相关改动：

rg -n "NPM_TOKEN|NODE_AUTH_TOKEN|GITHUB_TOKEN|AWS_|AZURE_|GCP_|PRIVATE_KEY|DEPLOY_KEY|secrets\\." .github workflows .github/workflows

如果恶意包在 CI 中运行过，并且 workflow 里有 npm token、GitHub token、云凭据或部署密钥，直接进入轮换流程。

轮换凭据不要只换 npm token

很多开发者看到 npm 包投毒，只会撤销 npm token。但恶意包不一定只偷 npm token。它能读取当前环境里的所有可访问凭据。

按这个顺序处理：

如果你不知道某个 token 是否被读过，按读过处理。供应链事件里，“看起来没有被用”不是安全证明。

限制 GitHub Actions 权限

npm 投毒经常盯上 CI，因为 CI 里有自动化权限。GitHub 文档建议在 workflow 或 job 级别配置 GITHUB_TOKEN 权限，只给需要的权限。

给普通测试工作流一个保守默认：

name: test

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci --ignore-scripts
      - run: npm test

发布 workflow 再单独提升权限，不要让所有 job 默认拥有写权限：

permissions:
  contents: read
  id-token: write

npm provenance 文档说明，Trusted Publishing 可以通过 OIDC 生成 provenance attestation，并减少在 CI/CD workflow 里使用长期 access token 的需要。能用 OIDC / Trusted Publishing 的发布流程，优先替代长期 NPM_TOKEN。

发布包时也要注意 provenance 的边界：npm 文档明确说 provenance 不能保证包没有恶意代码，它提供的是可验证的源码和构建说明链接。也就是说，provenance 是判断依据，不是免审通行证。

查 npm 发布来源和 provenance

如果你是包维护者，或者你的项目依赖内部包，继续查发布来源。

先看包元数据：

npm view <package-name>@<version> version dist.tarball dist.integrity repository gitHead _npmUser

对比几个版本：

npm view <package-name>@<good-version> _npmUser gitHead dist.integrity
npm view <package-name>@<suspicious-version> _npmUser gitHead dist.integrity

异常信号：

能验证签名和 attestations 时，跑：

npm audit signatures

签名验证失败不等于一定被投毒，可能是生态支持不完整；但对高风险依赖，它足以触发人工复查。

不要让 lockfile 自动漂移

供应链攻击最喜欢“自动更新”。如果 CI 每次都根据范围版本重新解析依赖，或者 bot 自动合并 lockfile 变化，恶意版本就更容易进来。

更稳的规则：

pnpm 项目可以在 CI 里使用：

pnpm install --frozen-lockfile

yarn 项目按版本选择：

yarn install --immutable

锁文件不是噪音。供应链事件发生时，lockfile 是你判断“到底装过什么”的证据。

发现可疑依赖后的最小处置流程

发现可疑依赖后，按这个顺序处理。

1. 暂停部署和发布流水线。
2. 保留当前 package.json、lockfile、CI run ID、构建日志和镜像 tag。
3. 查本机、CI、容器构建环境是否运行过安装脚本。
4. 回退到确认安全的版本，或临时移除该依赖。
5. 删除 node_modules 后用冻结 lockfile 重装。
6. 轮换可能被读取的 token、SSH key、云凭据和数据库密码。
7. 清理 CI cache、包管理器 cache、Docker build cache 和远程 runner。
8. 检查最近 GitHub Actions、npm publish、registry、云审计日志。
9. 补上 permissions、Trusted Publishing、provenance、安装脚本限制。
10. 记录影响范围和最终安全版本。

回退示例：

git checkout -- package.json package-lock.json pnpm-lock.yaml yarn.lock
Remove-Item -Recurse -Force node_modules
npm ci --ignore-scripts

如果你的项目用 pnpm：

git checkout -- package.json pnpm-lock.yaml
Remove-Item -Recurse -Force node_modules
pnpm install --frozen-lockfile --ignore-scripts

--ignore-scripts 只是应急隔离。确认依赖树安全后，再决定是否恢复脚本执行。

发布者要减少长期 token

如果你维护 npm 包，攻击面还包括你的发布账号。

优先顺序：

1. 开启 npm 账号 2FA。
2. 用 Trusted Publishing / OIDC 替代长期发布 token。
3. 如果必须用 token，使用短期、细粒度 token。
4. release workflow 只在 tag / release 事件触发。
5. 发布 job 单独隔离，不和测试 job 共用过多 secrets。
6. npm publish 前跑 npm pack --dry-run 看实际发布内容。
7. 包发布后检查 npm metadata、provenance、GitHub tag 是否一致。

发布前看包里到底有什么：

npm pack --dry-run

不要把 .env、测试 token、内部文档、调试脚本、.npmrc、构建缓存发进包。npm 投毒不一定来自外部攻击者；错误发布同样会造成供应链事故。

团队可以固定一张检查表

把这张表放进依赖升级 PR 或安全响应模板里。

npm supply-chain check:
- [ ] package.json and lockfile diff reviewed
- [ ] no unexpected new transitive package
- [ ] no unexpected git / tarball / remote dependency
- [ ] lifecycle scripts reviewed
- [ ] install tested with frozen lockfile
- [ ] CI job runs with least GITHUB_TOKEN permissions
- [ ] npm token is not available to normal test jobs
- [ ] publish uses Trusted Publishing / OIDC where possible
- [ ] npm audit signatures checked for high-risk release
- [ ] CI cache and Docker cache reviewed if suspicious package ran
- [ ] affected tokens and secrets rotated if install script may have run

npm 供应链安全不是“永远不要装依赖”。真正可执行的做法是：锁住版本、看懂 lockfile、限制安装脚本、减少长期 token、让 CI 权限最小化，并在可疑包执行过时按凭据泄露处理。

只要恶意包已经在本机或 CI 里跑过，清理依赖只是第一步。真正的收尾是把它可能接触过的权限都收回来。

参考来源

相关文章