npm依赖安全：如何评估一个包的Blast Radius爆炸半径影响范围

先问一个问题：如果你的项目直接依赖的某个 npm 包被攻破了，你有多大把握说“影响范围就这一个包”？很多同学第一反应是去查这个包本身，但真正危险的地方在于，它背后还挂着一整棵依赖树，树上的每一层，都可能成为攻击链的一部分。

Blast Radius（爆炸半径）这个概念，最早来自系统可靠性领域，用来衡量“单个组件故障时，最多波及到多少个相邻组件”。放到 npm 生态里，问题就变成了：当某一个 package 被污染、被恶意发布、或者被偷走账号后，有哪些项目、哪些版本、哪些软件包会被间接波及。本文会围绕这个概念，从依赖树原理、分析工具、实际排查步骤、降低风险的最佳实践四个方向展开，并结合日常使用 npm 时常见的安装、权限、镜像源、版本兼容问题，给出完整可落地的排查方案。

1. 什么是 Blast Radius，为什么 npm 包的安全问题必须看它

1.1 从一个安全模型说起

Blast Radius 翻译成“爆炸半径”，在安全领域通常指：某个资产、权限、组件发生安全事件后，受影响的系统范围有多大。你可能会觉得，这不就是“影响范围分析”吗？严格说两者有区别。影响范围分析通常是事后排查，比如“这个库被通报有漏洞，我去全局搜一下谁用了”；而 Blast Radius 更强调事前建模，它在依赖关系、权限关系、信任关系上做传播分析，结论是“如果 A 被攻破，B、C、D 都有风险，因为它们与 A 存在路径”。

在 npm 生态里，这种路径几乎是无处不在的。一个现代前端项目，安装完依赖后 node_modules 里动不动几百个包，这些包之间通过 dependencies、devDependencies、peerDependencies、optionalDependencies 连接成一个有向图。任何一个节点被攻破，攻击者都有机会把恶意代码传播到所有依赖它的包和项目里。

1.2 npm 包被攻破的常见方式

先搞清楚攻击入口，才能理解为什么 Blast Radius 会被反复提及。结合近几年公开的安全事件，常见途径有：

• 账号失窃：维护者账号密码泄露，攻击者以合法身份发布恶意版本。
• 域名过期：包仓库地址或作者域名过期，被第三方抢注后诱导开发者。
• 恶意 PR 投毒：攻击者给热门项目提交包含恶意代码的 PR，维护者合并后发布新版本。
• 依赖混淆：利用私有包名与公有包名相同的特性，诱导包管理器安装到恶意包。
• 抢注相似包名：把热门包名拼写错误或加连字符的包抢先注册，开发者误装。

这些攻击方式都有一个共同点：受害范围不是“一个包”，而是“所有依赖这个包的包和项目”。npm 的传递依赖机制让问题被指数级放大。

1.3 为什么说“暴露面”比“漏洞本身”更值得关注

假设某个不被任何人依赖的小工具包被攻破，影响可能很有限；但如果是 ESLint 插件、Babel 插件、构建工具这类“开发期被广泛依赖”的包，一旦被攻破，攻击者可能拿到成百上千个项目的源码级访问权限。因为这类包通常运行在开发者的电脑上、CI 环境里，能在安装或构建阶段执行任意代码。

这就是 Blast Radius 分析的价值：漏洞存在不等于灾难发生，真正决定灾难大小的，是整个依赖网络里有多少路径可以到达这个包。

2. npm 依赖树与传递依赖机制

2.1 依赖树是怎么生长的

要理解 npm 包的 Blast Radius，必须先理解依赖树。npm 管理的每个包都有自己的 package.json，里面的 dependencies 字段声明它依赖哪些包。安装时，npm 会递归下载所有依赖，并且尽可能地“拍平”到顶层 node_modules，以便共享同一份副本。

用一个最小示例来看，假设我们的项目 package.json 如下：

{ "name": "demo-app", "version": "1.0.0", "dependencies": { "package-a": "^1.0.0", "package-b": "^2.0.0" } }

package-a 和 package-b 又各自依赖其他包：

{ "name": "package-a", "version": "1.2.0", "dependencies": { "shared-lib": "^1.0.0" } }

{ "name": "package-b", "version": "2.1.0", "dependencies": { "shared-lib": "^1.3.0" } }

项目同时需要 shared-lib 的 1.0 和 1.3 两个版本范围。npm 会尽量让两个依赖共用同一个版本，如果版本冲突无法调和，就会把其中一个安装为嵌套依赖，即 node_modules/package-a/node_modules/shared-lib 这种层级。

