npm's Staged Releases Offer a New Defense for Earth Science Software Supply Chains

For anyone who maintains research software, the past few years have been a lesson in paranoia. You write code, you push it to a registry, and you hope the next time someone runs npm install, they're getting what you intended—not a malicious fork injected by an attacker who hijacked your CI pipeline. That fear isn't hypothetical. The Shai-Hulud worm tore through the npm ecosystem, and the registry responded by deprecating traditional authentication tokens. Now npm has rolled out a feature that feels less like a band-aid and more like a deliberate step toward sanity: staged releases.

If you're building tools for Earth science—whether it's a data processing library, a climate model wrapper, or a geospatial analysis package—this matters. Your users often run your code on critical research infrastructure, and a compromised dependency can corrupt datasets or waste months of compute. Staged releases give maintainers a chance to look before they leap.

What Staged Releases Actually Do

The old flow was simple: you run npm publish, and the package is live for anyone to install. With staged releases, that's no longer the default. Instead, the tarball gets uploaded to a staging queue. It sits there, visible on npmjs.com and in the CLI, until a human maintainer explicitly approves it. That approval requires two-factor authentication. The staging itself doesn't need 2FA, so non-interactive CI pipelines can still push to the queue without interruption. The identity check happens later, at the gate.

The workflow ships with a set of subcommands:

• npm stage publish – submit the version to the stage queue
• npm stage list – list staged versions awaiting approval
• npm stage view <stage-id> – inspect the staged tarball
• npm stage approve <stage-id> – promote it to the registry, prompts for 2FA
• npm stage reject <stage-id> – discard it

That's it. Five commands, but they change the trust model. Instead of trusting the entire CI pipeline to be secure, you're trusting a human to review what's actually about to be released.

Why Earth Science Maintainers Should Care

Earth science software often sits in a weird spot. It's not as heavily audited as, say, financial trading systems, but it's used in contexts where failures have real consequences. A package that calculates flood risk or processes satellite imagery could be a vector for an attacker who wants to disrupt research or steal credentials. The Shai-Hulud attack proved that the npm registry is a target. Staged releases don't make your code immune, but they do close a specific, glaring hole: the ability for an attacker to push a malicious version directly to users by compromising your CI.

Security researcher Adnan Khan put it bluntly on X: everyone publishing to npm should enable this now. He's not wrong. If you're still using plain npm publish in your Earth science project, you're relying on the hope that your CI environment never gets compromised. That's not a strategy; it's a wish.

The Tooling: What You Need

Staged releases require npm CLI version 11.15.0 or later, Node.js 22.14.0 or higher, and the package must already exist in the registry. That last bit is important: you can't stage a brand-new package. You have to publish it once the old way, then switch to staged releases for subsequent versions.

The CLI flags you're used to—like --tag and --provenance—work exactly as they do with npm publish. So if you're already using provenance attestations, you can keep doing that. The staged release just adds a human approval step on top.

Pairing with Trusted Publishing

GitHub recommends combining staged releases with OIDC-based trusted publishing. You can configure your CI to only allow staging, not direct publishing. That way, even if an attacker grabs your GitHub token, they can't push a release without your 2FA approval. This is a meaningful improvement over the old model, where a compromised CI could publish anything.

If you're already using trusted publishing, migrating is straightforward. You update your workflow to use npm stage publish instead of npm publish, then add an approval step. The configuration you already have for trusted publishing can be reused.

New Flags and Future Defaults

Beyond staging, npm added three new flags: --allow-file, --allow-remote, and --allow-directory. These control which types of dependencies can be installed from outside the registry. They can be set to all or none, and configured in .npmrc or package.json. The existing --allow-git flag remains, but in npm v12, its default will change to none. That's a strong signal: the registry is moving toward stricter default permissions.

For Earth science projects that often pull in Git-based dependencies for unreleased features, this could cause friction. But it's a good reminder to pin your dependencies and avoid relying on moving targets.

Community Reactions: Mixed but Instructive

Not everyone is thrilled. Hacker News user weinzierl called staged releases a band-aid, arguing that it might distract from building more secure infrastructure. A reply countered that it's a major improvement, not a band-aid, because it eliminates a whole class of attacks targeting CI hijacking. That's a fair point. The feature doesn't solve every supply chain problem, but it does close a gap that was wide open.

Others question adoption. turkeyboi noted that the feature only helps if maintainers actually use it. Klaster_1 wondered whether it should be mandatory by default. On Reddit, a commenter argued that staged releases only slow down the spread of malicious packages, not stop them. All valid concerns, but slowing down an attack is often enough to prevent damage.

Competitors Are Following Suit

The package manager world didn't wait. pnpm 11.3 added pnpm stage with the same subcommands. Yarn has its own equivalent, and release-it supports a "stage": true option. pnpm also delays installation of newly published versions by default, adding another layer of protection. If you're already using pnpm, you get these features without switching.

What's Next

GitHub has laid out plans to make fine-grained access tokens that can bypass 2FA default to staging-only. In npm v12, they'll add an allowScripts field, and install scripts will no longer run by default. That's a big deal for Earth science packages that rely on postinstall scripts to compile native binaries or download data. You'll need to opt in explicitly.

For now, the immediate step is clear: if you publish any npm package related to Earth science, enable staged releases. It takes a few minutes to set up, and it gives you a human checkpoint before your code goes out to the world. In an ecosystem where a single compromised dependency can cascade across research groups, that's not just good hygiene—it's a professional obligation.