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.

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.