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 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.
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.
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.
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.