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.
Dependencies of dependencies
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."
"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."
Enterprise adoption of open source software has rocketed thanks to a confluence of favourable factors, argues EDB CTO Marc Linster
The new coalition aims for a unified, comprehensive, public-private campaign against ransomware groups
Cybersecurity suffers from a PR issue, and the government's attempts to raise its profile reveals only the startling lack of diversity in the industry
The Spark #1 - 'If you're not obsessed with this being a success, you shouldn't do it because it'll be a nightmare most of the time'
Stuart Sumner speaks to Tony Pepper, co-founder and CEO of human layer security firms Egress, discussing his organisation's journey, and what he wishes he'd done differently
Why it's a bad idea to reveal too much on social media (part 94)