The open-source library security flaw problem

John Leonard
clock
The open-source library security flaw problem

'If you pick any random PHP library it more than likely has a flaw,' says Veracode's Chris Eng

Open-source code is more secure because with a thousand eyes on the code "all bugs are shallow", right? Wrong, says Chris Eng, chief research officer at security firm Veracode.

"This was a myth since day one," he said. "The problem is you don't have the right eyes."

Of all the eyeballs that pass over the code only a few have the required expertise to spot vulnerabilities. "You might as well have a room of English speakers reviewing a Russian manuscript," said Eng.

Which is not to say that proprietary software is necessarily more secure, just that the oft-quoted dictum can lead to complacency.

Open source has become hugely successful because of the culture of reuse. Why write something if you can take it off the shelf for free?

Which is great so long as the libraries - packages of functions and resources for performing a particular task - are secure, but unfortunately this cannot be taken for granted. Recent research by Veracode has found that libraries used by some languages, and the way those libraries are used, make them more vulnerable to attack.

The company scanned the components of 85,000 open source applications which included more than 351,000 unique external libraries and found that applications written in three languages popular with web development - JavaScript, Ruby and PHP - have particularly high rates of library usage.

veracode
Apps may have hundreds of dependencies. Source: Veracode

Some of these libraries are present in the vast majority of applications. More than 85 percent of JavaScript programs use the lodash library, for example, and the average JavaScript program incorporates hundreds of external libraries.

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

Dependencies of dependencies

And it's not just the number of libraries. Many of the commonly used libraries are transitive, meaning they are dependencies of dependencies, making managing those vulnerabilities more complex. The languages found to have the largest number of transitive dependencies were JavaScript, Ruby, PHP and Java.

veracode
Transitive libraries. Source: Veracode

PHP is of particular concern. As a ‘language of the web', PHP libraries are also a popular way in for hackers, particularly those exploiting cross-site scripting (XSS), access control and authentication flaws.

"Chances are, if you pick any random PHP library, it more than likely has a flaw," Eng said. "It's such a common application for server-side web applications, so it's frequently exposed to a large threat community."

While PHP may not be adding new libraries at the rate of say JavaScript or Python (in which a flawed library is included with roughly every 10 libraries used in applications), the issue is that existing vulnerabilities are not patched fast enough, Eng said.

"Historically, we've found that PHP applications carry the most security debt of any language, so even though they aren't changing rapidly, flaws are very slow to be fixed."

But it's not just users of languages commonly used in web applications that need to take care. The study found that while applications written in Swift and Go use far fewer libraries, those libraries each tend to have multiple flaws. Unfortunately, PHP exhibits the worst of both worlds - a large number of libraries and a high density of vulnerabilities per library.

Of all the ten languages and frameworks studied, .Net came out the best for the lowest number of transitive dependencies and flaws overall.

Eyeballs aren't enough

Fortunately, most of the vulnerabilities found are minor and can be fixed with a simple upgrade, but this is easier said than done in applications that include several thousand libraries.

And while they are fewer in number, there are dozens of serious XSS and authentication errors in open source libraries that are open for exploitation, and new techniques for attacking them are emerging all the time.

Because the dynamics are always changing, and as transitive libraries are often included automatically by default, developer teams should keep abreast of the particular issues with their chosen languages, stay on top of the latest security alerts and make sure they apply updates and patches promptly, Eng said.

"Developers need to keep in mind that just because a library is ‘safe' at a certain point in time, attacks are always evolving, and new vulnerabilities may be discovered in the future; this is why continuous scanning of your open source components is crucial.

"Relying on humans to spot every security bug just doesn't scale with the pace of modern development, whether open source or closed source. You need a robust software development lifecycle (SDLC) with integrated tooling. Humans can augment that, but they shouldn't be the only line of defence."

More on Cloud and Infrastructure

G-Core Labs expands North American presence with a new cloud point of presence in Chicago

G-Core Labs expands North American presence with a new cloud point of presence in Chicago

The new cloud location offers customers in the region both virtual machines and high-performance bare metal servers, integrated with security options including Intel SGX technology, Denial of Service protection and Web Application Firewall.

clock 29 April 2022 • 3 min read
Industry Voice: Interview: New Look CTO Ed Alford talks endpoint manageability

Industry Voice: Interview: New Look CTO Ed Alford talks endpoint manageability

As users and their devices become increasingly dispersed, remote endpoint management is an increasingly crucial part of organisational infrastructure. IT decision-makers have more responsibility than ever to ensure their organisation's toolset allows...

Intel
clock 13 April 2022 • 2 min read
About 400 customers have been affected by the outage, which has impacted many Jira services

Atlassian outage could take another two weeks to fully resolve

It could take as much as two weeks to fully restore all of the services that were accidentally deactivated during recent script maintenance, Atlassian has said.

clock 12 April 2022 • 1 min read