Four Business Security Concerns (Still) Looming Over Open-Source Software

Increased adoption of open source software is changing the way companies do business, bringing transformational benefits such as increased innovation, cost savings and accelerated time to market.

And it’s not unexpected. Open source projects, as the building blocks of big data, cloud infrastructures and the Internet of Things, have laid the foundation for nearly all the applications we use today.

Linux, for instance, powers 500 of the world’s supercomputers and infrastructures, including the New York Stock Exchange, the US Department of Defense, Japan’s bullet trains, air traffic control systems, control of nuclear reactors of submarines and ships – plus companies like Google, Cisco, Facebook, Twitter, Linked in, Toyota and many more.

In 2016, 65 percent of companies said to be contributing to open source projects, according to the Future of Open Source 2016 survey.

Governments are also considering moving to non-proprietary software. Russia is drafting a bill to restrict government agencies from buying licensed software, out of “security concerns.” In this case, security concerns translate to potential backdoors embedded in US-made software to facilitate cyber-espionage.

But this approach sparked serious security concerns when, in 2014, vulnerabilities were discovered in three innocuous, widely used open-source protocols: Heartbleed, Shellshock and POODLE. Heartbleed, a flaw in the OpenSSL cryptographic software library, exposed over 66% of active websites to interception of private communications. Shellshock enabled a hacker to take control of the module used to type text-based commands on Linux, Unix and Mac servers, while POODLE opened a path to hijack accounts from visitors using secured banking and shopping webpages.

Here are the biggest concerns to consider when implementing open source components in your business software portfolio:

1. Malware

Looking at the collaborative nature of open source, companies fear someone will plant malicious code in a program they plan on adopting. Indeed, there have been instances of malware built on code posted online. However, “given enough eyeballs, all bugs are shallow," as Linus Torvalds said.

How prevalent are vulnerabilities in open source software?

Opposing the idea of “security through obscurity”, the open source model proves that apps with flaws hidden from public view (as typically happens with ‘closed’ software) shouldn’t be misinterpreted as being more secure. That’s not saying that open source is inherently secure, but its flaws are usually scrutinized and fixed in a reasonably fast timeframe since being discovered, by a worldwide community of developers and testers.

And an increasingly significant number of organizations are relying on this.

“There are people out there running open source web frameworks on open source server frameworks, with open source SSL stacks on open source web servers, sitting in an open source container, running on an open source kernel in an open source hypervisor,” says Nicko van Someren, CTO at the Linux Foundation.

2. Resource scarcity

Critical libraries and applications sometimes are developed by understaffed groups of developers who lack the resources needed to properly maintain the code base. That’s why heavy reliance on code libraries can prove dangerous, as a single vulnerability in a popular library can affect hundreds of applications. Also, it’s worth considering that once a library containing vulnerabilities appears in a new application, it has all the privileges of that application.

That’s why testing the code before widespread deployment is mandatory.

3. Arbitrary reviewing procedures

If a bug allows hackers to exploit a vulnerability in clients’ computer systems, this will not only attract negative attention to the business, but also a potential breach-of-contract lawsuit. Yet companies don’t seem to take testing very seriously.

58% of companies are still reviewing code for open source content only under special circumstances, according to the same study.

Truth is, complex software such as OpenSSL cannot be completely tested in staging environments and in-house testing can only cover a limited number of situations. Most of the time, bugs and flaws in implementation show up in real-life scenarios, only after they have been implemented in production systems.  And companies realize that they are running a faulty version only after receiving an advisory from the vendor.

Another problem is that the open source community doesn’t have consistent means for publicizing what vulnerabilities have been found in modules of open source code or if patches have been posted.

4. Outdated management and security practices

Unfortunately, research shows many organizations lack processes for identifying and mitigating known vulnerabilities in open source code used in-house. And responsibility for keeping track of vulnerability disclosures on open-source components and ensuring deployment of patches in a timely manner falls on the organization.

On the other hand, some organizations set up code auditing departments to ensure the open-source apps or libraries they use internally are reliable and don’t break security guidelines. By reporting – and sometimes lending the original developers a hand – they do a service not only to themselves, but to the open source community as well.