从 Blast Radius 角度看，shared-lib 一旦被攻破，package-a、package-b、demo-app 全都在暴露面里。而且由于 npm 允许不同层级存在不同副本，单纯搜索“某个版本被谁依赖”还不够，还要看具体路径。

2.2 传递依赖把风险扩散到了哪里

传递依赖是指“依赖的依赖”。项目没有直接声明 shared-lib，但它出现在依赖树里，照样会下载到 node_modules，照样会在安装阶段执行脚本。

npm 安装时有两类脚本最值得警惕：

• preinstall / postinstall / prepare 等生命周期脚本。
• 通过依赖包内部的代码在 require 时执行。

攻击者只要把恶意代码塞进这两类入口，受害者只要执行 npm install，恶意代码就有机会运行。这也是为什么 snyk、npm audit、Socket 等工具会专门检测“安装时执行脚本”的依赖。

理解这一点后，Blast Radius 分析就不能只看一级依赖，必须整棵树铺开，找到所有可达路径。

2.3 为什么 lockfile 是分析的关键入口

package-lock.json 是 npm 自动生成的依赖树快照。它记录了每个依赖包的精确版本、解析地址、完整性校验哈希，以及它被谁依赖。

如果你需要评估某个 npm 包被攻破后的影响，第一件要做的事不是翻 node_modules，而是看 lockfile。项目里有没有 lockfile，直接决定了可复现性和可分析性：

• 有 lockfile：依赖树被锁定，可以精确分析每个包被哪些项目引用。
• 没有 lockfile：依赖范围是区间，相同 package.json 在不同时间安装结果可能不同，Blast Radius 分析也会失真。

所以很多安全最佳实践的第一条就是：把 lockfile 提交到 Git，让团队所有人和 CI 环境使用同一份锁定版本。

2.4 直接依赖 vs 间接依赖，暴露面差异巨大

直接依赖是你主动写入 package.json 的包，数量通常几十个；间接依赖是这些包自己拖进来的，数量经常几百上千。两者的权限模型几乎等价：只要在 node_modules 里，就能被 require；只要被导入，就可能执行代码。区别在于，你更容易关注到直接依赖的版本变化，却很难逐一看清全部间接依赖。

从暴露面管理角度，合理的做法是：先做依赖树可视化，把间接依赖数量多、传递层级深、安装后脚本多的包标记为高风险对象，再逐层分析它们的 Blast Radius。

3. 利用 npm 命令分析包的 Blast Radius

下面进入可操作的环节。以分析某个 npm 包为例，演示如何用命令行工具快速判断影响范围。这里以 lodash 为例，仅用于演示分析流程，并不代表 lodash 存在漏洞。

3.1 先看清这个包被谁依赖

要判断一个包被谁依赖，不能靠猜，要回到 lockfile 里搜索。

先在项目根目录执行：

npm ls lodash --all

这个命令会打印从当前项目出发的所有依赖路径。比如：

demo-app@1.0.0 └─┬ package-a@1.2.0 └── lodash@4.17.21

这说明项目本身没有直接使用 lodash，但它通过 package-a 被带进来了。如果想看整个依赖树中等价信息，可以执行：

npm ls lodash --all --json

输出 JSON 格式后，可以配合 jq 或者 Node.js 脚本做数据提取。

如果你在查看一个全局项目，想直接看某个包被哪些顶层依赖引用：

npm ll lodash

npm ll 是 npm ls 的长格式别名，能显示每个依赖的版本和路径信息。

3.2 查看一个包的元数据和历史版本

攻击者发布恶意版本时，通常会利用“版本号升级”或“替换旧版本”的方式。分析包的暴露面之前，需要先知道它有几个历史版本、最新版本是什么、仓库地址是否可信。

npm view lodash

该命令输出包的基本信息，包括版本、依赖、dist-tags、仓库地址等。如果想看全部历史版本：

npm view lodash versions --json

要看某个具体版本的依赖关系：

npm view lodash@4.17.21 dependencies --json

这些信息有助于判断：这个版本的依赖里有没有可疑的新增依赖，或者维护者是否突然发布了一个与历史行为完全不符的版本。

3.3 检查当前项目是否存在已知漏洞

npm 自带的 audit 能力是最容易上手的 Blast Radius 排查工具：

npm audit

它会把当前依赖树与已知漏洞库做比对，输出漏洞所在包、路径、受影响版本、修复建议。输出结构类似：

