Npm security issues to keep an eye on in 2021

Npm security issues to keep an eye on in 2021

2020 was a year many of us are happy to leave behind in the rear-view mirror, looking forward to a much improved 2021.

But, what security topics were talked about in the npm and the node.js ecosystem? What did we learn about security and threats that we can use to avoid large-scale security issues?

Let’s review some key takeaways to carry with us into 2021.

Continued growth in the use of open source dependencies …

The never-ending desire to speed up innovation in the software supply chain demands efficient reuse of code. Today, you would be hard-pressed to find a scenario where your data does not pass through at least one open source component.

The 10+ million JavaScript developer community introduced over 500,000 new component releases in 2020, with 1.3 million packages now available to developers in npm alone. With on average 90,000 npm packages downloaded annually per developer.

… and with that comes vulnerabilities

According to research from the University of Darmstadt published in August 2019 it revealed that a significant percentage (up to 40%) of all npm packages depend on code with at least one publicly known vulnerability.

Code may be vulnerable either because it contains vulnerabilities, or because it relies on dependencies that contain vulnerabilities. In modern software, 80% or more of most applications’ code comes from dependencies.

Highly popular packages directly or indirectly influence many other packages (often more than 100,000) and are thus potential targets for injecting malware.

Npm packages have been the target of many malicious packages, due to the fact that the code can be easily triggered during package installation (unless directly handled e.g. with --ignore-scripts).

Together with an ethos of “shared trust” within the open source community, bad actors can prey on developers that don’t consider that their dependencies could potentially contain malicious content (intentionally or not).

Teams need to be aware of malicious packages

A review of npm’s publicly available advisory databases easily identifies numerous package security issues created with malicious intent.

According to GitHub’s 2020 report into open source security, 17% of vulnerabilities were explicitly malicious (while triggering just 0.2% of security alerts). So although most software vulnerabilities are still mistakes, teams should be aware and guard against malicious packages.

Well-known and trusted packages could be targeted with a contaminated payload or new packages are created to intentionally introduce security issues, with the assistance of any user that accidentally download it. The goal is typically to steal information, cryptocurrency or hack applications.

Typosquatting is a major threat

Typosquatting (and the similar combosquatting) aims to get users to inadvertently install malicious packages by naming them in such a way that developers believe they are downloading an official package.

Attackers know that through human error, developers make typos or won’t invest time in checking code dependencies. The intent is getting their malicious packages pulled into your project (supply chain) and using that to get access to whatever system your project is finally deployed to.

Most malicious packages in the npm advisory database from 2020 are typosquatting atempts. Examples include the now removed twilio-npm package trying to piggy back on the popular package: twilio. More examples can be found in related articles here and here.

More information on Typosquatting can be found in our previous blog post on the subject.

Vulnerabilities were identified in packages like: Lodash. Although not malicious in its intent, the sheer popularity of the library makes the impact of the identified security issues that much larger.

Similarly, the previously identified issues with earlier versions of JQuery cause similar impact, where its widespread use makes it easy to detect use of vulnerable versions in many public websites still in 2021.

Strategy for keeping packages up-to-date

The security of an application depends not only its own code, but also on how secure the direct and indirect dependencies are. Therefore, it’s important to keep your packages up-to-date and be aware of vulnerabilities.

As the SolarWinds breach shows, it is as important as ever to be aware of and continuously work with the security of your software supply chain (and its dependencies) to not open up your organization for such attack vectors.

Related to this, dev teams in 2021 need to adopt a strategy for how to best keep their dependencies up to date. One that weighs automation vs security aspects. A strategy that keeps teams in control, where dependencies are updated with intention and not as a consequence or afterthought.

This may include work on topics like specifying dependencies with exact or range versions, automatic patching of dependencies and the general approach and mindset when adding new dependencies to a project.

So, what can Bytesafe offer to secure your code supply chain?

By integrating Bytesafe in your supply chain you create a secure proxy for ALL your dependencies. Both direct and indirect dependencies for your project will be managed and analyzed.

Bytesafe offers the Security Scanner plugin to scan and identify known vulnerabilities in packages. Identified security issues are displayed in Bytesafe and sent as notifications to integrated slack channels.

Bytesafe also allows for Security Policies to block security issues from entering your code supply chain.

Want to give Bytesafe a try? Go ahead and Sign up for Bytesafe.

Stay Updated!
We’ll keep you up to date on supply chain security and send you the latest information.