Did your npm pipeline break today? Check your ‘classic’ tokens

GitHub has this week implemented the final part of a security upgrade it hopes will make the vast and hugely popular npm Node.js registry more resistant to the growing menace of supply chain compromise.

As it warned it would do two months ago, on December 9, the npm (Node Package Manager) registry finally revoked all ‘classic’ or ‘long-lived’ tokens, which until now could be used to authenticate developer packages without setting an expiration date. Developers must now shift to using either granular access tokens (GATs) with a shorter life and more limited scope, or upgrade to a completely new automated CI/CD publishing pipeline based on OpenID Connect (OIDC) and OAuth 2.0.

The move is a direct response to a recent rise in supply chain attacks, particularly September’s Shai-Hulud worm which successfully backdoored hundreds of packages after compromising developer accounts and tokens.

“Such breaches erode trust in the open source ecosystem and pose a direct threat to the integrity and security of the entire software supply chain,” said GitHub director of security research, Xavier René-Corail, at the time. “They also highlight why raising the bar on authentication and secure publishing practices is essential to strengthening the npm ecosystem against future attacks.”

Developer workload

For developers, the alteration raises two issues: what are the practical effects of the change, and will it boost security as much as claimed?

On the first point, the upgrade is significant: any CI/CD developer hitting npm publish or npm install for a package authenticated using a classic token will from this week on receive a ‘401 Unauthorized’ error. Generating new classic tokens without an expiration date will no longer be possible. Granular tokens with future expiration dates will continue to work until February 3, 2026. After that date, granular tokens will have a maximum lifespan of 90 days, at which point they will have to be rotated.

The amount of extra work all this creates for developers will depend on how many packages are involved and their organization’s size. For larger organizations, assuming they haven’t already done the legwork, this could involve auditing hundreds of packages across multiple teams. Classic tokens in these packages will have to be revoked, and a process will have to be put in place to rotate granular tokens.

Not everyone is convinced that the reform goes far enough, however. Last month, the OpenJS Foundation criticized the maturity of the tokenless OIDC security model that GitHub wants developers to move towards in the long term. Given that attackers often compromise packages after breaking into developer accounts, more emphasis should be put on multi-factor authentication (MFA) security for those accounts, the OpenJS Foundation said.

Currently, npm doesn’t mandate MFA on smaller developer accounts, and OIDC itself imposes no additional MFA stage when publishing packages. In fact, in the case of automated workflows, there is no way to add MFA to the process. And there’s also the issue that some forms of MFA are prone to man-in-the-middle attacks. This means that any authentication method used needs to be able to resist such techniques.

“We’ve seen a clear pattern emerge where threat actors target maintainers of widely used but under-resourced projects,” commented Mitun Zavery, regional vice president for supply chain security company Sonatype.

“The recent compromise of npm packages like Chalk and Debug mirrors what we observed with the XZ Utilities backdoor incident. In both cases, the adversary patiently built trust to gain control, showing that social engineering is now a key stage in supply chain compromise.”

He pointed out that the industry needs to recognize that open-source package management registries such as npm are critical infrastructure and should be resourced accordingly. Additionally, Zavery said, “organizations need to assume compromise is possible and respond by maintaining accurate software bills of materials, monitoring for suspicious dependency changes, and sandboxing builds.”