Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

5/19/2020
04:10 PM
50%
50%

Unpatched Open Source Libraries Leave 71% of Apps Vulnerable

PHP and JavaScript developers need to pay close attention because different languages and frameworks have different rates of vulnerability, research finds.

The management of open source libraries poses a major challenge for secure development. That's because seven in 10 applications use at least one flawed open source library, inheriting vulnerabilities that could potentially be exploited, according to a new study of more than 81,000 applications.

The vulnerability of open source libraries varies across languages and frameworks, and developers should take into consideration the characteristics of the framework they are working with, according to application security firm Veracode, which published the analysis. PHP applications, for example, have a modest number of imported open source components — an average of 34 — but a larger share of vulnerable libraries. On the other hand, while JavaScript typically has a relatively low number of vulnerable libraries, the typical application has a massive number of imported libraries — 377 on average — resulting in a large number of vulnerabilities, Veracode found.

Developers need to not just focus on patching, but also on approaching application security in a way that is right for the frameworks with which they are working, says Chris Eng, chief research officer at Veracode.  

"Open source software has a surprising variety of flaws," he says. "The attack surface of many applications is much larger than developers may expect due to the fact that open source libraries have dependencies on other libraries. Developers must be aware of this and the fact that language selection makes a difference in terms of the size of the ecosystem and in the prevalence of flaws in those ecosystems."

The report underscores that a lack of patching continues to be the No. 1 problem for application-security programs. Fixes exist for more than 90% of the vulnerabilities that have a published proof-of-concept, according to Veracode's report. Fixing such issues is critical because attackers regularly use older vulnerabilities to attack systems and applications, the US Cybersecurity and Infrastructure Security Agency said in a recent advisory.

"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.

Overall, the research suggests that developers who know the security characteristics of the open source libraries supporting their particular language and framework will have a greater likelihood of producing secure code. 

For example, one attribute of open source libraries, known as transitive dependencies — where a library pulls in code from other libraries — can result in an application relying on code that a developer may not know about because they did not explicitly import the library. More than 80% of the applications written in JavaScript, PHP, and Ruby import more than two-thirds of their libraries through such transitive dependencies, according to Veracode. On the other end of the spectrum, less than 10% of applications written in Microsoft's .NET and Apple's Swift have transitive dependencies. Go, Java, and Python applications straddle the middle ground with a balanced mix.

The approach each language and its core developers take to libraries can also have an impact. 

PHP applications, for example, typically import a modest number of libraries but gain a significant attack surface area through this friend-of-a-friend method of importing components, which exposes vulnerabilities that might not otherwise be anticipated by developers. Combined with the finding that 27% of all PHP libraries have an exploitable flaw, the framework can be a source of hidden dangers for developers, says Veracode's Eng.

JavaScript applications, on the other hand, tend to import a large number of small libraries — one, for example, consists only of four lines of code — but relatively few libraries include a vulnerability. Because each application includes more than 300 libraries, however, the probability of including one of the vulnerable open source components is high, he says.

"More than any of the languages we've looked at, JavaScript encourages the creation and use of very, very, small libraries that do one task," Eng says. "With JavaScript, PHP, and Ruby, developers need to make sure they are managing transitive inclusions."

The most numerous vulnerability classes are not the ones that developers should necessarily spend the most time eradicating, according to Veracode. While 29% of all flaws are cross-site scripting vulnerabilities, only about 8% of flawed libraries have an exploitable version of the vulnerability. Two other classes of vulnerabilities from the OWASP Top 10 — insecure deserialization and broken access controls — are much more likely to be exploitable, with 30% of flawed libraries having an exploitable version of the vulnerability.

But the good news for developers is that a minor update or patch could fix more than 90% of vulnerabilities with published exploits, Eng says. 

"Open source software offers a lot of advantages, and it's only growing from here," he says. "My recommendation is that developers and their organizations increase their knowledge and ability to test for flaws in the libraries they are pulling into their applications. The fixes are usually minor and can have a big impact on reducing exposure."

Related Content:

 
Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...