Buggy open source components still dog dev teams
The best code in the world can still pose a risk if it relies on vulnerable libraries and frameworksPrint
21 April 2017 | 0
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 is not getting any better.
Modern software development relies on cobbling together custom code with multiple open source components, but organisations 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% 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 do not care if the issue is in the infrastructure or a library: a way in is a way in.
Attackers target components
Since most organisations do not realise the commercial applications they rely on contain any open source code, they do not prioritise 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 organisations did not realise the commercial networking applications they used had OpenSSL under the hood. If the developer does not address the flaw and release an updated version, the organisation remains unaware of the issue or the potential risk.
This way, attackers do not 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% 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 are not 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.
More popular than others
Black Duck’s analysis found vulnerable Apache Commons Collections in 11.8% of applications it tested. Apache Tomcat was found in 10.1% 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% 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 is 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.
IDG News Service