The Frequency of Known Vulnerabilities in JavaScript Libraries

There’s an interesting whitepaper from last week’s NDSS Symposium that discusses a large-scale attempt at determining just how vulnerable client-side JavaScript libraries are.

The study involved analyzing JS code across over 133,000 different websites. They scanned for popular JavaScript libraries (they ended up looking at 72), determined the versions in use and then queried to find if there were any known vulnerabilities. The conclusions were interesting, to say the least.

It’s an excellent report, and we highly recommend taking a few minutes to read through it. There have been a couple of summaries already (Adrian’s is a particularly good one) and we wanted to share our perspective as well.

Known vulnerabilities are common

The researchers found that 37% of the sites surveyed included at least one library with a known vulnerability. That’s a number that has been making many uneasy in the discussion we’ve seen, but the reality is that it’s probably much higher.

The study looked at the 72 most popular libraries, which means there’s a long tail of less popular libraries that weren’t analyzed. The median project we monitor includes 184 dependencies—the long tail in JavaScript development is substantial. While each of these libraries is less frequently used, they do add up to very large numbers. These libraries living in the long-tail also tend to have fewer contributors. This means that if a vulnerability is discovered, an update with a fix could take quite some time to rollout.

The vulnerability list they looked at also certainly left some off. The researches couldn’t find a database of vulnerabilities they liked so they did their best to assemble one. They did a pretty good job too, but it does look like there are at least a few in our database that didn’t get included in their analysis. For example, while the moment library ended up on their list of popular libraries, they didn’t appear to discover the two known vulnerabilities many versions contain.

They also didn’t attempt to identify any new vulnerabilities, which is very understandable: uncovering new vulnerabilities takes a substantial amount of energy and effort (as I’m sure our research team will attest to). But new vulnerabilities are disclosed far more frequently than developers update libraries. In only ten days since the report was released, we’ve added seven new vulnerabilities found in npm libraries.

Put it all together, and you realize that if 37% sounded bad, the reality is certainly worse.

It’s also worth remembering that this 37% is client side only. We currently have around 400 known vulnerabilities for npm packages in our database, and they’re not all client-side. Expanding the study to the JavaScript ecosystem as a whole would be even more sobering.

Upgrading to new libraries is a slow process

The median site they analyzed used a library version that is 1,177 days (that’s over three years!) older than the latest release.

Slow adoption of new releases of software and libraries is not a new problem, nor is it isolated to the JavaScript ecosystem. Look at any operating system update, and you’ll see it takes a while for most folks to update — and those systems typically have the luxury of pushing update notifications directly to the machine.

JavaScript libraries have all the same sort of challenges as an operating system around security but without the luxury of being able to trigger updates directly and with more manual work involved.

Updating a library means effort and risk. It takes awhile to find out there’s an upgrade, pull it down, test and potentially make changes in the way you’re using the library. If the upgrade involves minor changes and does not substantially change functionality, the level of effort is a bit lower but so is the desire for many to upgrade.

Proper semver versioning can indicate the complexity of an upgrade, but there’s no real indication of the urgency of an update. As the paper discusses, vulnerability fixes are not always very clearly communicated in the release notes of a library. To get some understanding of the urgency of a release, you have to be monitoring your libraries for known vulnerabilities, and the vast majority of developers still don’t.

Remaining hopeful

The paper’s findings are a painful wake-up call. Generally speaking, our industry has been quick to take advantage of the wealth of resources that open-source development provides, but much slower to recognize and protect ourselves from the risks that can come along with it.

While the findings may be discouraging on the surface (the paper’s authors were certainly discouraged by what they saw), we’re optimistic. General awareness of the importance of security has been slowly increasing as of late. Stronger and smarter web standards have been developed to add in layers of security. And tooling is improving. It’s entirely possible to monitor your JavaScript applications for known issues in a developer-friendly way, and be alerted when important new updates occur.

We have a long way to go, it’s true, but securing JavaScript is a solvable problem.