Preventing the Next NPM Virus Outbreak☣

February 11, 2021 | 5 minute read

Doing npm install seems like second nature these days for developers. But did you know that without proper attention and auditing of npm packages, the next time we unknowingly do npm i you could also be installing malicious scripts?

Preventing the Next NPM Virus Outbreak☣

Doing npm install seems like second nature these days for developers. But did you know that without proper attention and auditing of npm packages, the next time we unknowingly do npm i you could also be installing malicious scripts?

Is NPM Virus Free?

We know that most of the npm packages we use are maintained by third party actors. This can be a single developer, a team of developers or a super large corporation.

NPM in itself is very reliable. But does NPM guarantee you that any package that you install will be virus free? Unfortunately not.

So these days, it is not uncommon to hear some developers foreseeing a day in which a successful virus attack will spread through millions of machines through NPM.

Sorry if I’m the first person to tell you: NPM it’s not virus free 🤦🏼‍♂️.

I won’t go into all technical details of how exploits are possible in NPM. Just know that NPM has disclosed publicly that it is possible for an apparently ‘normal’ npm package (or its dependencies) to execute malicious code in your machine and wreak havoc.

For any package can be compromised. You probably have ESLint installed right? Well, guess what? One of its dependencies was (not long ago) compromised and installed malicious code on users machines. The ESLint team and NPM acted quickly to solve the issue and their incident report can be seen here. But this is not the last time a virus incident happened. Now the NPM security team is publishing weekly reports of such incidents.

Preventing Exposure To Future NPM Virus Outbreaks

Exploits can be defined as scripts that take advantage of vulnerabilities in code to cause unintended or malicious behaviors to occur. An exploit was possibly the culprit of the ESLint incident. There are some actions we can take to safeguard our code to avoid become infected with any future malicious script incidents.

NPM Security Recommendations:

  1. Think twice before installing a new NPM package. Are you sure you really need it? Is it well maintained? Can you just code it yourself? Ask yourself this questions before adding a new dependency. The best way to safeguard yourself is simply having less packages. If you are part of a team you could also consult with your team before installing a new package. Even if you are just trying it. You might not wanna be one of those using a seemingly harmless package that is then reported to contain an exploit, as it happened in a recent report.
  2. Use npm audit manually. This command was released by NPM as a response to its vulnerability. Actually each time you do npm i, npm audit will also run automatically. The npm audit command will scan your packages for vulnerabilities. You can even fix vulnerabilities automatically by just doing npm audit fix. The efficacy of this command depends on how it is up to date to latest threats and reports, but it must be part of your coding arsenal. You should manually run this command to inspect and fix as needed. You can learn more about it on the documentation. Here’s also a good video that covers common cases when running this command.
  3. Github Alerts: If you use Github then just take advantage of Github through its Dependantbot alerts which comes with any repository for free. If you been ignoring those alerts, don’t. Read more about it on the Github documentation.
  4. Use third-party software. This is useful if you are part of larger team. There are plenty of development security of tools that scan your dependencies for vulnerabilities. Some options are Snyk and WhiteSource.
  5. Pay open source maintainers. You heard it right. A lot of NPM packages are open source. Maintainers have to pay their bills at the end, and support them could not only help them financially but also hold them ethically accountable.
  6. Report suspicious packages to NPM. Just like you hear at the airport. For NPM, if you see anything suspicious, report it to support@npmjs.com.
  7. Disable NPM scripts. You can prevent malicious scripts by opting-out of using scripts altogether by doing npm config set ignore-scripts true. This might be a deal breaker for some since it also disables custom scripts on package.json. You can also do this case-by-case when installing a package with npm install --ignore-scripts. There might be unintended consequences of your packages not installing correctly and common commands such as npm run or npm test breaking. Some people have done workarounds by having shell aliases such as nrun = npm run --ignore-scripts=false or ntest = npm test --ignore-scripts=false to allow some particular scripts to work. I cannot assure what other problems will you encounter. Try this last strategy at your own risk.

Conclusion

So when is the next doomsday NPM package virus that will affect millions of computers coming? Who knows. So while we might not be able to prevent the next outbreak, we as developers need to guard ourselves. 

We are always eager to get to coding and wanna get setup as fast as possible. But the next time you are about to npm install, ask yourself: Are there any security checks I should be performing before installing? There are always things we can do to audit our NPM packages.

By applying these NPM security recommendations our code becomes more secure and we can greatly decrease the risk of getting infected when the next outbreak happens ☣