npm分阶段发布正式上线 人工审核防供应链投毒

一、npm 分阶段发布：发包流程多了一道人工审批关卡

开源生态最庞大的软件包仓库 npm 近日正式上线了分阶段发布（Staged Publishing）功能：一个版本在被用户安装之前，必须先经过维护者的显式审批。过去开发者执行 npm publish 后，新版本会立即对全球用户开放安装；而现在，预构建的压缩包会被上传到一个暂存队列，该队列在 npmjs.com 网站和命令行工具中均可见，维护者必须完成双因素身份验证（2FA）才能正式放行发布。

这个设计巧妙地把"身份核验"后置到了审批环节：暂存阶段本身不需要 2FA，兼容所有类型的令牌，因此非交互式的 CI 流水线不受影响，发包动作可以继续自动化。工作流包含一组新子命令：npm stage publish 将版本提交到暂存队列，npm stage list 查看待审批版本，npm stage view 检查暂存压缩包内容，npm stage approve 放行发布（会提示输入 2FA），npm stage reject 则直接丢弃。该功能要求 npm CLI 不低于 11.15.0、Node.js 22.14.0 及以上，且软件包必须已存在于注册表中。

二、直击 CI 劫持投毒：这道关卡解决了什么问题

分阶段发布推出的直接背景，是接连爆发的软件供应链攻击事件——先是破坏性极强的 Shai-Hulud 蠕虫攻击，随后 npm 官方开始弃用传统发布令牌。这类攻击的典型路径是：攻击者通过漏洞或钓鱼劫持开发者的 CI 环境，窃取发布令牌后向注册表直接推送恶意版本，下游项目在依赖更新时被批量投毒。由于发布过程完全自动化、无人工干预，恶意版本可以在数分钟内扩散到海量用户。

分阶段发布把"发布"拆成了"提交"与"审批"两步：即使发包令牌被劫持，恶意版本也只能停留在暂存队列，无法进入注册表被用户安装；而审批环节要求人工维护者输入 2FA，这是攻击者无法轻易自动绕过的一道关卡。GitHub 建议将分阶段发布与基于 OIDC 的可信发布（Trusted Publishing）结合使用，把配置限定为仅允许暂存发布，这样工作流发起的直接 npm publish 将被拒绝，进一步压缩攻击面。同期更新的还有 --allow-file、--allow-remote、--allow-directory 等参数，用于收紧非官方来源的依赖，npm 12 中 --allow-git 的默认值也将改为 none。这与我们此前介绍的 npm 12 默认禁用依赖安装脚本一起，构成了"发布侧审批+安装侧拦截"的供应链双重防线。

三、生态跟进与争议：创可贴还是防线升级

安全研究员 Adnan Khan 在社交平台上直言：所有向 npm 发布软件包的开发者都应当立即启用该功能，通过 OIDC 在 CI 环境执行发包操作，并在软件包对外开放前完成审核。不过社区也存在分歧：有开发者认为分阶段发布只是"创可贴"，长期看可能麻痹人们对基础设施安全建设的努力；立刻有人反驳称，对可信发布来说这不是创可贴而是重大改进，它堵住了 CI 环境劫持发包这一巨大的攻击缺口。也有声音质疑采用率——"只有维护者真正使用它时才有帮助"，并提议是否应当默认强制开启；还有评论认为该方案只能降低恶意包的扩散速度，算不上根治供应链问题的良方。

竞品包管理器迅速跟进：pnpm 11.3 增加了子命令完全一致的 pnpm stage，并默认延迟安装刚发布不久的新版本作为配套防护；Yarn 与 release-it 也提供了对应能力。GitHub 公布的后续计划还包括：默认将可绕过 2FA 的细粒度访问令牌设为仅允许暂存，在 npm 12 中增加 allowScripts 字段、将安装脚本改为默认不执行。可以预见，人工审批、双因素认证、最小权限令牌将成为开源包发布的标准配置。

四、对青海政企软件供应链安全的启示

青海政企信息化建设中，从政务网站到业务系统，大量应用深度依赖 npm 等开源生态。本次 npm 的调整给本地安全管理者三点启示：其一，凡涉及自研或外包开发的团队，应推动启用分阶段发布与可信发布，把发布审批纳入变更管理流程，杜绝"一键发包无人把关"；其二，对第三方依赖坚持锁文件加版本固定，同步开展漏洞扫描与软件成分分析（SCA），建立 SBOM 清单以便快速定位受影响的组件；其三，将供应链安全纳入等保 2.0 安全管理体系，对关键信息系统的开源组件实行上线前审计，警惕安装脚本类恶意行为。开源组件投毒已成常态，防御重心应从事后响应前移到发布环节管控，这一步越早做，代价越小。