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

6/23/2021
07:00 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

79% of Third-Party Libraries in Apps Are Never Updated

A lack of contextual information and concerns over application disruption among contributing factors.

Software developers almost never update third-party libraries after including them in a codebase, even though in most cases the libraries can be relatively easily updated without disrupting application functionality, a new study shows.

One result is heightened risk for organizations, as well as increased complexity when it comes time to make a fix, according to Veracode, which recently analyzed the results of 13 million scans of some 86,0000 customer repositories containing more than 301,000 unique software libraries. The security vendor also surveyed about 2,000 developers to understand their use of third-party software.

Related Content:

The Ticking Time Bomb in Every Company's Code

Special Report: Building the SOC of the Future

New From The Edge: 7 Powerful Cybersecurity Skills the Energy Sector Needs Most

Its analysis shows that 79% of the time, developers don't update the third-party libraries they use in a codebase. Though third-party libraries are constantly changing — and what's secure and what's not secure keeps changing equally fast — developers by and large don't update them. Even in the case of more mature, actively maintained repositories, Veracode found that third-party libraries are added and never updated 73% of the time — compared with 79% for all repositories. Overall, 50% of libraries take longer than 21 months to update, and 25% are not updated for as long as four years — which was the time frame for the Veracode study.

Interestingly, when developers do update third-party libraries, they act surprisingly quickly. For example, of the vulnerabilities that do get fixed, 17% are fixed within one hour and 25% within one week.

That shows the failure to update third-party libraries — or the chronic slowness to do so — is not the result of a workflow problem, says Chris Eng, chief research officer at Veracode. More often it's the lack of contextual information about how a vulnerable library might impact the application, concern over potential application disruptions, and cultural issues.

Developers who report needing more contextual information take more than seven months, on average, just to fix 50% of their known flaws, Eng says. On the other hand, developers who felt they have the needed information take just three weeks to fix 50% of flaws. The lack of context could be something as simple as not understanding the severity or impact of a vulnerability, Eng says.

"For example, if a developer doesn't understand why SQL injection is dangerous, they might brush it off as unimportant," he notes. "Sometimes illustrating the code path connecting the first-party code to the third-party vulnerability can also help the developer understand how and why their application is vulnerable."

Additionally, developers often fear that updating a library to fix a vulnerability will end up breaking something else. Even though 69% of vulnerabilities in third-party libraries involve a minor patch that would rarely cause breakage, developers are often not aware of this fact.

Cultural Factors
Leadership and culture are factors as well.

"Developers work on what they are told to work on from product and engineering managers," Eng says. "Leadership needs to carve out the capacity to leave time to work on vulnerabilities and reduce security debt, just as time is set aside to work on scalability, resiliency, quality, and so on."

In fact, Veracode's analysis shows that while developers often consider functionality and licensing as important considerations, they often don't view security as being of the same importance when adding a new library. More than two-thirds (67%) of the respondents in the Veracode study said they always consider functionality, and 63% said they always look at licensing when evaluating a new library.

In contrast, a smaller percentage — 52% — said the same about security. When developers did make security a core criterion for evaluating libraries, Veracode found the percentage of repositories with vulnerabilities in third-party libraries was slightly smaller (80.7%) compared with 84.2% when developers don't always consider security when evaluating third-party libraries.

Numerous previous studies have shown that almost all modern enterprise applications have vulnerable third-party and open source code in them to varying degrees. A recent study by Synopsys showed that enterprise applications these days have as many as 528 open source components in them, on average. The company found an average of 158 vulnerabilities per code base — many of them critical.

So the consequences can be severe for organizations when third-party libraries in their applications are not kept up to date. For one thing, breach risks can get higher. Another issue is increased patching complexity.

"The longer we wait to fix a vulnerability in a third-party library, the more complicated it gets to fix, the more time it takes to do the patch, and the bigger the risk of breaking something that affects users," Eng says.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
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-2020-36239
PUBLISHED: 2021-07-29
Jira Data Center, Jira Core Data Center, Jira Software Data Center from version 6.3.0 before 8.5.16, from 8.6.0 before 8.13.8, from 8.14.0 before 8.17.0 and Jira Service Management Data Center from version 2.0.2 before 4.5.16, from version 4.6.0 before 4.13.8, and from version 4.14.0 before 4.17.0 e...
CVE-2021-37578
PUBLISHED: 2021-07-29
Apache jUDDI uses several classes related to Java's Remote Method Invocation (RMI) which (as an extension to UDDI) provides an alternate transport for accessing UDDI services. RMI uses the default Java serialization mechanism to pass parameters in RMI invocations. A remote attacker can send a malic...
CVE-2021-23416
PUBLISHED: 2021-07-28
This affects all versions of package curly-bracket-parser. When used as a template library, it does not properly sanitize the user input.
CVE-2021-23417
PUBLISHED: 2021-07-28
All versions of package deepmergefn are vulnerable to Prototype Pollution via deepMerge function.
CVE-2021-23415
PUBLISHED: 2021-07-28
This affects the package elFinder.AspNet before 1.1.1. The user-controlled file name is not properly sanitized before it is used to create a file system path.