Package managers have become a critical attack surface. When a library reaches thousands of downstream projects, a single compromised release can propagate compromise at massive scale. npm has now introduced staged publishing—a feature that inserts a mandatory human approval gate, protected by two-factor authentication, between a release build and public availability.
The supply chain problem
Attackers have repeatedly exploited the speed and automation of package publishing. A maintainer's credentials can be harvested; a build system can be poisoned; a developer account can be compromised in a moment of inattention. Once a malicious version is live on npm's registry, it propagates to every downstream consumer running an update—often automatically, often within minutes. Detecting and revoking a poisoned package requires manual intervention, coordination, and often creates a window where millions of developers are exposed.
The problem is particularly acute in open-source ecosystems where a single engineer might maintain dozens of packages with millions of weekly downloads, often with limited security infrastructure.
How staged publishing closes the gate
Staged publishing decouples build automation from publication. A maintainer (or CI/CD pipeline) can prepare a release and upload it to npm with a special flag that marks it as staged. The package remains invisible to npm install commands and dependency resolution. To make it publicly available, a human must explicitly approve the release by passing a 2FA challenge. This approval step cannot be automated or delegated to a bot.
The benefit is that even if a build system is compromised—even if an attacker gains temporary write access to npm credentials—they cannot unilaterally publish a package without satisfying a second authentication factor that lives outside the CI/CD infrastructure. It forces a human moment of awareness into a process that has otherwise become entirely frictionless.
Adoption friction and practical constraints
Mandatory approval gates introduce latency and operational overhead. For high-velocity projects releasing daily or multiple times per day, requiring a human sign-off on every release becomes a bottleneck. npm has wisely made staged publishing opt-in, allowing maintainers to adopt the feature on a per-package basis.
The real friction, however, lies in cultural adoption. Many open-source maintainers already use 2FA on their npm accounts—but they may not change their existing publication workflow to adopt staged publishing unless they perceive a direct threat. Security features are most effective when they become standard practice, not an optional hardening measure available only to paranoid engineers.
Broader implications for infrastructure security
This development mirrors a broader shift in how infrastructure teams think about supply chain risk. Organisations managing thousands of dependencies now implement Software Bill of Materials (SBOM) tracking, dependency pinning, and lock-file enforcement in their CI/CD pipelines. Staged publishing is npm's contribution to that same principle: verifiable control over what gets released.
For teams running private package registries or self-hosted artifact stores, staged publishing validates the patterns they've already adopted. The gap between npm's public model and a private Artifactory or Nexus instance narrows further—both can now enforce approval workflows at the publication boundary. GitHub's rollout of these controls also signals that GitHub Actions users may see tighter integration between staged publishing and CI/CD workflows, reducing friction for teams already running their pipelines on the platform.
The staged publishing feature alone will not prevent all supply chain attacks. It raises the bar: an attacker must now compromise both CI/CD credentials and the 2FA token, or they must compromise the maintainer's personal approval process. For most attackers, that increased friction is enough to move to softer targets. For truly determined adversaries targeting a specific high-value library, the feature forces them to pursue physical or social attacks rather than pure infrastructure compromise.
The real value lies not in perfect security, but in shifting the cost of attack upward and reintroducing human judgment into a process that has become entirely automated. As supply chain attacks continue to mature, that friction becomes essential.