lodash <4.17.21 Severity: high Regular Expression Denial of Service in lodash - https://github.com/advisories/GHSA-xxxx fix available via npm audit fix

注意 audit 默认覆盖的是“从当前项目可达的漏洞路径”，这正是 Blast Radius 在依赖树上的具体体现。建议使用 JSON 输出保存证据：

npm audit --json > audit-report.json

拿到 JSON 后，可以提取 vulnerabilities 字段，查看每个漏洞的 find 数组，里面记录了从 root 到漏洞包的具体路径。

3.4 用依赖图工具做全局分析

命令行在单项目里够用，但当你管理多个仓库、想分析某个包在整个组织里的暴露范围时，推荐把依赖树转成图来观察。常用方案有：

• npm-visualizer：分析 package-lock.json，生成可视化的依赖图。
• dependency-cruiser：适合分析源码 import 层的依赖关系，定位“实际运行时会 require 到哪些包”。
• madge：可以从源码入口分析模块依赖，输出图片或 JSON。

以 npm-visualizer 为例：

npx npm-visualizer --exclude devDependencies --output graph.html

它会读取当前目录下的 package-lock.json，生成一个 HTML 文件，用浏览器打开后可以看到依赖之间的引用关系。分析时可以重点观察：

• 哪些包被大量依赖引用，它们的出边和入边最多。
• 哪些高危路径上出现了安装脚本。
• 哪些包虽然没有直接依赖，但出现在很多深层路径中。

这类工具的价值是帮你建立“依赖网络”的直觉，而不是只看单个包。

3.5 通过 npm 包分析平台获取外部情报

本地 lockfile 只能反映“我当前项目里发生的依赖”，但 npm 生态是动态的，你还需要外部信息源来持续跟踪。常用的免费平台有：

• npmjs 的 Package Details 页面，可以查看版本发布时间和依赖。
• Snyk Advisor，展示包的维护活跃度、社区评分和安全报告。
• Socket，重点检测包是否包含安装脚本、网络请求、混淆代码等高危行为。
• OSV-Scanner，Google 开源的漏洞扫描工具，支持从 lockfile 直接匹配 OSV 漏洞数据库。

这些平台本质上就是在为每个包计算“风险画像”，帮助开发者在依赖某个包之前，先判断它如果被攻破，自己会不会是受害者。

3.6 自动化输出“受影响项目清单”

如果你在大型团队里负责安全，手动一个个项目执行 npm ls 是不现实的。更合理的做法是写一个脚本，循环扫描所有仓库的 lockfile，统一输出“高危包 -> 受影响项目”的映射表。

简化思路如下：

#!/usr/bin/env bash # 文件路径：scripts/scan-blast-radius.sh # 用法：./scan-blast-radius.sh <package-name> PACKAGE_NAME=$1 for repo in ./repos/*/; do echo "检查项目: $repo" cd "$repo" if [ -f package-lock.json ]; then if grep -q "\"$PACKAGE_NAME\"" package-lock.json; then npm ls "$PACKAGE_NAME" --all 2>/dev/null || true fi fi cd - done

这个脚本的原理很简单：在所有仓库的 lockfile 里搜索目标包名，如果存在，再用 npm ls 输出具体依赖路径。生产环境中更推荐用 Node.js 或 Python 写一个稍微健壮的扫描器，把结果导出成 CSV 或 JSON，交给后续处置。

4. 从 lockfile 解析依赖关系的实战演练

4.1 准备一个示例项目

为了方便理解，我们不需要真实的中毒场景，而是搭建一个“存在潜在风险关联”的最小项目。

目录结构如下：

demo/ ├── package.json ├── package-lock.json └── src/ └── index.js

package.json 内容：

{ "name": "demo-blast-radius", "version": "1.0.0", "private": true, "dependencies": { "left-pad": "^1.3.0", "loader-utils": "^2.0.0" } }

文件路径：src/index.js

const leftPad = require('left-pad'); console.log(leftPad('CSDN', 8, '0'));

这里故意选了两个历史上被公开讨论过的包作为演示对象，目的是展示“被大量间接依赖”的典型场景，不代表这两个包现在存在漏洞。

4.2 安装依赖并生成 lockfile

在项目目录执行：

npm install

安装完成后，package-lock.json 会记录每个包的精确解析版本。接着执行：

npm ls --all

输出会展示 current 项目的完整依赖树。如果想知道某个特定包被谁依赖：

npm ls left-pad --all

预期输出类似：

