What security issues were talked about in the npm ecosystem in 2020? Let’s review some key takeaways to carry with us into 2021.
We at Bytesafe want to raise awareness on topics of npm security and secure management of package dependencies. Knowing is half the battle...
Continued growth = vulnerabilities
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.
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 details? See our previous post on Typosquatting.
Security issues in popular libraries can have a huge impact
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.
Strategies for efficient and secure management of dependencies
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.
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.
--
Thanks for reading! Much appreciated!
Top comments (0)