npm自动发布最危险的一步,被拆成了“先暂存再批准”

npm自动发布最危险的一步,被拆成了“先暂存再批准”

💡 原文中文,约2600字,阅读约需7分钟。
📝

内容提要

npm 新增“仅暂存”细粒度令牌:工作流通过 npm stage publish 提交候选版本,维护者经 2FA 批准后发布,将上传与公开分离。令牌泄露无法直接发布新版本,但仍可修改 dist-tag、弃用版本,需按写权限管理。npm 计划 2027 年 1 月取消绕过 2FA 直接发布,团队应逐步迁移,先在低风险包演练,并保留审计与回滚。

🔎

延伸解读

阶段令牌的安全边界:只切断新版本发布

阶段专用令牌并非只读,它仍可移动dist-tag、弃用版本等。这些操作足以把latest指向错误版本,或让正常版本显示为不可用。因此,其安全增量在于切断“创建新公开版本”的路径,而非消除所有供应链风险。团队必须像管理其他写令牌一样,对其轮换、限制包范围并监控操作,不能因不能直接发布就放松警惕。

迁移策略:从低风险包开始演练

不要第一天就替换所有生产令牌。先选一个低风险包创建候选版本,分别演练正常批准、审查拒绝、候选过期和同版本重试,确认告警能区分“提交失败”与“等待批准”。随后将审计日志接入现有安全事件系统,并设置发布窗口与备用批准者,避免主要维护者离线时临时恢复高权限令牌。

人工批准需与源码提交建立稳定关联

如果审查者只看到版本号1.2.3,攻击者可能利用版本命名和并发工作流制造误批。候选包的版本号、Git提交摘要、工作流运行编号、依赖锁文件和包内容清单,至少要有一个不可混淆的关联键。把构建产物哈希写入发布说明,能让批准动作指向确定产物,防止双人流程退化为橡皮图章。

2027年政策变化前的行动清单

npm计划在2027年1月移除通过“绕过2FA”令牌直接发布的能力。本周可做四件事:盘点所有NPM_TOKEN;标记哪些令牌可以直接发布;为关键包试建stage-only令牌;在演练包上验证提交、拒绝、批准和回滚。完成迁移后,主动吊销旧令牌,并检查缓存、日志和历史配置里是否残留。

Q&A

npm 新推出的“仅暂存”令牌是什么?它和普通发布令牌有什么区别?

npm 细粒度访问令牌新增了 Read and write (stage only) 权限。工作流使用 npm CLI 11.15.0 或更高版本执行 npm stage publish,将包版本送入待审状态,随后由拥有发布权的维护者通过 2FA 批准才能公开发布。普通发布令牌可以直接执行 npm publish 上线新版本,而阶段专用令牌只能提交候选版本,不能直接发布。

使用 npm 阶段发布需要满足哪些环境要求?

需要 Node.js 22.14.0 或更高版本,npm CLI 11.15.0 或更高版本,并且包维护者权限和已启用 2FA。现有包可以直接使用,无需额外配置。

阶段专用令牌泄露后,攻击者还能做什么?

阶段专用令牌仍是写权限令牌,泄露后攻击者虽然不能直接发布新版本,但仍可以移动 dist-tag、弃用版本等。这些操作足以把 latest 指向错误版本,或让正常版本显示为不可用。因此必须像其他写令牌一样轮换、限制包范围并监控操作。

如何为现有项目配置一个只提交候选版本、不自动批准的工作流?

先在 npm 后台创建只覆盖目标包的 stage-only 令牌,保存为仓库机密 NPM_STAGE_TOKEN。工作流使用 workflow_dispatch 触发,步骤包括:检出代码、设置 Node.js 22.14.0、npm ci、npm test、npm version 更新版本号、npm pack --dry-run 检查文件,最后运行 npm stage publish 并通过环境变量注入令牌。注意令牌不能写入 .npmrc 并提交。

npm 计划何时取消绕过 2FA 直接发布?团队应如何迁移?

npm 计划在 2027 年 1 月移除通过“绕过 2FA”令牌直接发布的能力。团队应逐步迁移,不要第一天就替换所有生产令牌。先选一个低风险包创建候选版本,演练正常批准、审查拒绝、候选过期和同版本重试,确认告警能区分“提交失败”与“等待批准”。然后将审计日志接入安全事件系统,设置发布窗口与备用批准者,最后吊销旧令牌并检查残留。

人工批准阶段发布时,审查者应该关注哪些信息以避免橡皮图章?

审查者应看到版本差异、npm pack 文件清单、测试结果、来源证明和变更日志,而不是只点“批准”。批准页面还应与源码提交建立稳定对应,候选包的版本号、Git 提交摘要、工作流运行编号、依赖锁文件和包内容清单至少要有一个不可混淆的关联键。把构建产物哈希写入发布说明,可以让批准动作指向确定产物。

🏷️

标签

➡️

继续阅读