Package Maintainers Call for Improvements to GitHub’s New npm Security Plan

GitHub is moving quickly to tighten npm security in the wake of the Shai-Hulud worm, and it’s drawing on active feedback from package maintainers. After publishing a roadmap that introduces stricter authentication, short-lived granular tokens, and expanded trusted publishing, the company opened a dedicated feedback thread to gather input from the community. Within days, GitHub followed up with concrete changes to the rollout, adding timelines, token expiry limits, and phased enforcement details in direct response to that discussion.

New requirements target tokens and 2FA#

GitHub detailed sweeping publishing changes in its roadmap, setting out some of the biggest shifts npm maintainers have faced in years. Classic tokens will be permanently revoked. TOTP-based two-factor authentication is being phased out in favor of phishing-resistant WebAuthn. All new releases will require either trusted publishing or 2FA-enforced local publishing. And granular tokens will soon expire in days or weeks rather than months or years.

These measures are being rolled out gradually through mid-November to minimize disruption. But even before the first phase began, GitHub asked for feedback to shape the implementation.

Maintainers welcome stronger defaults but highlight gaps#

Many participants in the discussion welcome tighter security requirements. Electron maintainer Samuel Attard put it simply: “Deprecate legacy classic tokens… ✅. This is good, get rid of them.” He also backed the move to phishing-resistant 2FA, despite the major effort that it will require from maintainers with dozens of packages.

"To be clear, this is going to be quite annoying for so many people," Attard said. "Not in the least me, Electron publishes ~50+ packages all using TOTP codes (securely sent via http://github.com/continuousauth to github actions) that all need to be migrated to trusted publishing. But this is work we were going to do anyway because we'd already made our own conclusions about trusted publishing being the more secure future."

Others agreed with the direction while flagging missing pieces. Wesley Todd commented that the changes “disallowing non-2FA local setups and setting better defaults” were encouraging, but argued the roadmap “is still missing the workflow for 2FA in CI.”

CI/CD publishing concerns have emerged as a major sticking point. Todd contends the plan “seems to limit CI publish to only trusted publishing (unless you want to deal with the toil of manually minting a token every week),” while still failing to provide native 2FA workflows for CI.

"So while it is moving in the right direction, my first optimistic read was anchored on the defaults and missed the whole bit that they are not actually addressing the ask for native 2FA workflows and even making one secure (albeit complicated to setup) workflow even harder since they don't have a proper API for minting tokens," Todd said.

"I think mainly these changes are good, they are just not complete. Adding first party support for the CI workflows to require 2fa as well is the main missing piece for me."

Enterprise workflows missing from Trusted Publishing#

Today, npm’s Trusted Publishing only supports GitHub Actions and GitLab CI/CD. Self-hosted runners, including those used with GitHub Enterprise Server (GHES), are not yet supported, and GitHub has only said additional providers like Azure Pipelines and CircleCI are on the roadmap.

Maintainers warned that this gap could create breaking changes for enterprise setups. Without OIDC support for GHES or other common CI systems like Jenkins, Buildkite, or CircleCI, organizations may be left without a workable replacement once classic tokens are revoked.

Debate around shorter token lifetimes leads to clarifications#

GitHub’s plan to shorten token expirations drew skepticism. Jordan Harband questioned whether any real-world incidents would have been prevented, noting most compromises involve rogue maintainers or freshly exfiltrated tokens. Even those open to expiry changes want smoother regeneration.

Eric Cornelissen warned that without easier workflows, developers might default to overly broad tokens.

"If you're going to force people to generate new tokens by forcing (short) expiry windows, at least make it easy for them to regenerate tokens using the previous configuration," Cornelissen said. "As someone who has been using short-ish expiry windows already, this has been by far my biggest frustration with it - this feature has been long overdue...

"If a token of mine expires, I probably need one with the same granularity to replace it, so give me that option. If not, I think many developers will just generate overly permissive tokens because it's easier than specifying one package per token."

Trusted publishing wins support, with conditions#

Trusted Publishing was widely recognized as the most promising piece of GitHub’s plan, but maintainers cautioned that it needs stronger safeguards and broader support before it can cover all workflows. Attard contends that it should be a one-way switch.

"Once you opt in to Trusted Publishing and publish your first release with it, that should be a one way choice only changeable in extreme cases with intervention from npm support," he said. "Currently just having access to a maintainers' npm account effectively let's you perform a 'downgrade' attack on them by removing trusted publishing and/or changing publishing settings. Once a package is published the Super Safe way, it should only ever be publishable that way."

Several maintainers confirmed they were already making the move. At Socket, we’ve migrated projects like socket-cli, socket-registry, swf, and socket-sdk-js to trusted publishing, with more underway. The shift requires work, but the benefits of eliminating long-lived tokens outweigh the costs.

GitHub adjusts rollout in response to feedback#

GitHub didn’t wait long to act on the feedback they were hearing. Just days after the discussion opened, the company published a follow-up post with the first enforcement steps. Granular tokens now expire by default in seven days, with a maximum of 90. Classic tokens will be revoked by mid-November, with generation permanently disabled. And new TOTP 2FA setups are blocked in favor of WebAuthn passkeys.

The changes are already surfacing in npm CLI warnings, with enforcement staged through the fall. GitHub acknowledged that token rotation adds toil for automation and reiterated that trusted publishing is the long-term path forward, with expanded provider support on the roadmap.

For maintainers, the message is clear: npm publishing workflows are about to change, and the transition may be bumpy. But the rapid back-and-forth between community feedback and GitHub’s rollout shows a new level of responsiveness.

GitHub’s roadmap has strong backing, especially the shift to phishing-resistant 2FA and trusted publishing. The challenge now is execution: filling gaps in enterprise support, smoothing CI/CD workflows, and ensuring that security improvements don’t come at the cost of developer usability. So far it appears the community is actively shaping how the changes land.