npm Rolls Out Staged Publishing and Install Controls to Combat Supply Chain Attacks

GitHub has deployed mandatory staged publishing controls for npm that force human verification before packages become publicly available. The feature requires maintainers to pass a two-factor authentication challenge to approve releases, eliminating direct-to-registry publishing even from automated CI/CD pipelines. This represents the most significant security change to npm's publishing workflow since the platform began requiring 2FA for top maintainers.

How Staged Publishing Works

Instead of the traditional immediate publish model, staged publishing introduces a two-step verification process. When developers run 'npm stage publish' from their package root directory, the prebuilt tarball uploads to a staging queue rather than directly to npmjs.com. A maintainer with publish access must then explicitly approve the package through a 2FA challenge before it becomes installable by the broader ecosystem.

The system provides what GitHub calls 'proof of presence' for every publish operation. This applies universally—whether packages come from local development environments, non-interactive CI/CD workflows, or trusted publishing systems using OpenID Connect authentication. The requirement removes the automation gap that attackers have exploited to inject malicious code through compromised CI/CD pipelines.

New Install Source Controls

GitHub simultaneously introduced three new command-line flags that give developers granular control over package installation sources. These flags join the existing --allow-git option to create a comprehensive allowlist approach for non-registry installs:

• --allow-file: Controls installations from local file paths and local tarballs
• --allow-remote: Controls installations from remote URLs, including HTTPS tarballs
• --allow-directory: Controls installations from local directories
• --allow-git: Previously existing flag for Git-based installations

These flags enable security teams to enforce explicit policies about acceptable package sources. Organizations can now block untrusted installation vectors by default while maintaining selective access to approved sources. This granular control is particularly critical for enterprises with strict software provenance requirements.

The TeamPCP Context

These controls arrive amid what GitHub describes as a 'massive surge' in software supply chain attacks over recent months. The cybercriminal group TeamPCP has poisoned popular packages at unprecedented scale through a self-perpetuating compromise cycle. Attackers gained access to maintainer accounts or CI/CD systems, published malicious versions that appeared legitimate, then used those compromised packages to further expand their reach across the dependency tree.

The staged publishing model directly counters this attack pattern. Even if attackers compromise a CI/CD pipeline or obtain publishing credentials, they cannot push malicious packages without passing a real-time 2FA challenge. This breaks the automation that makes large-scale poisoning campaigns feasible. The TeamPCP incidents demonstrated that automated publishing workflows, while convenient for legitimate developers, provided attackers with the same scalability advantages.

Operational Impact for Development Teams

The staged publishing requirement introduces friction into previously automated release processes. Teams must now designate maintainers who can respond to 2FA challenges during release windows. This affects organizations with overnight or weekend deployments, requiring on-call maintainer coverage or adjusted release schedules. The CLI version requirement (11.15.0 minimum) also necessitates updates across development environments and CI/CD systems.

For security teams, the new install flags require policy decisions and potential build script modifications. Organizations must determine which installation sources they'll permit and update their npm commands accordingly. The default behavior without these flags may block previously functional workflows that relied on non-registry sources. Testing in staging environments is essential before rolling these controls to production builds.

Measuring Effectiveness

The success of these controls depends on adoption rates and attacker adaptation. Staged publishing only protects packages whose maintainers opt in and maintain active 2FA. The npm ecosystem contains millions of packages with varying maintenance levels—abandoned or infrequently updated packages remain vulnerable. Organizations should prioritize monitoring their direct dependencies for staged publishing adoption and consider this factor in dependency selection criteria.

The install source flags provide immediate value but require proactive configuration. Unlike staged publishing (which package maintainers control), these flags place responsibility on package consumers. Security teams should audit their dependency installation patterns to identify which flags they need and establish organization-wide standards. The explicit allowlist model means accidental omissions could break builds, making comprehensive testing critical before enforcement.

Recommendations

Maintainers of packages with significant downstream dependencies should enable staged publishing immediately and upgrade to npm CLI 11.15.0 or newer. Configure OIDC-based trusted publishing for your CI/CD workflows before enabling staging to minimize manual intervention requirements. Document your approval process and establish SLAs for responding to staged package approvals to avoid blocking dependent projects.

Security and DevOps teams should inventory their npm installation sources across all build environments. Implement the new install flags starting in development environments with monitoring to identify legitimate workflows that require specific sources. Gradually roll out restrictions to staging and production with clearly documented policies. Audit your critical dependencies for staged publishing adoption and consider this in vendor risk assessments. For packages without staged publishing, implement additional verification steps such as lockfile reviews and automated security scanning before accepting updates.