npm Packages Security Best Practices

Use of open-source software has drastically changed over the last few years.  As per the report by Github, more than 80% of the code in modern applications originates from the open-source software or dependencies. Not only this, 94% of active repositories which are written in JavaScript contain at least one open-source dependency which in turn are dependent on other dependencies. With these astonishing figures, it becomes evident to focus on securing open-source dependency management. Additionally, security auditing of open source is an important part of moving security to the left, and npm package security should be a top priority, as we can see from the fact that even the official npm CLI tool  has been found to be vulnerable. 

In this blog, we are going to talk about npm security best practices and the productivity tips for both open-source maintainers and developers. Let us get started! 

Impose The Use Of Lockfile 

As per npm official doc: 

“package lock or lockfile describes an exact, and more importantly reproducible node_modules tree. “ 

They help in deterministic installation of the dependencies across various environments. But sometimes you might commit the changes to package.json file but tend to forget updating the lockfile alongside it. In that case, when npm or Yarn detects a discrepancy between the project’s package.json and the lockfile, they tend to pull in dependencies as per the package.json file rather than those in lockfile. 

This sort of situation may be dangerous for build and production environments as they could install unwanted package versions making the whole point of lockfile ludicrous. To deal with such situation and abort the installation if there are any inconsistencies in specified set of dependencies and their versions by using following commands: 

• For Yarn, run yarn install –frozen-lockfile. 
• For npm, run npm ci. 

Always Make Use Of A Private Registry 

Npm public registry is the biggest source for installing packages. But sometimes it might not be very secure to pull the packages directly from the registry. Also, you might have different requirements in terms of deployments or performance. Luckily, npm enables you to change to a different registry.  

Private registry is a great way to securely pull and install all your npm packages. Additionally, it helps you keep track of the packages that are being used by your team and you can always configure to allow only approved packages. Private registry also helps in caching of packages helping in speeding up the development process. 

Also, having a private registry resolves the issue of keeping a track of various developer’s accounts and bad practices they follow with their authentication.    

Always Scan for Security Issues 

The npm team has made a good effort in improving the security of packages. The problem lies in the fact that frequently  there is a slight time lag between news of new threats and the time the teams become aware of the issue. The delay is even larger until such time as the security issues have been resolved by eliminating, upgrading, or patching packages or versions which have been affected. 

This is the reason why you need to make sure that all the packages AND their dependencies are constantly scanned for vulnerabilities. Also enabling automatic alerts for new security issues will be handy. 

Say No To Running Scripts When Installing Packages 

Scripts are often executed when you are installing packages. It is recommended that you analyse the scripts included in package content before execution. This will enable you to be on safer side if some malicious script is executed as part of an installation process.  

If you don’t have enough time to check the scripts, it is advised to use –ignore-scripts attribute for safe installation. 

npm install PACKAGE@VERSION –ignore-scripts 

Prevent Typosquatting Risks 

Merely installing directly from the official npm registry won’t save you from installing a malicious package. There have been several instances where bad actors have released packages with names that are confusingly identical to official packages. The aim is to take advantage of the community’s interest in common packages and replace it with malicious code. To delay detection for as long as possible, the infected shipments always act just like the actual ones. node-npm, for example, is a spoof of the actual package name node. Make sure you double check what you install. Do not automatically accept install instructions as a trusted truth.  

Review before you run! 

Prevent Publishing Secrets To The npm Registry 

If you use API keys, passwords, or other secrets, you should follow the guidelines outlined below to prevent sensitive data from being leaked.  

• Before publishing any package, run npm publish —dry-run to review the contents of the package tarball.  

• It is recommended that sensitive files be placed in .gitignore and that you update it as needed.  
• Alternatively, you could use package.json’s files attribute to whitelist files and folders which must be included in the package that’ll be built and installed. 

Evaluate npm Project Health 

Rushing to update dependencies to the most recent versions isn’t always a smart idea, particularly if you don’t read the release notes, look over the code updates, and carefully test new improvements. Staying out of date and not updating at all, or for a long period of time, is often a cause of trouble. The npm CLI will tell you whether the dependencies you’re using are up to date based on their semantic versioning offset. You will see which packages are out of date by running npm outdated. 

Make Use Of npm Author Tokens 

A token is created for your user any time you log in with the npm CLI, and it authenticates you to the npm registry. Tokens make it simple to execute npm registry-related activities such as accessing private modules on the registry or publishing new versions from a construct step during CI and automatic procedures. 

The npm registry website, as well as the npm command line client, can be used to handle tokens. The following is an example of how to use the CLI to generate a read-only token that is limited to a particular IPv4 address range: 

$ npm token create –read-only –cidr=192.0.2.0/16 

You can use npm token list or npm token revoke to see which tokens have been created for your user or to revoke tokens in an emergency. Protect and minimise the exposure of your npm tokens to ensure you’re implementing this npm security best practices. 

Concluding Thoughts

If you’re just a developer who is using npm in projects, it is best to create the cheat sheet and hang it somewhere near your working desk. It will help you in recalling some of the npm security best practises you should adopt.