We just published our seventh State of Software Security (SoSS) report. Based on the goldmine of data we have accumulated over the past 18 months and 300,000 security assessments, this SoSS report is intended to give security practitioners a clear picture of application security trends and how their initiatives compare to their peers’.
New in this version of the report is a deep-dive look at the increasing use of open source components, and how that use affects organizations’ risk postures. In particular, SoSS v7 took a close look at component usage by Java developers.
Open source components are prevalent
The reliance on software for economic success has turned even the most traditional of companies into software companies, pouring investments into software development. But most companies can’t keep up with the pace of innovation all on their own. In many situations, it makes more sense to purchase applications or augment development teams’ efforts by integrating open source components into the applications. In fact, applications today have an average of 46 unique components.
Open source components are introducing risk
We have historically found open-source components to be overwhelmingly insecure. In a recent analysis of more than 5,300 enterprise applications uploaded to our platform over a two-month period, we found that components introduce an average of 24 known vulnerabilities into each web application.
This year’s report generated similarly dire results: It found that 97 percent of all Java applications assessed had at least one component with a known vulnerability.
Despite the risk components introduce, they are still best practice for any company attempting to rapidly produce and deploy new applications or updates. Component use isn’t the problem; lack of visibility into component use is the problem.
Do you know if you’re using a vulnerable component?
This new research puts hard data behind the reason so many organizations struggle to keep their components free of vulnerabilities: a large number simply don’t know they are using a vulnerable component.
For example, after ranking all the component vulnerabilities by prevalence, we found that the second most prevalent component vulnerability was released in January 2008, and patched in 2010. It’s the second most common vulnerability, and it was patched six years ago. It’s clear to see now why the chaos that ensued after Heartbleed could happen – a significant number of organizations don’t even realize that they are using a very risky component.
Unless your company has a dynamic inventory of components used by developers, you will be unable to remediate or mitigate the risk when a vulnerability in an open source component is disclosed.
Failing to upgrade components increases risk over time
Not updating components is a significant problem, and it becomes a bigger problem as time passes. Looking at one particular struts library, we found that while a decent proportion of apps use a relatively safe version of the application, many more are still using moderately or very risky old versions of the library.
And falling behind on upgrades happens quickly. The most recent versions of this particular library had zero known vulnerabilities at the time the data was pulled; all of the versions have vulnerabilities now.
Security teams need to encourage and facilitate application developers in paying attention to the composition of their applications and keeping open-source libraries up to date.
One vulnerability in one component can wreak serious havoc
Finally, we took a closer look at how far-reaching the effects of a vulnerability in a component can be. In particular, we followed the path of the most common component with critical vulnerabilities, commons-collections-3.2.1jar.
In November 2015, researchers revealed that a vulnerability in Apache Commons Collections could indeed be exploited, and could give attackers significant access. The Apache Commons project issued patches for the vulnerability, which affected all versions of Commons Collections 3.x up to and including v. 3.2.1 and v4.0. The patches, v3.2.2 and 4.1, eliminated the vulnerability.
How prevalent was Apache Commons Collections v. 3.2.1? It was the single most prevalent vulnerable component version across our entire data set of Java applications, found in 25 percent of all Java applications. In some industries the risk was even higher, with this version found in 67 percent of all Java applications in the technology industry vertical.
And that was just the version in which the vulnerability was first found; when looking at all vulnerable versions, 50.3 percent of all applications Veracode scanned contained a vulnerable version of the Apache Commons Collections library.
The problem goes even further. A Java library that uses Apache Commons Collections and does deserialization may also exhibit the vulnerability.
It was widely used in a variety of standard “infrastructure” applications—web servers, application servers, CI servers, etc. But it’s worth noting that the issue was not just in the infrastructure applications, but in any application that uses Apache Commons Collections v.3.0 - 3.2.1 or 4.0.
The lesson here is that the fall-out from one component vulnerability is more far-reaching than most would think. Addressing this vulnerability requires a broader response than just patching servers; it requires visibility into the component supply chain for all of your applications.
What’s your plan?
Get the details on our open source component findings in our State of Software Security report, version 7.
Is your experience in line with what we found in this report? Do you keep track of the open source software components your developers are using?