2.1 allowScripts 默认关闭#

这是影响最广的一项变更。从 npm v12 开始，以下生命周期脚本默认不再执行：

值得注意的是，隐式的 node-gyp 重建也会被阻止——即使某个包没有显式声明 install 脚本，但只要包含 binding.gyp 文件，安装时同样会触发原生模块编译，这在 v12 下也需要显式授权。

2.2 --allow-git 默认值为 none#

Git 依赖（"foo": "git+https://github.com/user/repo.git"）默认不再解析。这项变更关闭了一个关键的代码执行路径：Git 依赖的 .npmrc 文件可以覆盖 Git 可执行文件路径，攻击者可以借此绕过 --ignore-scripts 的限制。

2.3 --allow-remote 默认值为 none#

远程 URL 依赖（HTTPS tarball 等）同样默认不再解析，进一步缩小了未经审查的代码进入依赖树的窗口。

3.1 触目惊心的攻击数据#

npm 生态在过去一年经历了前所未有的供应链攻击浪潮：

3.2 不对称的信任模型#

传统的 npm 安装模型存在根本性的信任不对称：

• 只有 2% 的包真正需要运行安装脚本（如原生模块编译、平台二进制下载）
• 但 100% 的包都有能力在安装时执行任意代码
• 一个深度嵌套的传递依赖的 install 脚本，足以攻破整个系统

这种”默认信任一切”的模型在当前的威胁环境下已经不可持续。

3.3 pnpm 已经验证了这条路#

pnpm v10 在 2025 年 1 月率先实现了默认阻止生命周期脚本 + 显式许可名单的安全模型。一年多的实践证明：

• 绝大多数项目只需批准极少数的包（如 esbuild、sharp、node-gyp 等需要原生编译的包）
• CI/CD 流程可以通过 package.json 中的许可名单实现自动化
• 开发者体验的影响远小于预期，安全收益巨大

npm v12 的变更本质上是在 npm 生态中全面推广这一已验证的安全模型。

4.1 立即行动：升级到 npm 11.16.0+#

npm 11.16.0（2026 年 6 月发布）已经包含了 v12 所有变更的预警机制。升级后运行 npm install，你会看到 v12 将阻止哪些脚本的警告信息，而不是直接在 7 月被硬阻断。

1
# 升级到最新 npm 11
2
npm install -g npm@11
3

4
# 在项目中运行安装，观察警告
5
npm install

4.2 审查并建立许可名单#

npm 11 提供了全新的审批工作流：

1
# 查看所有有待审批安装脚本的包
2
npm approve-scripts --allow-scripts-pending
3

4
# 批准你信任的包（写入 package.json）
5
npm approve-scripts esbuild
6
npm approve-scripts sharp
7
npm approve-scripts node-gyp
8

9
# 拒绝不需要的包
10
npm deny-scripts some-suspicious-package

4.3 提交许可名单#

审批结果会写入 package.json，这是一个需要版本控制的团队决策：

1
{
2
  "name": "my-project",
3
  "dependencies": {
4
    "esbuild": "^0.27.0",
5
    "sharp": "^0.34.0"
6
  },
7
  "allowScripts": {
8
    "esbuild": true,
9
    "sharp": true
10
  }
11
}

许可名单的优势在于：

• 可审查：每次 PR 都能看到哪些包被授予了安装脚本权限
• 可追溯：Git 历史记录了每个信任决策的时间点和决策人
• 可自动化：CI/CD 直接读取 package.json，无需额外配置

4.4 处理 Git 依赖和远程依赖#

如果你的项目依赖了 Git 仓库或远程 URL：

1
# 在 .npmrc 或命令行中显式授权
2
npm install --allow-git=all          # 允许所有 Git 依赖
3
npm install --allow-git=foo/bar      # 只允许特定仓库
4
npm install --allow-remote=all       # 允许所有远程 URL 依赖

建议尽将 Git/远程依赖迁移到 npm 注册表的正式发布包，从根本上消除风险。

5.1 Docker 镜像#

如果你的 Dockerfile 中有 npm install -g 全局安装，需要确认这些包是否包含安装脚本：

1
# npm v12 的 Docker 镜像（node:24+ 将内置 npm v12）
2
FROM node:24
3

4
# 需要显式审批全局包的脚本
5
RUN npm approve-scripts -g esbuild
6
RUN npm install -g esbuild

5.2 GitHub Actions / 其他 CI 环境#

1
- name: Install dependencies
2
  run: |
3
    # package.json 中的 allowScripts 会被自动读取
4
    npm install
5
    # 如果需要额外授权（不推荐），使用：
6
    # npm install --allow-scripts=all

推荐的做法是将 allowScripts 写入 package.json 并提交，这样 CI 环境无需任何额外配置。

5.3 应急回退（不推荐）#

如果项目暂时无法完成迁移，可以通过以下配置恢复到旧行为：

1
# 全局恢复旧行为（高风险，不推荐）
2
npm install --allow-scripts=all --allow-git=all --allow-remote=all

但强烈建议这只是应急手段——攻击者正是依赖开发者长期使用这类”全开”配置。

立即行动清单#

1. 升级 npm：npm install -g npm@11
2. 运行一次完整安装：观察 v12 兼容性警告
3. 审查安装脚本：npm approve-scripts --allow-scripts-pending
4. 建立许可名单：对每个需要脚本的包做出明确决策
5. 提交到仓库：将 package.json 中的 allowScripts 纳入版本控制
6. 清理 Git/远程依赖：尽可能迁移到 npm 注册表正式包