demo-blast-radius@1.0.0 └── left-pad@1.3.0

这表示 left-pad 是直接依赖。再来看 loader-utils：

npm ls loader-utils --all

如果 loader-utils 只是直接依赖，输出会很简单。但在真实项目中，loader-utils 通常会被 webpack、vue-loader、style-loader 等构建工具间接引用，所以依赖路径会更长。

4.3 解析 package-lock.json 中的依赖关系

package-lock.json 的核心结构是 packages 字段，记录了每个包的版本、依赖关系和 integrity 哈希。可以用以下命令提取关键信息：

node -e "const lock = require('./package-lock.json'); const pkgs = lock.packages; Object.keys(pkgs).filter(k => k && k.includes('loader-utils')).forEach(k => { const p = pkgs[k]; console.log(k, p.version); console.log(' 依赖:', JSON.stringify(p.dependencies)); });"

如果包存在嵌套依赖，你会看到同一个包名出现不同路径，例如：

node_modules/loader-utils 2.0.4 依赖: ...

假如某条依赖路径里出现了恶意包，这个脚本可以帮助你快速确认它出现的层级数量，以及是否被多个父包引用。

4.4 用 audit 计算当前依赖树的“风险路径”

继续在项目里执行：

npm audit --json

JSON 里有一个 vulnerabilities 字段，每个漏洞对象包含：

• name：存在漏洞的包名。
• severity：严重程度。
• isDirect：是否为直接依赖。
• via：漏洞来源，可能引用间接依赖路径。
• effects：被该漏洞影响的包，这是 Blast Radius 在漏洞维度的直接表达。

在 JSON 输出中，如果看到某个漏洞的 effects 里有多个包，意味着哪怕你只安装了一个有漏洞的包，也可能连带着其他包一起处于受影响状态。修复时不能只升级出问题的包，还要检查 effects 列表里的所有包是否还能兼容新版本。

4.5 制造一个“模拟污染版本”来观察传播路径

为了更直观地观察 Blast Radius，可以在本地点一个小规模的模拟实验。先在本地建一个伪造的 npm 包，然后让另一个包依赖它，最后在项目里通过 file: 协议引入，再用 npm ls 观察传播。

本地包目录结构：

fake-malicious/ ├── package.json └── index.js

文件路径：fake-malicious/package.json

{ "name": "fake-malicious", "version": "1.0.0", "main": "index.js" }

文件路径：fake-malicious/index.js

console.log('恶意包被加载');

然后建一个中间包：

demo-mid/ ├── package.json └── index.js

文件路径：demo-mid/package.json

{ "name": "demo-mid", "version": "1.0.0", "dependencies": { "fake-malicious": "file:../fake-malicious" } }

最后项目 package.json 修改为：

{ "name": "demo-blast-radius", "version": "1.0.0", "private": true, "dependencies": { "demo-mid": "file:../demo-mid" } }

执行：

npm install npm ls fake-malicious --all

输出会显示：

demo-blast-radius@1.0.0 └─┬ demo-mid@1.0.0 -> ../demo-mid └── fake-malicious@1.0.0 -> ../fake-malicious

这个实验告诉我们：只需要在根项目的 package.json 里引入 demo-mid，fake-malicious 就会出现在依赖树里。而且 npm 安装时不会因为“它不是你直接依赖”就跳过它。真实世界里，恶意包就是通过这种“多跳”路径进入生产环境的。

4.6 观察安装脚本的执行链

继续用上面的模拟包，给它加上安装后执行脚本，验证“安装阶段触发”的传播方式。

修改 fake-malicious/package.json：

{ "name": "fake-malicious", "version": "1.0.0", "main": "index.js", "scripts": { "postinstall": "node index.js" } }

然后删除根项目的 node_modules，重新执行：

npm install

在安装过程中，控制台会打印：

> fake-malicious@1.0.0 postinstall > node index.js 恶意包被加载

这个现象解释了为什么 npm 供应链攻击那么危险：攻击者不需要等运行时代码被调用，只要 install 命令被执行，恶意代码就可以运行。对应的防范手段之一，就是在 install 时用--ignore-scripts临时屏蔽脚本；生产环境更要根据包的可信度决定是否允许安装脚本。

5. 真实场景中的 Blast Radius 案例拆解

这里不编造任何未公开的细节，只讨论已经被广泛报道的安全事件的通用模式。

5.1 事件一：环境变量信息被盗取

攻击者向某个被大量依赖的包注入代码，在安装时读取 process.env 并将结果发送到远程服务器。这类攻击的 Blast Radius 范围包括：

