The npm ecosystem has faced an increased wave of supply chain attacks, and security practices around publishing JavaScript packages are changing fast.

The OpenJS Foundation and its Security Collaboration Space are focused on keeping the ecosystem safe and reliable for the developers and communities who depend on it. As stewards of many of the web’s most-used JavaScript projects, we take that responsibility seriously.

Lately, we’ve been working closely with GitHub’s npm team to understand how new security features affect projects and maintainers, especially as threats and tools keep evolving.

Why npm Security is so Important

JavaScript powers virtually everything: browsers, mobile apps, IoT devices, TVs, and AI models on the web. npm is the distribution backbone for this global footprint. Its scale makes it a high-value target.

npm serves 17M registered developers and powers ~370B monthly downloads. The average JavaScript project pulls in ~683 transitive dependencies, which is orders of magnitude more than typical projects in other languages.

This compounding dependency depth, plus the ubiquity of JavaScript across the stack, means package publishing is a security-critical operation. The more visible and auditable the publishing trail, and the more resilient the authentication flow, the better off the entire web is.

npmjs.com’s implementation of Trusted Publishing is promising for JavaScript, but it’s not ready for critical packages just yet. Some controls, like even the possibility of enforcing 2FA, still need to mature to ensure maintainers aren’t exposed to hard-to-detect risks.

The OpenJS Security Collaboration Space has compiled recommendations for publishing securely.

Three Current Paths to Publish JavaScript

Given the active threats and evolving landscape, maintainers need practical guidance to evaluate their options. There’s no single solution for every project, security is always a spectrum. Below we outline three approaches for publishing securely to npm and the trade-offs of each.

1) Local Publishing (Most Secure Today)

Publishing locally with strong personal auth (non-SMS 2FA) remains the most predictable and secure route for many projects.

Why

• Clear public auditability of the publisher’s identity
• Fewer opaque moving parts than CI pipelines
• Lower blast radius if something goes wrong

Trade-offs

• Manual/serial process can slow larger teams
• Requires careful handling of local credentials

When to favor it: Security-critical libraries with a small, trusted maintainer set.

For an in-depth review: Check this GitHub repository

2) CI-Based Publishing (Balanced, but Complex)

Automating releases via CI centralizes the workflow for multi-maintainer projects, but adds risk.

If your project already uses CI for releases, be aware that recent changes to npm’s token system will affect your workflows. Starting December 9, npm will revoke all existing classic tokens and prevent the creation of new ones.

Even if you’ve migrated to granular tokens, any existing tokens with longer expiration dates will be automatically capped to February 3, 2026. After that date, all newly created tokens with write access scope will have a maximum allowed lifespan of 90 days, requiring regular rotation.

These changes may disrupt existing release pipelines, including those that follow the previously recommended setup in GitHub’s official documentation.

Benefits

• Repeatable, standardized releases for larger teams
• Single, controlled entry point for publish
• Supports 2FA before publishing (but is easy and common to accidentally use in a one-factor manner)

Risks

• Bot accounts obscure who actually published
• Private audit logs mean the broader ecosystem can’t quickly validate anomalous publishes
• Any CI compromise can lead to silent, high-impact incidents
• Requiring npm 2FA requires a third-party server

Hardening tips

• Use a dedicated “release” repo with very limited access
• Require review gates/environments; alert via Slack/webhooks on publish
• Keep least-privilege scoped tokens and short lifetimes where required

Trade-offs

• Requires a manual token rotation at minimum every 90 days by design from Nov 19.
• The 2FA step requires additional setup and trust an additional external service like step-security/wait-for-secrets

For an in-depth review: Check this GitHub repository

3) Trusted Publishing (Not Yet Recommended)

GitHub’s token-less approach is an important step, but today we don’t yet recommend it for high-value packages, though we’re encouraged by GitHub’s progress.

Why (current gaps)

• Incomplete controls (e.g., 2FA enforcement paths)
• Edge-case weaknesses that maintainers can’t fully mitigate yet
• Fragile provenance configuration in setup, like case-sensitivity, mismatched registry URLs, or naming inconsistencies, can silently break provenance and cause confusing publish failures.
• On-boarding packages is a manual per-package process and cannot (yet, see Github/npm’s plan for details) be done in bulk for an Org or User.
• Once onboarded, packages with directly added users can still be published via token based workflows, additionally it can just turned off or edited in case of an account takeover
• Many maintainers oversee hundreds of packages, and manually configuring individual workflows and repositories for each is not scalable today.

We believe Trusted Publishing represents the future, but it’s not yet ready for adoption in critical projects, as in its current state it wouldn’t prevent attacks such as Shai-Hulud and other recent ones.

For an in-depth review: Check this GitHub repository

Current Recommendations

We appreciate GitHub’s responsiveness and progress. We’ll keep collaborating and will update this guidance as capabilities mature. To summarize:

• Small/critical projects: Use local publishing with 2FA and logout and decommission login tokens on npmjs.com once you are finished with the release process.
• Multi-maintainer teams: Harden CI, limit bot privileges, ensure observable publishes.
• Security-sensitive packages: Defer Trusted Publishing until key controls mature and the process becomes scalable for large maintainers.

This balances practical maintainability with verifiable trust that is crucial in an ecosystem where a single publisher can cascade across hundreds of transitive dependencies and millions of weekly downloads.

Our Shared Responsibility

The JavaScript ecosystem is enormous, interdependent, and essential infrastructure. Maintaining public auditability, traceable ownership, and responsible authentication practices is how we reduce risk at npm’s scale.

The npm team has been responsive to community feedback, and we’re committed to continuing this collaboration while giving maintainers actionable guidance today.

The OpenJS Security Collaboration Space will continue publishing updates as GitHub and npm evolve their model. We’ve also prepared example repositories demonstrating each setup (local, hardened CI, and the current state of Trusted Publishing) so maintainers can compare configurations side-by-side and understand trade-offs quickly.

About the OpenJS Security Collaboration Space

The OpenJS Security Collaboration Space is a working group through the OpenJS Cross Project Council (our technical advisory committee). We bring together maintainers, security experts, and partners to raise the bar for JavaScript supply-chain security. To get involved, join us on Mondays in the Security Collab Space, visit openjsf.org or join our public Slack where you can chat with us on the #security and #npm channels and more.