Software bugs are inevitable, but some issues are more about not vetting third-party libraries than actual coding mistakes. Many of the security vulnerabilities found in commercial software are the result of using at-risk versions of open source libraries and frameworks, and the problem isn't getting any better.
Modern software development relies on cobbling together custom code with multiple open source components, but organizations underestimate exactly how many libraries and frameworks they actually use, Black Duck Software said in its latest Open Source Security and Risk Analysis.
Of the 1,000-plus commercial applications audited by the company in 2016, 96 percent contained at least one open source component. A little more than one-third of the application's codebase is made up of open source code, with an average application using 147 unique components, according to the analysis.
"Components" is intentionally a broad term in this analysis, and it includes frameworks like Bootstrap and JUnit, scripting languages like PHP, libraries like jQuery and Apache Commons, and infrastructure technologies like the Linux kernel and Apache Tomcat. Including all these different elements makes sense because attackers don't care if the issue is in the infrastructure or a library: A way in is a way in.
Attackers target components
Since most organizations don't realize the commercial applications they rely on contain any open source code, they don't prioritize reports of bugs in open source projects. This is one of the reasons why it took so long for enterprises to grasp the magnitude of the Heartbleed vulnerability in OpenSSL: Many organizations didn't realize the commercial networking applications they used had OpenSSL under the hood. If the developer doesn't address the flaw and release an updated version, the organization remains unaware of the issue or the potential risk.
This way, attackers don't need to look for vulnerabilities in a specific application. Instead, they can go after all the applications that use a component like Bootstrap, Apache Commons, or OpenSSL. With Heartbleed, for example, attackers can put together a list of every commercial application using OpenSSL to find out which may be flawed. According to Black Duck's analysis, more than 15 percent of applications were vulnerable to Heartbleed.
About two-thirds of applications using open source components contained at least one risky component, and on average, applications had 27 vulnerabilities hidden in open source code. For the most part, these aren't zero-days or newly discovered issues—the bulk of the vulnerabilities are several years old, and updated components were available. More than half of these bugs were ranked as high severity, meaning they could be exploited remotely, did not require the attacker to authenticate to exploit, and could be triggered by a relatively unskilled adversary.
Some are more popular than others
Some open source components are more popular than others. Black Duck's analysis found the jQuery JavaScript library was the most widely used, included in 58 percent of tested applications. Front-end web framework Bootstrap was the second most popular, found in 35.8 percent of applications, followed by unit testing framework JUnit at 30.9 percent.
Black Duck's analysis found vulnerable Apache Commons Collections in 11.8 percent of applications it tested. Apache Tomcat was found in 10.1 percent of applications, but applications using vulnerable Tomcat versions on average had 11 high-risk vulnerabilities. Using a buggy version of OpenSSL meant introducing an average of 27 high-risk flaws to the application.
Popularity also varies by industry. For example, OpenSSL was the most common high-risk component in enterprise software, cybersecurity, manufacturing, and telecommunications, while Apache Tomcat was the most common among health applications, internet and software infrastructure, retail, and gaming.
Black Duck echoes the findings of Veracode's latest State of the Software Security report, which found that 97 percent of Java applications tested by the application security company contained at least one component with a known software vulnerability. At the time, Veracode highlighted the number of applications using buggy versions of Apache Commons Collections.
Know what you have
Development teams should maintain a full and accurate inventory of the open source components they use regularly so that they know which application is using which version. With that information on hand, when they receive information from public sources such as the National Vulnerability Database about publicly disclosed vulnerabilities, they know right away which applications are at risk.
Companies should also adopt an open source policy so that it's clear how components are selected. As more and more of software development gets automated, a formal policy will help make sure the components are used correctly and the inventory is regularly maintained. There are ways to integrate open source component checks to build tools so that the tests run whenever new code is committed.