Five Critically Important Facts About npm Package Security

In 2021, the Mend Supply Chain Defender automated malware detection platform detected and reported more than 1,200 malicious npm packages that were responsible for stealing credentials and crypto, as well as for running botnets and collecting host information from machines on which they were installed.

As with all malicious npm packages that Mend identifies, those packages were immediately reported to the npm security team and subsequently removed from the registry as part of our ongoing effort to make the open-source software (OSS) community safer. 

As a result of doing this over the past year, our researchers have developed a list of five critically important facts that are vital to understanding npm package security:

1. There is a “trust by default” approach towards open source software that attackers exploit: Open source provides a great avenue into a company’s software supply chain because developers simply don’t have time to read every line of code from every package that’s in use. While projects usually start out with the latest versions, they typically fall behind, and when developers do upgrade to the latest version, they don’t have time to review all the changes, some of which might be malicious. 

2. Default behavior isn’t secure: By default, npm packages are supposed to include everything needed for their functionality. Unfortunately, many packages download additional resources upon installation. Such behavior may mean the developer doesn’t have a chance to review and analyze the content of all packages. And this creates an opportunity for such packages to be compromised because consistency checks aren’t being implemented.

3. Attackers research the best way to use npm for attacks: In many cases, attackers have only a specific time in which to work – between the moment they upload the malicious code and the moment it‘s reported by security researchers. To actually gauge how long this window of time is, a malicious actor may upload an intentionally broken package to measure the length of time before the package is removed. Armed with this knowledge, they can craft attacks to take advantage of this time window. Creating a successful attack can be extensive work for an attacker. Not only does the attacker need to ensure that his code will work, but he also needs to ensure that it affects as many systems as possible and reaches the machine he is ultimately interested in accessing.

4. Malicious npms don’t need to be run or be used: If a malicious npm is downloaded, it automatically is given permission to do whatever it wants.

5. Dependency hell is used to hide malicious activity: On average, npm packages depend on four other packages to do their dirty work. This is dependencies upon dependencies, which is often referred to as dependency hell. The more dependencies in a package, the higher the probability is that one of them will become rogue. When there are many packages with dependencies, it creates noise that is extremely difficult to filter. When that happens, an attacker can add an unexpected package dependency chain, thus compromising a dependency for a popular library – and these activities will go completely unnoticed.

To learn more about malicious npm packages identified by Mend.io, read the Open Source Risk Report >>