The open-source library security flaw problem

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.

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.

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