# npm Strengthens Supply Chain Defenses with 2FA-Gated Publishing and Install Controls


GitHub has introduced two significant security enhancements to npm designed to defend against the escalating threat of supply chain attacks targeting open-source ecosystems. The updates—staged publishing and install source controls—represent a meaningful shift in how package maintainers can secure the release process and how developers can restrict dependency installation sources.


The measures arrive at a critical moment. Supply chain attacks have surged dramatically in recent months, with threat actors like TeamPCP poisoning popular packages at unprecedented scale through self-perpetuating cycles of compromise. These developments signal recognition that traditional publish workflows leave critical gaps in the software delivery pipeline.


## The Threat: Supply Chain Attacks at Scale


The open-source ecosystem has become a prime target for attackers seeking to compromise applications at scale. Rather than attacking individual organizations directly, threat actors have discovered that poisoning popular packages can reach thousands of dependent projects simultaneously—making the supply chain an asymmetrically attractive attack vector.


Common attack patterns include:


  • Compromised maintainer accounts — attackers gain credentials through phishing, credential reuse, or credential stuffing
  • Malicious package takeovers — abandoned or under-maintained packages are claimed and poisoned
  • Typosquatting — packages with names similar to popular libraries trick developers into installing malicious versions
  • Dependency confusion — exploiting version resolution logic to inject private package names into public registries
  • CI/CD pipeline compromise — automated release workflows without human verification gates

    • TeamPCP's recent campaign exemplified this threat, poisoning multiple high-profile packages in rapid succession. Each compromised package became a staging point for subsequent compromises, creating a cascading effect that exposed the fragility of relying solely on automated publishing workflows without human oversight.


    ## Background and Context: Why Automation Isn't Enough


    Historically, npm publishing has favored velocity over verification. Maintainers could publish directly from CI/CD pipelines using automated credentials, streamlining the release process but eliminating a critical human verification step. This model assumes:


  • The CI/CD environment is secure (often untrue)
  • Automated credentials cannot be stolen (consistently false)
  • Maintainer code is malicious-free (unrealistic given supply chain access)

    • The result: no cryptographic proof that a human authorized each release. An attacker gaining access to CI/CD credentials or a GitHub Actions workflow file could publish malicious code indistinguishable from legitimate releases.


    npm's staged publishing directly addresses this gap by reintroducing mandatory human review while preserving the benefits of automation for development and testing phases.


    ## Technical Details: How the New Controls Work


    ### Staged Publishing


    Staged publishing implements a two-phase release process:


    1. Upload phase — The prebuilt package tarball uploads to a staging queue via npm stage publish

    2. Approval phase — A maintainer must pass a 2FA challenge to approve the staged package for public availability


    Once approved, the package becomes installable on npmjs.com. The flow ensures "proof of presence"—cryptographic evidence that a human with 2FA-verified credentials explicitly authorized the release.


    Prerequisites for staged publishing:


  • Publish access to the package
  • Package must already exist on npm (no new package staging)
  • 2FA enabled on the maintainer account
  • npm CLI version 11.15.0 or newer

    • Example workflow:


    npm stage publish
# (human reviews in staging area)
npm publish <staged-version>  # With 2FA challenge

    GitHub recommends pairing staged publishing with trusted publishing using OpenID Connect (OIDC) for maximum protection. OIDC eliminates long-lived credentials entirely, replacing them with short-lived tokens issued per CI/CD job. This combination—OIDC for CI/CD + staged publishing for human approval—closes both the automated credential exposure vector and the unmanned release vector.


    ### Install Source Controls


    A parallel update introduces three new flags for npm install to restrict dependency sources:


    | Flag | Purpose | Use Case |

    |------|---------|----------|

    | --allow-file | Permits installs from local file paths and tarballs | Monorepo development, local package testing |

    | --allow-remote | Permits installs from remote URLs (HTTPS tarballs) | Secured CI/CD environments with strict controls |

    | --allow-directory | Permits installs from local directories | Workspace-based development |


    These flags join the existing --allow-git option to form an explicit allowlist approach for non-registry sources. By default, these sources are blocked unless explicitly enabled.


    Example:


    npm install --allow-file ./local-package.tgz
