Will npm's new security steps stop attacks?

GitHub has tightened security rules for developers publishing packages to the npm registry as part of a broader effort to better protect against threats such as the recent Shai-hulud self-replicating worm, which spreads via compromised developer tokens.

The changes significantly raise the bar for npm security, but other critical attack surfaces persist. Weakly protected CI/CD systems, compromised dependencies, and social engineering tactics continue to pose threats that extend beyond the authentication and publishing controls instituted by GitHub.

Here’s what you need to know about the new measures — and why you need modern application security practices and controls beyond baseline features. 

Join Oct. 30 webinar: Anatomy of a Software Supply Chain Attack

Attacks push repos to boost security hygiene

GitHub, which maintains the npm registry, announced the measures to harden the npm package publishing process against account takeovers and malware injection one month ago. It took the action after ReversingLabs informed it on September 14 about its discovery of Shai-hulud, a self-replicating worm that infected hundreds of packages on npm via compromised maintainer accounts. The infected packages cumulatively accounted for millions of downloads from npm, making Shai-hulud a high-impact compromise.

To protect against similar attacks, GitHub said, it would require two-factor authentication (2FA) for all local publishing, limit token lifetime to seven days, and promote the use of trusted publishing.

In the coming months, GitHub will deprecate legacy authentication methods, including classic tokens and time-based, one-time passwords (TOTPs), in favor of FIDO-based 2FA. Developers publishing a package directly from their own machine (local publishing), rather than via a trusted, automated system (trusted publishing), will need to use hardware security keys, biometrics, authenticator apps, or some other form of 2FA to authenticate themselves.

Any publishing tokens that remain will now be more granularly scoped, meaning it grants developers only limited, specific permissions on npm. GitHub will set the tokens to expire after seven days to reduce the risk of misuse if an attacker manages to compromise these tokens.

What is trusted publishing — and how does it work?

GitHub will more aggressively promote the use of trusted publishing for npm packages.  Trusted publishing allows maintainers to publish packages to npm from trusted CI/CD platforms such as GitHub Actions and GitLab CI/CD. To publish to npm, a developer triggers a GitHub Actions (or GitLab CI/CD) workflow, which automatically authenticates to npm using short-lived OpenID Connect (OIDC) tokens that prove the workflow’s identity. This approach eliminates the need for developers to create, store, and manage API tokens in their build pipelines. The maintainers of several other public repositories, including the Python Package Index (PyPI) and RubyGems, already use this method.

GitHub wrote in its blog post about the new measures: 

When npm released support for trusted publishing, it was our intention to let adoption of this new feature grow organically. However, attackers have shown us that they are not waiting. We strongly encourage projects to adopt trusted publishing as soon as possible, for all supported package managers.

Currently, npm supports Trusted Publishing for GitHub Actions and GitLab CI/CD, with plans to expand support to additional build pipelines.

Jeff Williams, co-founder and CTO of Contrast Security, said that the measures, taken together, bolster npm security against Shai-hulud-type attacks. GitHub is closing several of the gaps that Shai-hulud exploited, he noted. 

These are real improvements. Mandatory 2FA, short-lived tokens, and expanded trusted publishing will make it much harder for attackers to steal credentials or push malicious packages.

Jeff Williams

But the new measures will not completely eliminate the risk from the next Shai-hulud, Williams stressed.

What these changes don’t fix

Williams said a deeper problem that these new steps can’t solve is that the open-source software (OSS) ecosystem remains effectively anonymous. Most maintainers are just usernames with limited or no organizational backing, little vetting, and no accountability. 

Stronger authentication can help ensure that the real maintainer is logging in, but that won’t stop a maintainer who is actually an attacker who earned trust through legitimate contributions. 

In open source, identity is still largely a social construct, not a verified fact. There are many organizations with the motivation, expertise, and funding to infiltrate almost any open-source project, regardless of these defenses.

Jeff Williams

The fact that many OSS projects, including some of the most widely used ones, have little financial backing from their biggest users is a central issue, given the broad reliance on open source. Just recently representatives from Alpha-Omega, the Eclipse Foundation, the OpenJS Foundation, OpenSSF, Packagist, the Python Software Foundation, the Rust Foundation, and Sonatype warned that the situation is reaching a breaking point and needs solid commitments of support from major users of the OSS ecosystem.

Trusted publishing is welcome

Williams said that trusted publishing is the biggest win. “Moving away from long-lived tokens toward OIDC-based, short-lived credentials removes one of the main weapons attackers use once they compromise a developer account or CI pipeline.” GitHub’s move to set seven-day token expiration and mandatory 2FA also reduces the window of opportunity for abuse and hardens the perimeter. But he reiterated that it doesn’t fix everything.

They still can’t address the problem of malicious insiders or compromised maintainers.

Jeff Williams

Karlo Zanki, reverse engineer at ReversingLabs, agreed that GitHub’s push toward broader adoption of trusted publishing is a significant change and that the other measures are less impactful. And he sees other vulnerabilities.

While the new, granular tokens give more control than legacy tokens, the bigger number of configuration options automatically increases the risk of misconfiguration.

Karlo Zanki

He also noted that the shorter life of granular access tokens wouldn’t have prevented Shai-hulud from spreading because it was publishing new packages immediately upon infection. In addition, conceptually at least, the use of tokens has not been abandoned, he noted. 

Highly privileged tokens that can be used for publishing from CI/CD frameworks and reused several times still exist.

Karlo Zanki

How will stressed maintainers cope with new friction?

How GitHub’s changes will impact maintainers pushing packages to the registry is an open question. Maintainers who still rely on personal access tools, classic tokens, and TOTPs will likely feel a short-term impact, said Jason Soroko, a fellow at Sectigo. 

Soroko said teams should inventory every publish path and migrate CI to trusted publishing with OIDC. They need to swap any remaining TOTP to hardware-backed WebAuthn, adopt short-lived granular tokens only where absolutely needed, and run rehearsal publishes to catch breakages early.

I would like to see org-wide provenance and attestation enforced by default. [Also needed] are automated anomaly detection that can quarantine suspicious releases before wide distribution, first-class package rollback with consumer notifications, and stronger account recovery with passkey-only flows and device binding.

Jason Soroko

Williams said much depends  on how OSS developers, who are for the most part unpaid volunteers, would handle the cultural impact of GitHub’s changes. 

Every new security mandate, no matter how small, adds friction for people who are donating their time. GitHub’s rollout will likely cause some mild disruption in CI pipelines, but the real challenge is convincing maintainers — most of whom have no direct stake in npm’s risk profile — to spend their evenings updating workflows and rotating tokens.

Jeff Williams

What else is needed to protect against the next Shai-hulud?

Soroko said other measures that could further help bolster npm security include better support for private registries and mirrored staging that could help large organizations test policy changes safely. 

These steps, layered onto the current plan, would further raise the cost of account takeover and reduce time to containment when something like Shai-hulud appears again.

Jason Soroko

Wiliams said the real long-term focus needs be on what maintainers are publishing to repositories such as npm and how the packages behave, rather than on who is doing the publishing. “Trying to solve this problem by vetting developers is a fool’s errand,” he said.

The effort should be to find better ways of detecting malicious code and keeping it out of repos in the first place. It is a task that can be enormously challenging, Williams said.

Right now, from the developer perspective, there’s no difference between a highly professional, commercially supported open-source project and a weekend vibe-coded library that has a beautiful GitHub README.md and absolutely zero security effort.

Jeff Williams

Learn how Spectra Assure provides a complete approach to software supply chain security.