GitHub, which owns the npm registry for JavaScript packages, says it is tightening security in response to recent attacks.
September has been a bad month for npm with phishing attacks on package maintainers and hundreds of packages infected by secret-stealing malware.
GitHub security lab lead Xavier René-Corail said that more than 500 compromised packages have been removed and others blocked from upload by security scanning.
René-Corail also described changes that he hopes will strengthen security. Many existing authentication methods will be removed “in the near future,” including legacy classic tokens and one-time passwords for two-factor authentication (2FA). Token lifetimes will also be shortened, with a switch to trusted publishing and 2FA-enforced local publishing by default.
The workflow for trusted publishing
Trusted publishing was first adopted by the PyPI package index and is designed for automated workflows. Using OpenID Connect, the package repository verifies that a package comes from a trusted source and issues a short-lived token, avoiding the risks of long-lived tokens that can be stolen. Currently npm trusted publishing only supports GitHub Actions and GitLab CI/CD (continuous integration and delivery) pipelines.
Other package repositories have also added support for trusted publishing, including RubyGems, crates.io for Rust, and NuGet for .NET – this last one introduced yesterday by Microsoft.
Once the changes are fully implemented, the publishing options for npm packages will be limited to local publishing with 2FA, granular tokens with a lifetime of seven days, and trusted publishing.
According to René-Corail, the team intended to allow gradual adoption of trusted publishing, but said that “attackers are not waiting.” However, the disruption that would be caused by breaking existing workflows means that the changes will be “rolled out gradually,” with the timing of enforcing the changes yet to be announced.
One of the issues is that not all developers will want to use GitHub Actions or GitLab CI/CD pipelines, and René-Corail said there are plans to expand eligible providers. The docs state that currently only cloud-hosted GitHub runners are supported for trusted publishing, but that support for self-hosted runners will be added in a future release. Each package can only have one trusted publisher configured at any one time.
Trusted publishing avoids long-lived tokens, but for some it is not enough. “As a maintainer of popular project (postcss) I have doubt about OIDC Trusted Publisher,” said Andrey Sitnik. “For me (I use 2FA to publish with hardware key like YubiKey) adding Trusted Publisher via CI increases risks. Any malware from postcss’s node_modules can make commit & tag and push it to GitHub.”
Another developer said that “OIDC isn’t a quick fix, it simply delegates authorization to another platform,” asking for further steps from GitHub such as to “make it possible to require more than one review and to make it harder to change those settings so that a single compromised account will have a harder time reverting changes.” ®