• 使用该包的任何 Node.js 项目。
• 在 CI 环境构建的项目，因为 CI 里常常配置了云厂商密钥、私钥、Token。
• 开发者的个人电脑，因为本地的环境变量可能包含账号信息。

从暴露面看，受影响的不是“某一个业务系统”，而是“所有运行了 npm install 的终端环境”。

5.2 事件二：安装脚本替换源码文件

攻击者通过 postinstall 脚本，修改项目中已有的源码文件。例如在某个工具包安装后，动态给 Webpack 配置文件追加恶意插件。

这种攻击的 Blast Radius 更加隐蔽，因为它不会在依赖树上增加新节点，而是直接在宿主项目内部修改文件。常规的 npm audit 不一定能发现，必须配合文件完整性校验、构建产物 diff、运行时的异常请求监测才能定位。

5.3 事件三：版本号被恶意覆盖

当某个包的维护者账号泄露后，攻击者会在原版本号上发布一个被污染的新版本。由于很多项目没有锁版本，而是使用^1.0.0这种范围写法，重新执行 npm install 就会安装到恶意版本。

这种情况下，Blast Radius 会被“版本范围”放大。lockfile 中如果记录的还是旧版本，重新 install 也可能因为 registry 数据变化而拉取到新版本。所以高安全要求的项目，不仅要有 lockfile，还要对 registry 的响应做哈希校验。

6. 如何降低 npm 包的 Blast Radius

6.1 从依赖声明上收缩暴露面

降低暴露面最直接的办法，是少依赖、依赖得更精确。

• 用 exact 版本替代 range 版本：

"dependencies": { "lodash": "4.17.21" }

• 减少不必要的依赖包，能用原生 API 解决就不要引入工具库。
• 使用 pnpm 时注意，虽然内容寻址存储会提升安装速度和磁盘使用率，但依赖分析和安全扫描仍然要走 lockfile 或 audit。
• 搭建私有 registry 时，配置白名单代理，阻止未授权的公共包进入内部项目。

6.2 启用 npm audit 与自动化扫描

把安全扫描接入 CI，是成本最低、效果最明显的防线。可以在 CI 脚本里加入：

npm audit --audit-level=high

如果 audit 发现 high 级别以上漏洞，CI 直接失败，强制开发者处理。注意 audit 依赖漏洞数据库，需要定期更新 npm 版本，保证数据库是最新的。

如果团队使用 GitHub，可以利用 Dependabot 或 Renovate 自动提交依赖升级 PR，减少人工排查成本。

6.3 对安装脚本保持敏感

npm 安装时可临时禁用脚本：

npm install --ignore-scripts

这只适合临时排查，不推荐长期使用，因为有些包必须通过脚本完成编译或下载二进制文件。替代方案是安装时检查脚本数量：

npm pkg get scripts

对某个具体包执行：

npm view some-package scripts --json

如果一个简单的纯 JS 工具包突然带上了复杂的 postinstall 脚本，就要高度警惕。

6.4 使用 lockfile 和完整性校验

将 package-lock.json 和 pnpm-lock.yaml（如果使用 pnpm）提交到版本库。npm 在安装时会根据 lockfile 校验完整性，如果 registry 返回的内容与 lockfile 中的 integrity 不一致，安装会报错。

典型示例：

npm ERR! code EINTEGRITY npm ERR! Verification failed while extracting some-package@1.0.0

遇到这种报错，不要急着用--force跳过，要先确认是不是镜像源问题，或者包确实被篡改。很多时候，保留 lockfile 能帮你阻断恶意版本的自动扩散。

6.5 最小权限与网络隔离

在 CI 和部署环境里，尽量不给 Node 进程多余的权限：

• 不要用 root 身份运行 npm install。
• CI 环境使用独立、短期有效的 token。
• 对敏感环境变量做最小范围注入，不让所有构建任务共享同一个密钥。
• 在可以接受的前提下，使用沙箱容器运行 npm install，并限制出网访问。

这些措施会把“包被攻破”的后果限制在更小范围内，而不是让攻击者立刻拿到整个运维体系。

7. 常见 npm 环境问题与排查思路

在分析 Blast Radius 或者处理 npm 依赖时，经常被环境问题卡住。这里整理几个高频场景。

7.1 PowerShell 禁止运行脚本的解决办法

Windows 上高频报错是：

npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。

原因是 PowerShell 默认执行策略是 Restricted。临时解决可以执行：

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