npm install --allow-remote https://example.com/package.tgz

    This granular control allows teams to enforce policy: development environments might allow all sources, while production CI/CD pipelines might restrict installs to the npm registry only (blocking unexpected file or remote installs that could signal compromise).


    ## Implications for Organizations


    For open-source maintainers:

    Staged publishing raises the baseline security for popular packages. High-value targets like frameworks and utilities should adopt it immediately. However, adoption requires discipline—the security benefit only manifests if maintainers actually use the feature for every release. The 2FA requirement also increases friction; maintainers must be prepared for slightly longer release cycles.


    For enterprise development teams:

    Install source controls provide a practical enforcement mechanism for supply chain policy. Teams can configure CI/CD pipelines to reject non-registry installs, reducing the attack surface for dependency confusion and typosquatting. This becomes particularly important as teams scale and onboard new developers who may not distinguish between official and malicious package names.


    For security-conscious organizations:

    These controls are table stakes but not sufficient alone. Layered defenses remain essential:

  • Software Bill of Materials (SBOM) tracking for all dependencies
  • Dependency scanning for known vulnerabilities (Snyk, Dependabot, npm audit)
  • Lock file enforcement to pin exact versions and detect drift
  • Policy-as-code tools to restrict which registries and sources are allowed
  • Behavioral monitoring for unusual install patterns or dependency resolution anomalies

    • For threat actors:

    These changes raise the cost of supply chain compromise but don't eliminate it. Attackers can still target newly compromised maintainer accounts, wait for adoption before poisoning, or pursue social engineering attacks on maintainers directly. The barrier moves higher, but the attack surface remains non-zero.


    ## Recommendations: Next Steps


    Immediate actions for maintainers:

    1. Update npm CLI to version 11.15.0 or newer

    2. Enable 2FA on all npm accounts with publish access

    3. Enable staged publishing for all production releases

    4. Audit existing CI/CD workflows to ensure OIDC-based trusted publishing is configured

    5. Document the new release workflow for all team members


    Recommended policy for development teams:

    # Production CI/CD configuration
npm install --no-save --allow-git=github.com/trusted-org/* --audit=audit
npm ci  # Lock file enforcement in production builds

    For security teams:

  • Mandate SBOM generation for all dependencies
  • Implement automated dependency scanning in CI/CD
  • Monitor for suspicious install patterns (remote URLs, file paths in production builds)
  • Require signed commits and verified releases for sensitive packages
  • Audit which developers have npm publish credentials

    • ---


    ## HackWire Analysis


    npm's staged publishing represents a meaningful recalibration of the open-source ecosystem's risk tolerance. For years, the industry accepted that convenience outweighed verification—maintainers could publish from CI/CD pipelines, users could install from anywhere, and humans rarely touched the release process. TeamPCP's campaign exposed how dangerous that assumption had become.


    What makes this update noteworthy is not that it solves supply chain attacks—it doesn't—but that it addresses a specific, high-leverage vulnerability: unmanned releases from potentially compromised automation. By forcing human review through 2FA-gated approval, npm has eliminated the scenario where an attacker with stolen CI/CD credentials can unilaterally poison a popular package. That's a real constraint on attacker capabilities.


    However, the adoption challenge is steep. Staged publishing requires discipline and coordination across teams. Many maintainers may view the extra friction as not worth the effort, especially for less critical packages. Adoption will likely concentrate among high-profile, well-resourced projects—exactly those targets most worth attacking. Smaller, newer packages will remain largely unprotected, preserving the low-hanging fruit for supply chain attacks.


    The install source flags are more immediately valuable. Teams that implement strict registry-only policies (blocking --allow-remote and --allow-file in production builds) can meaningfully reduce dependency confusion and typosquatting risk. This is tactical, implementable security that pays dividends immediately.


    The pattern worth noting: supply chain security is fragmenting into multiple specialized controls rather than consolidating into monolithic solutions. npm stages publishing, GitHub issues OIDC tokens, npm audits vulnerabilities, and Snyk/Dependabot watch for exploits. No single tool owns the problem; teams must compose a defense strategy from many pieces. That's more complex but also more resilient—compromise of any single tool doesn't cascade to compromise of the entire supply chain.


    For organizations shipping dependencies to others: staged publishing should be mandatory. For organizations consuming dependencies: install source controls should be enforced in CI/CD, and SBOM generation should be non-negotiable. The ecosystem is raising its baseline, but maturity is still optional.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [DevSecOps](https://www.hackwire.news/category/devsecops) and [Software Supply Chain](https://www.hackwire.news/category/software-supply-chain) security
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)