The npm team has added a human step back into the software supply chain, and that is worth pausing over. Staged publishing, now available in npm CLI 11.15.0+ and Node 22.14.0+, requires a maintainer to approve a version before it becomes installable. That approval is not a formality; it is a two-factor authentication challenge. The version sits in a queue until a human with the right credentials says yes. This is a deliberate counterweight to the automation that has made open-source publishing so fast and, increasingly, so dangerous.
We have seen what happens when that speed is weaponized. The same week npm announces this feature, our own reporting covers AI Agents Shared User Images, Highlighting Data Security Concerns and North Korean hackers linked to $351M Bitget crypto theft. The through-line is not subtle: the tools we trust to move code and money are being compromised at the point of release. A stolen token or a compromised maintainer account has historically been enough to push malicious code into millions of downstream installs. Staged publishing does not solve every attack vector, but it directly addresses the moment when a package transitions from private code to public dependency. That moment deserves a human gate.
For our readers, the practical takeaway is straightforward: this changes the default trust model. Previously, if you had publish credentials, you could ship. Now, npm is saying that possession of credentials alone is insufficient. The two-factor challenge is tied to the release action itself, not just the login. That means even if an attacker phishes a maintainer's password and steals their session token, they still need to complete a second factor at the exact moment of publication. We would tell any team running a private registry or a public package that this is not a feature to ignore. It is a permission structure that forces a pause, and pauses are cheap compared to incident response.
The new configurable permission flags that ship alongside staged publishing are equally important. They give maintainers finer control over what scripts can do during installation. That is a direct response to supply chain threats that weaponize postinstall scripts. We would advise reading those flag descriptions carefully and testing them in a staging environment before rolling out to production. The goal is not to make publishing tedious; it is to make compromise expensive. The open question we are watching is adoption. npm is a default for millions of developers, and defaults matter. If staged publishing becomes the standard for critical packages, the bar for a supply chain attack rises meaningfully. If it remains an opt-in afterthought, it is just another checkbox. Our honest take: this is the right direction, but the real test is whether the community treats a human approval step as a feature or a burden. We would tell any reader managing a popular package to adopt this now, before an incident forces the habit. The cost is a few seconds per release. The alternative is cleaning up a breach that shipped through your name.