GitHub Aims to Improve npm Security After Malware Campaigns

GitHub announced several imminent security changes to its authentication and publishing options on the heels of a recent surge in account takeovers and supply chain attacks impacting the npm ecosystem.

In the “near future,” the platform changes will include local publishing with required two-factor authentication, granular tokens that have a limited seven-day timeframe, and an authentication method called trusted publishing, which aims to reduce the need for long-lived tokens or credentials to be shared with external systems during the package repository authentication process. 

“These efforts, from GitHub and the broader software community, underscore our global commitment to fortifying the security of the software supply chain,” said Xavier René-Corail, senior director at GitHub Security Lab, in a Monday post. “The security of the ecosystem is a shared responsibility, and we’re grateful for the vigilance and collaboration of the open source community.”

Recent npm attacks

The new security measures come after an increase in supply-chain attacks within the open source ecosystem, particularly involving compromised npm packages. A phishing campaign in early September resulted in the compromise of the npm account of an open source contributor, which impacted several npm packages. The impact of this incident was limited: the maintainers deprecated the impacted packages after noticing the issue within hours, and even the amount of crypto in wallets associated with the campaigns was just a couple hundred dollars.

But then, in mid-September, a new, seemingly separate campaign appeared. This attack had the capabilities to automatically add malicious code not just to one package but any other packages it had access to, and to steal “multiple types of secrets.” Attackers used an automated script that downloaded secret-scanning tool TruffleHog in order to sniff out identity secrets before attempting to validate those secrets. Attackers created a public GitHub repository named Shai-Hulud with the stolen secrets, before pushing a GitHub Actions workflow to other accessed repositories in order to steal secrets from those repos. The campaign’s self-replicating capabilities had worrying potential downstream impacts for maintainers and end users. 

“This attack felt different to everyone,” said Dan Lorenc, co-founder and CEO of Chainguard. “These attacks have happened almost every week and have involved npm, RubyGems, or others, but this one didn’t target cryptocurrency. Instead, it stole infrastructure credentials, so people are taking it a lot more seriously.”

GitHub on Monday said it has removed more than 500 compromised packages from the npm registry to prevent further propagation of the malware, and is blocking the upload of new packages that contain known IoCs linked to the malware in an attempt to kneecap the self-replicating pattern.

Github security measures

René-Corail said that the worm could have enabled an endless stream of attacks if not for GitHub’s intervention. This has quickened some of the platform’s existing efforts to raise the bar on authentication and secure publishing practices.

For npm maintainers, the protections include 2FA for package publishing and settings modification. Specifically, GitHub will remove the option to bypass 2FA for local package publishing and deprecate time-based one-time password 2FA in favor of the more secure FIDO-based 2FA. 

Additionally, granular tokens with publishing permissions will be limited to a shorter expiration, and legacy classic tokens will be deprecated. GitHub will also set publishing access to disallow tokens by default as a way to encourage usage of trusted publishers. Trusted publishing is a security capability that removes the need to securely manage an API token in the build system. It has been recommended by the Open Source Security Foundation (OpenSSF) Securing Software Repositories Working Group and has been added to package repositories over the years like RubyGems, crates.io, npm, and NuGet.

When it comes to GitHub’s security mandates, “I think it’s about time,” said Lorenc. “They’ve had these features for a while - support for 2FA, trusted publishing - but the ecosystem has been hesitant to require them. There was a hope that these would grow organically, but that didn’t happen.”

GitHub isn’t alone – last week, Ruby Central announced changes to ensure that administrative access to RubyGems, Bundler, and RubyGems.org is securely managed.

New security measures and the open source community 

Overall, companies demanding security measures across the open source software community must contend with the unique model of the ecosystem. As part of this mode, maintainers work on a volunteer basis and have sounded off on challenges with burnout, lack of support, and work overload. Despite that, the services they maintain serve billions or even trillions of downloads each month. This systemic issue has been at the heart of several other security incidents, including the XZ Utils backdoor in 2024.

In a new letter published Tuesday, OpenSSF and several other organizations outlined some of these inherent problems within the open source ecosystem model that are exacerbating issues with supply chain security, as well as availability and scalability. 

“Regardless of the operating model, the pattern remains the same: a small number of organizations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users, including commercial entities that generate demand and extract economic value, consume these services without contributing to their sustainability,” according to the letter. 

GitHub, for its part, acknowledged that its security changes may require updates to the workflows of npm maintainers. The company said that it will gradually roll out its changes, and provide future updates with documentation, migration guides, and support channels in order to minimize disruption. 

“Overall, there is a general tension between open source maintainers who see themselves as doing free work, and companies that are the ones asking for demanding protections around the supply chain,” said Lorenc. “My argument is that this is a societal contract. If you’re doing something, why would you leave it insecure?”