npm's New Staged Publish: A Human Gate for Supply Chain Security

The Short Version: What npm Just Changed

npm, the default package manager for Node.js, has finally switched on its staged publish feature. The idea is simple: instead of pushing a version straight to the registry where anyone can install it, the tarball first lands in a staging queue. A human maintainer then has to eyeball it, pass two-factor authentication, and explicitly approve it before the package becomes public.

This is a notable departure from the old flow, where publish was publish, and the world could grab your code the second you hit Enter. Now there's a deliberate pause, a checkpoint, a moment for someone to actually look at what's about to ship.

The Nuts and Bolts of Staged Publish

The workflow comes with a set of subcommands. You stage a version, list what's waiting, inspect a specific tarball, approve it, or reject it. The commands are straightforward: npm stage publish, npm stage list, npm stage view <stage-id>, npm stage approve <stage-id>, and npm stage reject <stage-id>. Approval prompts for 2FA—that's the human gate.

One thing worth noting: the staging step itself doesn't require 2FA. That's a deliberate choice to keep non-interactive CI pipelines running smoothly. The identity check happens later, at approval time. So your automated build can still push a version to the queue without someone typing a code, but a person has to step in before it goes live.

There are a few prerequisites. You need npm CLI version 11.15.0 or higher, Node.js 22.14.0 or newer, and the package must already exist in the registry. This isn't for brand-new packages—it's for updates to existing ones.

The Security Context: Why This Matters Now

This isn't a random feature drop. It's a direct response to a nasty stretch of supply chain attacks. There was the Shai-Hulud worm, which did some real damage, and the broader push to deprecate traditional tokens. Security researcher Adnan Khan put it bluntly on X: every developer publishing to npm should enable this now. His suggestion: use OIDC in CI, publish to the staging queue, and review before the package goes public.

The threat model is clear. If an attacker compromises your CI environment—say, by stealing credentials or injecting malicious steps—they could publish a tainted version directly to the registry. With staged publish, they'd only be able to push to the staging queue. The final approval still requires a human with 2FA, which is a much higher bar to clear.

Mixed Reactions: Is This a Band-Aid or a Real Fix?

The community has been, predictably, split. On Hacker News, user weinzierl called staged publish a band-aid, warning that it might actually undermine longer-term efforts to build more secure infrastructure. That drew a sharp rebuttal: for trusted publishing, this isn't a band-aid—it's a major improvement that closes a whole class of attacks targeting CI hijacking. Sure, attackers might find other ways, but this plugs a huge hole.

Others questioned adoption. Turkeyboi pointed out that the feature only helps if maintainers actually use it. Klaster_1 wondered whether npm should force it on by default. Over on Reddit, a commenter argued that this only slows down the spread of malicious packages—it doesn't solve the underlying supply chain problem.

Those are fair points. Any security control is only as good as its adoption rate. If most packages never use staged publish, the ecosystem's risk profile barely changes. The question of default enforcement is a real one, but npm has historically been cautious about breaking changes.

Competitors Are Already Copying the Playbook

Rival package managers didn't waste time. pnpm 11.3 added pnpm stage with the same subcommands. Yarn has its own equivalent. release-it supports a "stage": true option. pnpm also added a default delay for installing freshly published versions, giving maintainers a window to catch problems before the wider community pulls them down.

This is a good sign. It means the industry recognizes the value of a human checkpoint, and it's not just an npm-specific quirk. When multiple tools converge on the same pattern, it becomes a de facto standard.

What's Next: Tighter Defaults and More Controls

GitHub has laid out a roadmap. Fine-grained access tokens that can bypass 2FA will soon be restricted to staging-only by default. And in npm v12, there's a new allowScripts field that will make install scripts opt-in rather than opt-out. That's a big deal—install scripts have been a common vector for malicious code, and flipping the default is a significant hardening step.

The CLI reference also lists flags like --tag and --provenance, which behave exactly as they do with npm publish. So the transition shouldn't be jarring for teams already using those options.

There are also new parameters: --allow-file, --allow-remote, and --allow-directory, joining the existing --allow-git. These can be set to all or none via .npmrc or package.json. In v12, --allow-git defaults to none, which will break some workflows but also close off a common footgun.

Should You Turn It On?

If you maintain any npm package that gets regular updates, the answer is probably yes. The setup isn't trivial—you need to upgrade your toolchain, adjust your CI scripts, and get used to a new approval step—but the security win is substantial. The alternative is leaving your publishing pipeline wide open to CI hijacking, which is exactly the kind of attack that's been making headlines.

For teams already using trusted publishing with OIDC, the migration path is smooth. GitHub recommends combining staged publish with OIDC-based trusted publishing, configuring it to only allow staged releases. That way, a direct npm publish from CI gets rejected, and the only path to the registry goes through the staging queue.

Staged publish isn't a silver bullet. It won't stop every supply chain attack, and it doesn't address issues like typosquatting or malicious dependencies. But it does add a human layer to a process that was previously all automated. In a world where a single compromised CI pipeline can poison thousands of projects, that human gate is worth something.

The real test will be adoption. If enough maintainers switch, the ecosystem becomes measurably safer. If it stays a niche feature, it's just another tool in the box—useful, but not transformative. Either way, it's a step in the right direction, and it's good to see package managers finally taking supply chain security this seriously.