Mend Research: Fixing Vulnerable npm Packages Quickly and Painlessly
Over the past few years organizations have been shifting security tools and practices left to ensure that application security is addressed from the earliest stages of the software development life cycle (SDLC). These efforts also increasingly cover open source components, which comprise up to 80% of our software products.
As AppSec practices continue to shift left into development, the task of ensuring that open source libraries are up-to-date and vulnerability-free falls on developers’ shoulders — and it is quite a task.
The Challenge: Keeping Open Source Components Secure
Open source libraries are composed of a deep web of direct and transitive dependencies. Many development and security teams struggle to update open source libraries as soon as a security vulnerability is detected — without breaking the build or slowing down development.
In addition to the task of tracking all open source dependencies in the code base, staying on top of newly disclosed security vulnerabilities and fixing them quickly by updating to a secure version can also be a complicated task.
Package Updates and the Risk of a Broken Build
With the fast pace of today’s release cycles, fear of dealing with a broken build prevents developers from updating to a secure version. The result is outdated and insecure software that might eventually cost a company much more than a delayed release.
Mend Research: Vulnerable npm Packages
In order to gain a better understanding of the process of tracking and managing open source version updates, our research team went to the Mend open source vulnerabilities database, which covers over 270M open source components and 13 billion files. We decided to take a deep dive into npm — as it is one of the most popular platforms in the open source dev community, and can give us a good understanding of open source vulnerability management.
Mend Insights: Fixing npm Vulnerabilities
We analyzed the npm vulnerabilities published in 2021, checking the CVE publication date and comparing it to the release date of the vulnerabilities’ fix, in cases where a fixed version is available.
We discovered that over 90% of vulnerabilities in npm packages are fixed before the vulnerability is published on the NVD. That means that with the right tools and processes in place, developers can potentially install a fix before a security vulnerability is publicized, which ideally means before any black hat hackers are aware of it.
Fixing a security vulnerability by installing a fix before it is even publicly acknowledged is the best way to ensure that the attack window is never opened in the first place. In cases when a vulnerability is known to attackers but not yet publicly disclosed, the attack window is even larger than previously expected, and requires a swift and effective fix.
We also looked at the distribution of the fix date vs. the date the new CVE was published.
Over half of the vulnerabilities have a fix available up to a month before the vulnerability was published on the NVD, and 85% of vulnerabilities are fixed a day or more before the issue is published. Some are even fixed a year or more before the issue is published.
We also found that most of the vulnerable packages could have been addressed well before the issue was published on the NVD.
Our data shows that a total of 83% of the CVEs that were most prevalent in projects could be fixed before the publication of the CVE, when they become common knowledge to all users, and become a risk.
Updating Vulnerable npm Packages with Confidence
Data regarding fix dates vs. CVE publication dates shows that in most cases developers can fix security vulnerabilities even before they are published on the NVD. The problem is that manual tracking of CVE’s or released fixes of vulnerable open source components is virtually impossible.
Mend Renovate helps developers integrate automated fix pull requests in the development environment, to ensure that fixes are implemented as soon as they are released.
Understandably, developers are often hesitant to push these security fixes, because of the risk that they will break the build. Mend Merge Confidence helps to overcome developer hesitance and enables fixes to be accepted and deployed faster.
Merge Confidence: Leveraging Crowd Data for Quicker Remediation
Mend Merge Confidence gathers dynamic crowd data about new releases and gauges the likelihood that a new release is “accidentally” breaking or backward-incompatible.
Leveraging anonymized and aggregated data gathered from hundreds of thousands of repositories using Mend’s GitHub app, developers can quickly assess the likelihood that a new release might cause them problems. For example, if a new release is a week old, passed 99% of everyone’s tests, and already has 20% adoption, the chances that there’s a newly introduced bug that nobody else has detected yet is extremely low, and the remaining users can feel confident to upgrade.
This confidence makes the difference, allowing developers to approve security fixes without hesitation and close the attack window where projects may be exposed to attackers.