生产环境建议只对当前用户放行，而不是全局。如果公司安全策略不允许修改执行策略，可以改用 npm 的 cmd 版本：

C:\Program Files\nodejs\npm.cmd

7.2 Node 版本不兼容的排查

npm 报错中非常常见的是：

npm ERR! code EBADENGINE npm ERR! engine Unsupported npm ERR! notsup Required: {"node":"^22.22.2 || ^24.0.0"}

这表示当前 Node 版本过高或过低，不满足包的要求。排查步骤：

1. 查看当前版本：node -v
2. 查看包要求的 Node 版本范围：可以在 npm 包页面查看 engines 字段
3. 使用 nvm 切换合适版本：

nvm install 22 nvm use 22

不要直接用--force跳过引擎检查，因为运行时不兼容会导致各种隐藏问题。

7.3 npm 国内源配置

在分析、安装 npm 包时，网络问题经常干扰判断。配置国内镜像源可以减少超时和下载失败。命令如下：

npm config set registry https://registry.npmmirror.com

如果只需要临时使用，可以加上--registry参数：

npm install --registry=https://registry.npmmirror.com

注意：镜像源可能同步延迟，刚发布的新版本未必能马上拉取到。若最新版本缺失，可以先切回官方源确认。

8. 工程化落地：把 Blast Radius 分析变成团队规范

8.1 建立依赖准入清单

一个团队如果对所有 npm 包都无条件信任，Blast Radius 的失控只是时间问题。建议在项目里维护一个 DEPENDENCIES.md 或 trusted-dependencies 配置，对直接依赖进行分类：

• 可信依赖：源码知名、维护活跃、历史上无安全负面记录。
• 受限依赖：允许使用，但必须固定版本并定期审计。
• 禁止依赖：无人维护、安装脚本复杂、下载量低但权限请求异常。

在 CI 中加入检查，凡是 package.json 里出现“禁止依赖”，直接构建失败。

8.2 发布前做一次依赖树快照评审

在功能分支合并前，执行：

npm ci npm audit --json > audit.json npm ls --all > tree.txt

将 tree.txt 和 audit.json 放入产物目录，作为发布包的一部分。后续如果出现安全事件，这条“依赖快照”就是判断 Blast Radius 的基础证据。

8.3 对组织内多个仓库做统一扫描

对稍具规模的前端组织，建议做一次全局扫描。思路：

1. 收集所有仓库的 lockfile。
2. 解析出每个仓库的完整依赖列表。
3. 以“包名”为维度，反向构建“包 -> 仓库”的映射。
4. 定期导入漏洞情报，输出受影响仓库清单。

这类工作可以用脚本实现，也可以借助商业化方案。重点不是工具多先进，而是先建立“可以回答谁暴露了”的数据底表。

8.4 建立安全事件应急预案

当某个包被通报攻破，团队内部需要有明确的响应清单：

1. 确认当前项目 lockfile 中该包的版本是否受影响。
2. 用 npm ls 找到所有依赖路径。
3. 检查是否执行过安装脚本，是否有异常网络请求。
4. 升级到安全版本，重新生成 lockfile。
5. 轮换可能泄露的环境变量和密钥。
6. 通知所有相关项目和运维人员。

这个清单本质上就是在定义：一旦攻击发生，你如何快速测量自己的 Blast Radius。

9. 总结：用 Blast Radius 思维看待 npm 依赖安全

回到最开始的问题：当一个 npm 包被攻破时，还有谁暴露了？

如果你的回答是“只是那个包”，说明你低估了 npm 的传递依赖力量；如果你能立刻拿出 lockfile，列出受影响版本、依赖路径、安装了该包的所有仓库，说明你已经建立了 Blast Radius 思维。在供应链攻击越来越常态化的今天，npm 安全的关键不只是“不装恶意包”，而是即使装了一个恶意包，也要让它在最短时间内被识别、被隔离、被清除。

接下来的学习方向，可以围绕三块继续深入：一是掌握 npm、pnpm、yarn 三种包管理器的依赖解析差异，尤其是 lockfile 格式；二是学习 Snyk、Socket、OSV-Scanner 等安全工具的动态；三是了解 SBOM（软件物料清单）的生成和使用，它能把 Blast Radius 分析从“临时救火”变成“日常工程”。

最后给一个实用建议：不管项目多紧，优先保证 package-lock.json 被提交，优先保留每次发布前的 npm audit 报告，优先对拥有安装脚本的包做人工审查。这三个动作，能让很多严重的 npm 供应链风险在早期就被拦截。