Repositories offer up vulnerable libraries says report

A report by Aspect Security and Sonatype analysed 113 million downloads of 31 popular open source Java frameworks and security libraries and found that, of those downloads, 26% of them had a known vulnerability. The report says that this highlights the fact that organisations don't have good procedures or tools for ensuring that the libraries they use when building applications are up to date. The study looked at 31 libraries which had 1,261 different versions of themselves held in the "Central Repository", a service for Apache Maven users run by Sonatype.

The 31 libraries included Spring, Apache CXF, Hibernate, Java Servlet, Log4J, Apache Velocity, Spring Security, Apache Axis, Bouncy Castle, Struts 1.x, Apache Commons, Tiles and Google Web Toolkit (GWT). The report counted the number of times vulnerable versions, such as versions of Struts with a remote code execution vulnerability, versions of Spring with a 2011 expression language vulnerability or Apache CXF with an authentication bypass, were downloaded from the repository over the past 12 months. According to the researchers, 37% of all libraries in the repository contain known vulnerabilities, but only 26% of the examined downloads are of libraries with known vulnerabilities.

The most downloaded vulnerable library was GWT; only a minority of downloads contained no known vulnerabilities. This is due in part, though, to there being many vulnerable versions being released during 2011. The GWT figures skew the numbers considerably; of libraries released in 2011, there were 45 million downloads and 35% of them were vulnerable, but remove GWT and that drops to 30 million and 5% vulnerable.

The H asked if the granularity of the study might have had some impact on the numbers and asked Sonatype CEO Wayne Jackson to look into it. For example, we wondered if a 12 month granularity with a regularly released library with security fixes in every month could make it appear to be being downloaded with vulnerabilities for most of the year. Jackson told The H that he "confirmed with the research team that only components with known vulnerabilities were counted. In other words, they did not count downloads prior to the discovery of vulnerability".

Part of the issue is that many developers are unaware that a library has been updated to fix vulnerabilities, or they have configured their projects to use particular versions of libraries and not put in procedures to check if "fixed" libraries don't become vulnerable at a later date. "The real staggering finding in the report is that people continue to use known vulnerable components well after the vulnerability has been disclosed and fixed," Jackson noted.

The problem though is a clash of philosophies; the "Maven way" is, said Jackson, not to break any build and removing known vulnerable libraries from the repository would break builds, sometimes unnecessarily as the vulnerable functionality in a library may not be used or exposed by an application. But by ensuring a build never breaks, the door is left open for vulnerable libraries to be used again and again, long after the originating project had retired them.

The H asked it was maybe possible to mark a library so that build tools emit a warning when they download a library has been replaced with a newer, less vulnerable version, but Jackson pointed out that it would require the repository manager to invest the time and resources in parsing vulnerability reports and marking libraries though the functionality could be added to tools like Maven if someone wanted to implement it.

Sonatype's solution to this problem is part of their Nexus Professional 2.0 product, a repository manager which includes a Repository Health Check which checks for known vulnerabilities in open source libraries within Maven repositories. The company has also released Sonatype Insight which focuses on analysis of projects from a license, quality, security or management point of view.

(djwm)