Modern software development relies on open source libraries, even for those applications that are sold commercially and aren’t open source. However, developers may not always be aware how these components are introducing vulnerabilities into their code.
Seven in 10 applications use at least one open source library with a security flaw, which makes those applications vulnerable, Veracode said in its latest State of Software Security: Open Source Edition report. The report analyzed 351,000 unique open source libraries across Veracode’s platform database of 85,000 applications. A single flaw in one library can cascade to all applications using that component. The security debt becomes even higher when the vulnerable component is not called directly by the application, but by some other library.
“An application’s attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies,” said Chris Eng, Veracode’s chief research officer.
In most cases, the vulnerable libraries wind up in the applications indirectly, as 47 percent of the open source libraries with at least one vulnerability were “transitive” dependencies, Veracode said. Transitive dependencies refers to situations where a library relies on code from other libraries. A developer may explicitly include only one library, but if that library includes another, and that one also pulls in code from yet another library, the code the developer is writing winds up having three dependencies, not just one. As applications get more complex, the number of dependencies the developer has to manage grows pretty quickly.
"An application that picks up most of its dependencies via second, third, or even greater degrees of separation from a developer's explicit instruction increases the difficulty of managing those dependencies," the report said.
This is why it is harder for developers to stay on top of making sure they are using the most up-to-date versions of open source libraries. They can keep track of the ones they are using directly, but they often have to trust that the upstream library maintainers are managing the other dependencies.
"All of this imported code represents functionality that your developers did not author, but becomes code you have to manage," the report said.
Vulnerable And Outdated
Veracode’s findings echo the recent Open Source Security and Risk Analysis report from Synopsys which found that 99 percent of codebases contain at least some open source code and 75 percent used at least one vulnerable open source component. Synopsys found that 49 percent of codebases it analyzed had at least one component with a high-risk vulnerability. Synopsys audited 1,253 applications and assessed open source codebases from 20,000 sources for the OSSRA.
About 90 percent of applications used at least one open source component that was out-of-date by four or more years, or was abandoned, with at least two years of no development activity, Synopsys found. Out-of-date or abandoned components are even more likely to have unfixed security vulnerabilities.
The average application included 445 open source components, Synopsys found—which was far higher than the average number of components reported by Veracode. In an average application, 70 percent of the codebase was open source. Both reports agreed that applications are using a lot of open source components.
"The 2020 OSSRA report highlights how organizations continue to struggle to effectively track and manage their open source risk,” said Tim Mackey, principal security strategist of the Synopsys Cybersecurity Research Center. “Maintaining an accurate inventory of third-party software components, including open source dependencies, and keeping it up to date is a key starting point to address application risk on multiple levels.”
The OSSRA, like Veracode’s State of Software Security report, looked at both open source and commercial applications that incorporate open source components. Synopsys also found that some open source components were widely used. For example, 55 percent of applications analyzed by Synopsys used jQuery, 40 percent used Bootstrap, 31 percent used Font Awesome, and 30 percent used Lodash.
Veracode ran a similar analysis, and found that every language had a set of libraries that were used in over 75 percent of applications. For example, the x/net networking package for Go appeared in 52 percent of the applications, and the most popular JavaScript library, inherits, was used in 92.3 percent of the applications. The four-line isarray package is the seventh most popular JavaScript library and found in 86.2 percent of the applications. This isn't necessarily a bad thing, if the libraries themselves are safe to use. However, the second and third most popular JavaScript libraries, debug and ms, used in 89 percent of the applications, both have known denial-of-service vulnerabilities.
Packages "implementing trivial functionality [ms converts time into milliseconds] can have flaws, and may exist deep in a dependency tree," Veracode said.
Even if the developer knows to use the most recent version of the libraries, if any of the other libraries included in the application pull code from older versions of these two components, the denial of service issues becomes part of the application.
Language Differences
When it comes to vulnerabilities in components, all programming languages and frameworks are not created equal. More than 80 percent of applications written in JavaScript, PHP, and Ruby import more than two-third of their libraries through other libraries, while less than 10 percent of .NET, Swift, and Go applications rely on transitive dependencies, Veracode found. Whether or not the languages and frameworks are more likely to use transitive or direct dependencies has nothing to do with which language or framework is more secure, or “better.” Developers just need to keep in mind the characteristics of the framework or language they are using.
"JavaScript, Ruby, PHP, and Java have most of their attack surface from transitive inclusions that developers need to ensure they are managing," the report said.
Swift has the highest density of flaws, but has an overall low percentage of flawed libraries, Veracode found. Go, on the other hand, has a high percentage of libraries with flaws but has low density, meaning the individual library has an overall low number of flaws.
The typical PHP applications doesn’t import a lot of libraries, an average of 34 components, but a greater share of PHP libraries have at least one security vulnerability. PHP has more flawed libraries and a high density of flaws (but not as high as Swift), meaning the individual library also has a lot of flaws. Including any given PHP library has a greater than 50 percent of chance of introducing a security flaw into the code, Veracode found.
In contrast, a relatively low number of JavaScript components have some kind of vulnerability, possibly because so many JavaScript components are very short, with a few lines of code dedicated to doing one specific thing. This means, however, that a typical JavaScript application imports an average of 377 libraries, which increases the probability of including at least one vulnerable component somewhere along the way.
Types of Vulnerabilities
Veracode mapped the vulnerabilities in the open source libraries against the Top 10 list of software vulnerabilities maintained by the Open Web Application Security Project to determine if some types of vulnerabilities were more prevalent in open source components than others. Cross-Site Scripting (XSS), insecure deserialization, and broken access control vulnerabilities made up "a substantial portion" of the flaws in open source components. Veracode found that 29.1 percent of the libraries had at least one cross-site scripting flaw, 23.5 percent had insecure deserialization issues, and 20.3 percent had problems with broken access control.
The language differences were evident here, as well, as more than 40 percent of PHP libraries had cross-site scripting issues. PHP also had more broken access control and authentication problems than in any other language.
Insecure deserialization issues were common only in PHP and Java libraries, and broken access control flaws were bigger problems for .NET and Go libraries than XSS. While XSS issues were prevalent across all languages, they posed less of a problem than insecure deserialization and broken access control because most XSS issues were not exploitable.
Developers also can’t just look at CVEs (Common Vulnerabilities and Exposures) to keep track of vulnerable libraries because not all vulnerabilities get assigned CVEs. More than 60 percent of vulnerable JavaScript libraries have security flaws without corresponding CVEs.
Synopsys also had similar findings, noting that of the ten most common vulnerabilities it identified in open source components, four did not have a CVE assigned. The top three most common vulnerabilities were found in 37 percent of the applications analyzed. The fourth most common was the first one with a CVE (CVE-2019-11358), and is a vulnerability in jQuery.
Update Those Libraries
Most, or 74 percent, of the applications with vulnerable libraries can be fixed by just updating the libraries, Veracode said. In fact, 71 percent of the applications would even need a major update since a minor version update would fix the issues.
Most of the libraries with vulnerabilities from the Top 10 list also have updates available, as did 91 percent of flaws with public proof of concept exploits already have a fix available. Considering that attackers continue to target older vulnerabilities to attack systems, updating these components could significantly reduce the attack surface.
"Open source software gives companies tremendous advantages, but there's no free lunch here, and all code must be managed to avoid your own contributions — whether open or closed source in nature — from exposing your users to vulnerabilities," Veracode stated in the report.