一、什么是 NPM 供应链攻击的 Blast Radius在 Node.js 项目开发中我们几乎每天都会使用npm install安装依赖包。正常情况下安装一个包只需要几秒钟但这背后却存在一个非常容易被忽视的问题你安装的每一个 npm 包背后往往还携带着一大串它自己的依赖而这些依赖又有自己的依赖。假设团队在项目中直接依赖了lodash、axios和react看起来依赖数量不多但经过多级依赖传递后package-lock.json中的真实依赖可能成百上千。这个问题会演化成一个非常严重的供应链安全场景攻击者不需要攻陷你项目直接依赖的那个包只需要攻陷依赖链里某一个不太起眼的小工具包就能把恶意代码带进你的生产环境。Blast Radius爆炸半径指的就是当某个 npm 包被攻陷后有多少其他包、多少项目和多少运行环境会被连带影响。这个影响范围不是只看“谁直接用了这个包”而是要沿着依赖树往上层传播分析把所有直接或间接依赖该包的组件全部找出来。本文将从 npm 依赖结构讲起演示如何用命令行工具排查依赖风险分析一个包被攻陷后的污染路径并给出工程化的缓解方案。适合前端开发、Node.js 后端开发以及做依赖安全审计的同学阅读。1.1 为什么 npm 生态更容易被供应链攻击盯上npm 是世界上最大的包管理生态之一注册表中有超过 200 万个包。npm 包设计之初就考虑到了模块复用的便利性但却没有在设计层面强制约束“依赖树必须足够浅”。这就导致了一个常见现象一个简单的工具函数库可能依赖了几十个第三方包一个复杂的构建工具依赖树可达几千个包这些包可能来自不同的维护者、不同的组织、不同的安全维护水平。当攻击者选定目标后通常会寻找那些比较流行但没有精力维护的小型包通过社工、钓鱼或直接接管维护者账号的方式发布一个恶意版本。一旦用户执行npm install或npm update恶意代码就随着依赖传递进入本地环境。Blast Radius 分析的核心价值在于它帮助我们在攻击发生前后快速判断“受影响面有多大”从而决定是否需要紧急修复、回滚版本或全网排查。1.2 直接依赖、间接依赖与影响范围的关系为了准确理解 Blast Radius我们先把依赖关系分清楚。依赖类型含义举例直接依赖项目 package.json 中显式声明的依赖react: ^18.2.0间接依赖依赖其他包时被一起安装的包react 依赖的 scheduler、loose-envify传递依赖多层级间接依赖依赖的依赖的依赖任意嵌套层级假设项目里安装了一个名为a的包a依赖bb依赖cc被攻陷。此时直接依赖数量1a实际受影响的项目代码所有 import 了 a 的模块潜在影响链a → b → c在没有 lockfile 或没有依赖审计的情况下开发者很难感知c的存在更别说评估它的安全性。Blast Radius 分析的第一步就是要摸清完整的依赖树并把不安全包的“上层引用者”找出来。二、环境准备与依赖分析基础在正式做依赖风险分析之前先确保本地环境可以正常执行 npm 命令。2.1 检查 Node.js 与 npm 版本打开终端执行以下命令node -v npm -v本教程的示例环境如下实际版本以你本机为准Node.js v18.17.0 npm 9.6.7如果你在 Windows 上运行 npm 时遇到“无法加载文件 npm.ps1因为在此系统上禁止运行脚本”的报错这是因为 PowerShell 的执行策略默认禁止运行脚本。可以尝试以下两种解决方式。方式一以管理员身份打开 PowerShell修改执行策略Set-ExecutionPolicy -ExecutionPolicy RemoteSigned方式二改用 CMD 命令行工具运行 npm 命令。如果你遇到“npm 不是内部或外部命令”的提示说明 Node.js 没有正确安装或环境变量未配置。此时需要将 Node.js 的安装目录添加到系统 PATH 环境变量中默认安装路径一般为C:\Program Files\nodejs\2.2 准备一个包含复杂依赖的示例项目为了演示 Blast Radius 分析过程我们创建一个简单的示例项目。这个项目会故意引入一些包含多层依赖的常用包。mkdir blast-radius-demo cd blast-radius-demo npm init -y执行下面的命令安装示例依赖npm install lodash axios express安装完成后当前项目结构如下blast-radius-demo/ ├── node_modules/ ├── package.json └── package-lock.jsonpackage-lock.json文件中记录了 npm 安装时的完整依赖树。我们可以先用一个简单的命令来查看当前项目依赖总数量。npm ls --all 2/dev/null | wc -l在实际项目中这个数字往往会达到几百甚至几千。依赖数量越大Blast Radius 分析就越重要。三、用 npm 自带命令评估 Blast Radius排查一个 npm 包被攻陷后影响范围第一步就是回答两个问题这个包当前被哪些包依赖这个包当前安装的版本是什么npm 提供了多个原生命令来回答这些问题。3.1 使用 npm ls 查看依赖链npm ls是排查依赖来源最常用的命令。它能够根据包名反查依赖链效果非常直接。假设我们需要确认lodash在当前项目中的依赖链npm ls lodash输出效果blast-radius-demo1.0.0 D:\code\blast-radius-demo └── lodash4.17.21如果某个包是被间接安装的例如我们想知道scheduler是从哪条路径进来的npm ls scheduler输出可能会是blast-radius-demo1.0.0 D:\code\blast-radius-demo └─┬ react18.2.0 └── scheduler0.23.0这个命令返回的结果非常直观不光告诉你安装了哪个版本还告诉你它是被哪个上层包拉进来的。如果你想知道项目里所有带高危漏洞的包并追踪它们的依赖链可以执行npm auditnpm audit会根据 package-lock.json 中的依赖树去 npm 官方漏洞库比对已知漏洞然后给出受影响的包和修复建议。3.2 使用 npm query 做结构化查询npm ls适合人眼阅读但在依赖数量多、需要自动化统计时推荐使用npm query命令。这个命令支持类似 CSS 选择器的语法可以精确筛选依赖关系。查看所有已安装包的总数npm query :root * | less这条命令会输出当前项目的直接依赖信息结果以 JSON 结构展示。查看所有被间接依赖的包npm query *:not(:root *) | less这个查询表示选择所有不是顶层直接依赖的包也就是全部间接依赖。查看某个特定包被哪些包依赖虽然npm query不能完全等价于反向依赖查询但可以结合后处理脚本实现。比如用 Node.js 脚本解析 npm 输出。3.3 分析 package-lock.json 中的依赖关系package-lock.json本质上是一棵完整的依赖树快照。当我们需要评估一个包被攻陷后的 Blast Radius 时可以写一个简单的脚本对 lockfile 做解析。以下脚本逻辑是给定一个包名遍历整个 lock 文件找出所有直接依赖它的包。// 文件路径scripts/blast-radius.js const fs require(fs); const lockData JSON.parse(fs.readFileSync(./package-lock.json, utf-8)); const targetPackage process.argv[2]; if (!targetPackage) { console.error(请指定要查询的包名例如node scripts/blast-radius.js lodash); process.exit(1); } const packages lockData.packages || {}; const dependents []; for (const [path, meta] of Object.entries(packages)) { const deps meta.dependencies || {}; // 同时检查 dependencies 和 optionalDependencies const allDeps { ...deps, ...(meta.optionalDependencies || {}) }; if (allDeps[targetPackage]) { dependents.push({ path, version: meta.version, dependsOn: allDeps[targetPackage] }); } } console.log(依赖 ${targetPackage} 的包数量: ${dependents.length}); dependents.forEach(item { console.log(- ${item.path || (项目根目录)} 依赖 ${targetPackage}${item.dependsOn}); });在项目根目录执行node scripts/blast-radius.js lodash示例输出依赖 lodash 的包数量: 1 - node_modules/express 依赖 lodash^4.17.21这个脚本只是最基础的版本。在实际安全分析中还需要考虑锁文件中的dev标记、可选依赖、peer 依赖等情况。3.4 可视化整个依赖图如果依赖数量过大终端文本输出不利于全面观察。比较常用的做法是生成一个依赖图文件然后借助可视化工具查看。安装dependency-cruisernpm install -D dependency-cruiser执行可视化分析npx depcruise src --include-only ^src --output-type dot dependency-graph.dot生成 dot 文件后可以使用在线工具或本地 Graphviz 将其转换为图片。通过图形化展示一个包被哪些模块引用会一目了然。不过dependency-cruiser主要分析的是项目源码之间的 import 关系。要完整分析 node_modules 内部的依赖关系更推荐使用npm ls --all配合文本搜索或使用专门的商业级 SCA软件成分分析工具。四、实战模拟一个 NPM 包被攻陷后会怎样为了更直观地理解 Blast Radius我们来模拟一个供应链攻击场景。注意这个模拟是在本地测试环境中进行的不会安装真正的恶意包也不会发布任何真实攻击代码。4.1 模拟场景设定我们虚构一个名为safe-logger的包该包被项目中的api-client依赖而api-client被业务模块user-service依赖。依赖关系如下user-service └── api-client └── safe-logger如果safe-logger被攻击者接管并发布恶意版本那么直接受害包api-client间接受害包user-service最终影响所有调用 user-service 接口的业务模块4.2 本地创建模拟包先创建一个模拟恶意包safe-loggermkdir -p mock-safe-logger cd mock-safe-logger npm init -y修改 package.json 内容{ name: safe-logger, version: 1.0.1, description: 模拟被攻陷的日志工具包仅用于本地安全教学, main: index.js }创建index.js// 模拟恶意代码收集环境变量信息 // 注意此代码仅用于本地安全测试禁止用于真实攻击 const maliciousCode () { const envInfo { env: process.env, cwd: process.cwd(), platform: process.platform }; console.log([!] 模拟恶意行为敏感信息已被收集, JSON.stringify(envInfo)); }; maliciousCode(); module.exports { log: (msg) console.log(msg) };然后在本地将模拟包打包npm pack此时会生成safe-logger-1.0.1.tgz文件。4.3 创建受害者项目在另一个目录创建受害项目mkdir -p victim-project cd victim-project npm init -y安装模拟包npm install ../mock-safe-logger/safe-logger-1.0.1.tgz安装成功后运行项目入口文件node -e require(safe-logger)控制台会输出模拟的恶意行为提示。这说明只要安装了这个包即使你的代码没有主动调用恶意功能main入口中的代码也会在包被 require 的时候执行。4.4 实战中的影响范围判断现在我们可以回答前面提出的关键问题了。当safe-logger被攻陷时判断 Blast Radius 的步骤是第一步找出所有直接依赖safe-logger的包cd victim-project npm ls safe-logger第二步找出所有被api-client间接依赖的顶层模块npm ls --all 2/dev/null | grep api-client第三步从业务角度分析user-service的所有调用方都会受到影响。这已经超出了 npm 命令能回答的范围只能靠代码仓库的依赖扫描和调用链路追踪。在这个模拟中可以看到一个日志工具包的攻陷会影响整个上层业务模块所有依赖链上的项目文件都存在被攻击的风险。五、NPM 生态中的真实风险场景了解了 Blast Radius 的计算方式后再来看几个真实项目中常见的风险场景这些都是我们在日常开发中需要重点关注的。5.1 依赖混淆攻击攻击者在 npm 上发布一个与公司内部包同名的公共包版本号故意设置得比内部版本更高。开发者的 npm 配置如果同时使用了内部私有仓库和公共 npm 仓库就可能在安装时优先拉到恶意公共包。这种攻击的 Blast Radius 取决于内部包被多少个业务系统引用。一个核心工具库如果被 50 个服务引用攻击影响范围就是全部 50 个服务。5.2 软件包名称相似性攻击攻击者注册一个与热门包名字相似但存在细微差异的包比如把lodash改成loadash把axios改成axois。如果开发者手误输错包名恶意包就会被安装进项目。这类攻击的 Blast Radius 相对分散因为单个包的下载量不高但隐蔽性强代码评审很难发现。5.3 流行包的维护者账号被接管攻击者通过钓鱼或密码爆破拿到热门包维护者账号后发布一个带有恶意代码的“新版本”。由于热门包有大量现存用户只要用户执行npm install或npm update攻击代码就会进入构建链。这种情况的 Blast Radius 往往非常大。例如一个周下载量千万级的构建工具如果被攻陷受影响的项目数量可能覆盖整个前端生态的数十万个项目。5.4 安装脚本中的恶意操作npm 支持在包安装时自动执行preinstall、install、postinstall脚本。攻击者可以在这些脚本中写入恶意命令在包安装阶段就完成执行。判断安装脚本是否危险的命令npm view package-name scripts例如npm view lodash scripts输出{ test: echo \\See package.json for details\\ }如果发现某个包的安装脚本包含下载远程文件、执行系统命令等可疑操作就要提高警惕。六、如何最大化控制 Blast Radius分析 Blast Radius 是为了更好地控制它。在工程实践中我们可以从多个方面来降低 npm 供应链攻击的爆炸半径。6.1 精确锁定依赖版本在package.json中使用精确版本号而不是带^或~的模糊版本。{ dependencies: { lodash: 4.17.21, axios: 1.6.2 } }这样做的目的是当某个依赖发布新版本时不会因为自动更新而被意外带入恶意版本。6.2 完善 lockfile 机制确保package-lock.json文件被提交到 Git 仓库。lockfile 记录了安装时的完整依赖树只要 lockfile 不变任何环境下安装的依赖版本都一致。验证 lockfile 是否生效npm cinpm ci会严格按照 lockfile 安装依赖。如果 lockfile 与 package.json 不一致命令会直接报错而不是静默更新。6.3 使用 npm audit 定期检查建议在 CI 流程中加入依赖安全检查npm audit --audit-levelhigh--audit-level参数可以设置最低报告等级可选值包括low、moderate、high、critical。设置为high时只有高危漏洞才会导致命令非零退出从而阻断构建。6.4 使用 overrides 强制固定子依赖版本当某个间接依赖存在漏洞而它的维护者还没有修复时可以通过overrides字段强制覆盖版本。{ overrides: { lodash: 4.17.21 } }也可以对指定包的子依赖进行覆盖{ overrides: { api-client: { safe-logger: 1.1.0 } } }使用overrides后npm 会无视依赖声明中的版本范围强制使用指定版本。这个功能在供应链攻击应急响应时非常有用但需要谨慎测试覆盖后的兼容性。6.5 精简依赖减少不必要的包每多一个依赖就多一分风险。在引入新依赖前建议先考虑这个功能真的需要第三方库吗能否用原生 API 实现这个库的维护是否活跃最近一次发版是什么时候这个库的依赖数量是不是太多检查某个包的依赖数量npm view package-name dependencies如果发现一个简单工具库却依赖了几十个其他包就要重新评估是否值得引入。6.6 使用 pnpm 提升依赖管理安全性pnpm 和 npm 的核心区别之一在于依赖存储方式。pnpm 使用全局内容寻址存储并通过符号链接将依赖链接到项目中。这种设计让每个项目生成的 node_modules 更干净也减少了依赖被意外修改的风险。安装 pnpmnpm install -g pnpm在项目中使用 pnpm 安装依赖pnpm install要注意的是pnpm 默认也会读取package-lock.json但更推荐使用 pnpm 自己的pnpm-lock.yaml。七、常见 NPM 报错排查清单在依赖安装和安全分析过程中我们经常会遇到各种 npm 报错。这里整理了一些高频问题供大家参考。7.1 npm 安装报错npm ERR! code EBADENGINE现象npm ERR! code EBADENGINE npm ERR! engine Unsupported engine npm ERR! engine Not compatible with your version of Node/npm原因当前 Node.js 版本不满足某个包的要求。解决思路检查当前 Node 版本node -v查看包对 Node 版本的要求npm view package-name engines根据要求切换 Node 版本推荐使用 nvmNode Version Manager管理多个 Node 版本。7.2 npm 安装很慢或者网络报错现象安装依赖时长时间卡住或者提示网络超时。解决思路检查当前镜像源npm config get registry如果返回的是官方源https://registry.npmjs.org/在中国大陆环境下载可能会比较慢。可以切换到国内镜像源npm config set registry https://registry.npmmirror.com也可以在使用命令时临时指定npm install --registryhttps://registry.npmmirror.com7.3 找不到某个包No package xxx available现象No package zabbix-server-mysql available.原因这通常不是 npm 的报错而是 yum、dnf 或 conda 等其他包管理器的报错。这说明当前 Linux 发行版的软件源中没有这个包。解决思路检查当前使用的包管理工具yum list | grep zabbix添加正确的软件源后重试。7.4 PowerShell 中运行 npm 脚本报错现象npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本原因PowerShell 执行策略默认禁止运行脚本。解决思路以管理员身份打开 PowerShellSet-ExecutionPolicy -ExecutionPolicy RemoteSigned7.5 npm 命令找不到现象npm 不是内部或外部命令也不是可运行的程序或批处理文件。原因Node.js 未安装或安装目录未加入 PATH。解决思路重新安装 Node.js安装时勾选“Add to PATH”选项。安装完成后重新打开终端。八、供应链安全的最佳实践建议从 Blast Radius 的角度出发下面是我在实际工程中比较推荐的几项安全实践。8.1 最小权限与最小依赖原则无论是部署权限还是依赖数量都遵循最小化原则。生产环境尽量只安装生产需要的依赖开发依赖不进入生产镜像npm install --production或者在 Docker 构建时使用FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omitdev COPY . . CMD [node, index.js]这样可以显著减少生产环境的攻击面。8.2 私有仓库与镜像同步对于企业项目建议搭建私有的 npm 仓库如 Verdaccio、Nexus并配置只从私有仓库拉取依赖。这样即使公共 npm 仓库中的某个包被删除或恶意篡改私有仓库中的副本仍然可以保持稳定。8.3 安全巡检机制建议建立以下巡检机制每次提交代码前执行npm auditCI 流水线中加入npm audit --audit-levelhigh每周对 lockfile 做一次全量扫描关注 npm 安全公告和 GitHub Security Advisory8.4 应急响应预案当发现某个依赖被攻陷时建议按以下顺序处理确认受影响版本范围使用overrides强制覆盖为安全版本重新安装依赖在所有相关项目中执行排查检查项目代码中是否有异常文件或异常请求如有必要轮换环境变量的密钥和 Token九、总结与下一步学习建议这篇文章从 Blast Radius 的概念出发带着大家一起拆解了 npm 依赖树中的影响传播链条。我们掌握了几个核心能力用npm ls、npm query查看依赖链解析package-lock.json来定位受影响的上层依赖创建本地模拟包理解恶意包被安装后的实际行为通过精确版本、lockfile、npm audit、overrides 等手段控制爆炸半径处理常见的 npm 安装和运行报错。接下来可以继续深入学习的方向包括阅读 npm 官方文档中关于 lockfile 的完整说明研究 pnpm 和 Yarn Berry 在依赖管理上的安全性差异学习 SCA软件成分分析工具的原理和使用了解 Node.js 运行时安全和沙箱隔离方案。在实际项目中依赖安全不是一次性工作而是一个持续优化的过程。每次升级依赖、每次引入新包都应该走一遍依赖审查流程。希望这篇文章能给你提供一个可落地的排查思路。