npm 不忍了，正式上线“阶段式发布“的新功能，进一步对抗频繁的供应链攻击！

👇 今日要闻

打破信息壁垒，走近全球前端。Hello World 大家好，我是林语冰。

npm 是地球上最大的软件注册中心，也是前端开发的重要基建。

不幸的是，随着 AI 编程的崛起，赛博攻击的成本变低，npm 的安全频繁受到挑战。这一年来已经爆发了多次大型供应链攻击，波及 Axios 等流行生态。黑客利用 npm 发布和 GitHub CI/CD 部署的脆弱环节投毒或攻击，搞得下游的 npm 用户人心惶惶。

今天 npm 终于忍无可忍，GitHub 博客官宣，正式推出了新型发布功能：阶段式发布（Staged publishing）。这种发布思路类似于 Git 先将代码从工作区提交到暂存区、再提交到远程仓库的多阶段流程。

目前，npm 官方网站已经更新了《阶段式发布》的参考文档，这种新型发布机制能否更有效地对抗供应链攻击呢？本期我们就来速览一下其工作机制和注意事项。

阶段式发布与直接发布不同，不会立即向用户提供软件包的新版本。它在软件包正式上线到 npm 注册中心之前，需要额外的审核步骤。

具体而言，预构建的 tarball 压缩包会先上传到暂存队列，该队列在 npm 官网和 CLI 中均可见，但需要维护者审核并批准后才会公布，用户才能安装。

根据 npm 官网的《阶段式发布》指南，整个工作流程分为三大步骤。

阶段式发布不再使用 npm publish 直接发布，取而代之的是新命令，在软件包根目录运行下列命令：

这会将软件包提交到暂存区，等待维护者审核和最终批准发布，用户才能安装。

暂存软件包后，有两种方式对其进行审核。

一种是在 CLI 命令行界面，支持下列命令：

审核暂存包的另一种方式是在 npm 官网，打开"Staged Packages"（已暂存的软件包）标签页，审核已暂存的软件包，并找到需要批准的软件包。

最后，批准已暂存的软件包，并将其发布到 npm 注册中心，这同样有两种方式。

一是通过 CLI 命令：

二是在 npm 官网操作，在"Staged Packages "（已暂存的软件包）标签页中审核暂存的软件包，然后点击"Approve"（批准）。

分阶段发布对开发环境有最低的版本要求：

在集成 npm 阶段式发布之前，请确保当前的开发环境满足上述要求，你可以使用下列两个命令验证版本：

另外，库维护者需要确保下列权限：

GitHub 团队还建议将阶段式发布与 OIDC 可信发布结合使用。

可信发布可以限制为 仅阶段式发布 ，这意味着工作流中传统的 npm publish 命令会被拒绝，只能接受 npm stage publish 命令。CI 工作流将继续以非交互方式运行，稍后维护者可以通过 npm 官网或 CLI 命令行批准软件包已暂存的新版本。

当然，你也可以在本地运行 npm stage publish，但最佳实践是将 CI（持续集成）发布到暂存队列，并由维护者从可信设备进行批准，这样维护者在自己的电脑上有权发布，而黑客的电脑无法发布。

如果想了解更多阶段式发布和 OIDC 可信发布的使用细节，请参考文末提供的这三个 npm 新文档：

为了对抗供应链攻击，GitHub 官宣 npm 正式上线 Staged publishing（阶段式发布） 新功能。

不同于传统的 npm publish 直接发布，阶段式发布使用 npm stage publish 命令将新版软件包上传到暂存队列，要求维护者经过 2FA（双因验证）审核和批准，新版本才能正式发布，被用户安全下载。

npm 阶段式发布还可以和 OIDC 可信发布结合使用，集成到 CI/CD 持续部署到工作流，降低 npm 供应链攻击的风险。

👍 以上就是本期《前端日报》的全部内容了，如果读完对你有所帮助，可以按赞打卡、在看推荐或转发分享。

🙏 已经关注我的粉丝们，我们下期再见啦，掰掰~~

👇 参考文献：