NPM Release Security

Nazar Hussain
Dec 15 · 6 min read

Securing npm package releases — highlighting common threats and taking steps to mitigate them.

JavaScript is the most popular programming language in the world, and as such, it gets a lot of use in open source projects. This popularity has brought more attention from bad actors in the Javascript open-source ecosystem, and hence the ecosystem is more at risk simply by virtue of public access. Indeed, numerous open-source projects were exposed to hundreds of vulnerabilities in the last year alone.

Experiencing a vulnerability of one of your dependencies is one thing, but getting infected by a vulnerability intentionally in your javascript package releases is another. In the first scenario, there are many guidelines for choosing better dependencies⁠ — ones that have a more active user base, better test coverage, and, importantly, a quick release cycle.

In the second scenario, the fix is less straightforward. Yet, it’s essential to protect your code from bad actors who may infect or expose your work to different vulnerabilities. And to do that, you must understand the threats involved in releasing code through node package manager (npm) or other registries and then develop the steps to mitigate them.

NOTE: The threats and guidelines mentioned below are not restricted to the npm or JavaScript ecosystem. They’re equally important for other ecosystems as well.

Defending against common threats

Code obfuscation attack

  1. Make sure not to use any dependency with obfuscated code
  2. While reviewing the packages, audit the compiled and obfuscated code
  3. If needed, compile that dependency locally and see if it matches the same output

Git impersonation attack

  1. Make sure all release branches are locked
  2. Verify the authenticity of your organization’s git users carefully
  3. Enforce the rule that all users must sign commits with their GPG keys
  4. Never merge any PR which include any unsigned commits

Typosquatting attack

  1. While using dependencies, double and triple check the dependency’s name
  2. Verify the dependency info with the npm info
  3. Scan exiting public registry for the package names similar to your library
  4. Ask the community to report any package which they found confusing or with a similar name
  5. Setup a bot or service to monitor new package registration for the same purpose

Account takeover (ATO) attack

Once an ATO happens, the attacker releases a patch version with infected code, and since most of the JS ecosystem depends on auto-version updates, the infected package spreads quickly. In the past, we saw ua-parser-js, coa, and rc packages like this. It does not matter if you use npm or Github registry. Both can affect ATO. To mitigate this threat:

  1. Ensure that all users in Github use 2FA.
  2. Ensure that all users on npm use 2FA.

Guidelines

NPM Security

  1. Limit who has access to the npm registry
  2. When one user is not intended to publish, always create a “read-only” mode npm token.
  3. When one user is intended to publish, packages must assign a token to a particular IP. `npm token create — cidr=192.1.1.2

Audit and monitor vulnerabilities

  1. Keep updating your dependencies to get more stable and secure versions
  2. Use a vulnerability monitoring service like sync.io to keep an eye on all dependencies

Avoid publishing sensitive data on Github

  1. Create a special file or structure for sensitive data. E.g. a directory `.secrets/keys`. This will ensure everyone knows if they want to use some keys that can be put in this file.
  2. Add such files to ‘.gitignore’ to make sure these never become part of the SVC.
  3. While doing code reviews on Github, pay special attention to collapsed files. In Pull Request review mode, Github collapses very large files, and such files are often accidentally skipped during a review.

The above mitigation steps and guidelines are not a bulletproof plan to protect your npm package release but will at least protect you from commonly known factors. As a package release manager, you must always keep a vigilant eye on your package releases. Having a well-defined security and vulnerability reporting mechanism for the community can also be a good addition. We wish you all safe releases!

Disclaimer: The suggestions above cover some of the fundamentals and are not fit for every project or situation.

About ChainSafe

Want to help build the foundations of Web3? Join us!

Have a question, comment, or suggestion? Drop into our Discord and join the conversion! We’re also always looking for talented people. Check out our open positions and get in touch ➡️➡️ careers@chainsafe.io

Website |Youtube |Medium |Twitter |Linkedin |GitHub

Acknowledgments

Special thanks to M. Junaid Taj and Colin Adams for their help writing this article.

ChainSafe

building the infrastructure for web 3.0

ChainSafe

building the infrastructure for web 3.0

Nazar Hussain

Written by

Experienced programmer, technical designer and technology enthuasist. Currently working on Lisk, a blockchain application platform. Web: basicdrift.com

ChainSafe

building the infrastructure for web 3.0