Registry Operator Constraints: Resourcing, Economics, And Incentive Alignment
Sources: 1 • Confidence: Medium • Updated: 2026-02-12 18:47
Key takeaways
- The npm team is perceived as under-resourced with a large backlog, contributing to slow responses unless issues become emergencies.
- Nicholas argued that a new registry run by an AI company would face major trust and operational barriers, and separately argued that reliability issues in hosted AI services would make an AI-native npm-compatible registry less compelling.
- About 500 npm packages were compromised in September 2025 alone.
- Trusted publishing currently lacks two-factor authentication, and OpenJS Foundation guidance recommends critical packages avoid it due to repo-takeover publishing risk.
- Recent malicious npm packages have targeted crypto theft and secret harvesting, including running TruffleHog to exfiltrate local secrets and propagate.
Sections
Registry Operator Constraints: Resourcing, Economics, And Incentive Alignment
- The npm team is perceived as under-resourced with a large backlog, contributing to slow responses unless issues become emergencies.
- Nicholas believes GitHub spinning npm off into a foundation is unlikely, and outlined a possible off-ramp involving joint funding via OpenJS to hire registry engineers.
- Running the npm registry is extremely expensive and was a key reason npm Inc. needed to sell, making the registry a major cost center for its owner.
- Nicholas claims npm's main differentiator versus other package ecosystems is scale, which makes many solutions harder to apply to npm.
- Nicholas explained that VC funding creates pressure to generate returns, and failure to monetize can lead investors to push for a sale.
- Nicholas expects npm is capable of real-time package upload analysis and signature-based blocking, but believes this capability is not being applied broadly enough to prevent repeated similar attacks.
Competitive Landscape: Alternative Registries And Client-Layer Mitigations
- Nicholas argued that a new registry run by an AI company would face major trust and operational barriers, and separately argued that reliability issues in hosted AI services would make an AI-native npm-compatible registry less compelling.
- JSR launched with reserved/confusing scopes, trusted publishing and 2FA requirements, and no pre/post-install scripts.
- pnpm shipped a client-side mitigation that blocks installing packages newer than about seven days to slow rapid spread of compromised releases.
- JSR's early rapid iteration and issue responsiveness degraded over time to the point that bug reports stopped getting responses.
- JSR's announced open-governance committee produced no visible progress or updates and effectively went nowhere.
- JSR did not support a workable way to publish npm packages that depend on JSR packages, leading at least one ESLint package to copy JSR source code into its own repository.
Npm Supply-Chain Compromise Magnitude And Attacker Mechanics
- About 500 npm packages were compromised in September 2025 alone.
- ESLint maintainers periodically receive suspicious pull requests that only change dependencies without explanation.
- ESLint is downloaded at a rate of over 200 million times per month.
- A common npm compromise pathway is stolen maintainer credentials followed by publishing a malicious package that uses preinstall/postinstall scripts to execute on install.
- Recent malicious npm packages have targeted crypto theft and secret harvesting, including running TruffleHog to exfiltrate local secrets and propagate.
- ESLint previously experienced an npm compromise enabled by a maintainer reusing credentials from another site that was hacked, which allowed unauthorized publishing.
Publisher Authentication Changes: Token Rotation Vs Oidc Trusted Publishing
- Trusted publishing currently lacks two-factor authentication, and OpenJS Foundation guidance recommends critical packages avoid it due to repo-takeover publishing risk.
- npm token policy changes converged on fine-grained tokens with a limited lifetime of about 90 days, requiring periodic rotation or automation.
- Scaling token and publishing changes was difficult for maintainers with many packages because npm initially lacked batch operations and required per-package setup with repeated 2FA prompts.
- Trusted publishing uses OIDC from CI (e.g., GitHub Actions) to mint short-lived npm publish tokens on demand instead of storing long-lived tokens.
- Trusted publishing is enforced by pre-registering a specific repository and a specific workflow file as the only allowed publishing source for a package.
- GitHub's npm security changes shift more responsibility and operational burden onto maintainers rather than addressing root causes at the registry level.
Install Scripts As An Ecosystem-Level Attack Surface With Constrained Mitigation Space
- Recent malicious npm packages have targeted crypto theft and secret harvesting, including running TruffleHog to exfiltrate local secrets and propagate.
- npm pre- and post-install scripts can execute arbitrary commands, creating a significant attack surface in a public registry context.
- Banning pre/post-install scripts on npm would break a non-trivial share of packages because native modules rely on those scripts to compile per-machine artifacts.
- Using npm's ignore-scripts option reduces risk but can silently break dependency trees that require compilation, making failures hard to debug.
- Nicholas proposed requiring a major version bump when a package adds install scripts to prevent automatic uptake via patch/minor updates.
- A proposed mitigation is heightened automated scrutiny or a waiting period for publishes that add or change install scripts.
Watchlist
- ESLint maintainers periodically receive suspicious pull requests that only change dependencies without explanation.
- The npm team is perceived as under-resourced with a large backlog, contributing to slow responses unless issues become emergencies.
- A gap was identified in maintainer-focused resources for leveling up security/operations, with a possible lead that OpenJS may have produced something similar.
- A single major npm supply-chain attack could plausibly cause multi-million-dollar damage and trigger serious reputational and possibly legal consequences for the registry operator.
- Jerod suggests that because JSR was intended to be open and governed, another party could potentially pick it up if the Deno team stops progressing it.
Unknowns
- What is the precise source, definition, and verification method for the 'about 500 compromised npm packages in September 2025' figure?
- How often do compromises involve account takeover versus malicious PR/contribution routes, and what share of incidents are driven by install scripts specifically?
- What are adoption rates of fine-grained expiring tokens and OIDC trusted publishing across high-impact npm packages, and how does adoption correlate with reduced incidents?
- What specific OpenJS guidance exists on trusted publishing for critical packages, and what changes would be required (e.g., step-up verification) for that guidance to change?
- Does npm actually perform real-time upload analysis and signature-based blocking at scale today, and what policies determine when it is applied?