Subscribe

Securing open source

Open source is used more than ever - but isn't open source security an oxymoron?

Godfrey Kutumela
By Godfrey Kutumela, leader of the cyber crime and security division at IndigoCube.
Johannesburg, 23 Nov 2016

Open source software is on the up and up. More companies, software development houses and individual developers are making use of it. But, isn't the very concept of open source inimical to security? It could be argued both ways, but the reality is that if it is being used - and it is - then companies had better have a good understanding of the implications for their system, and how to secure it.

First of all, some basics of the open source world. It is important to understand the difference between free and open source software. Free software is software that can be used without paying a licence fee - think of Adobe Acrobat Reader or Winzip - whereas open source software allows users to access the source code itself.

Open source software is typically created by communities of developers, and the movement is one of the few remaining vestiges of the digital community's roots in non-commercialism and idealism. Developers shared code in order to learn from each other and take computing forward. As commercialisation took over the digital world, and particularly the Internet, the idea of open source began to mutate, and ways for the open source software movement to interact with the commercial software industry, to their mutual benefit, began to emerge.

Wisdom of the collective

Most of the serious open source software is now produced by loosely organised communities that issue their own licences, but with radically different conditions. Hadoop and Apache are two names users have probably heard of. Read more about open source or consult the indispensable Wikipedia, itself a kind of open source project.

The great strengths of the open source movement are that it taps into the skills and insight of a huge pool of developers, so the code is likely to be much better (and thus intrinsically more secure) than code developed by an in-house team. And because it's global, it can be developed and fixed using a follow-the-sun model.

Open source is used to write a complete software product - think companies like Red Hat, for example - or simply to produce a small component that can be used in a custom-developed piece of software or even in commercial software. Indeed, Gartner suggests by 2018, 70% of newly deployed applications will run on an open source database, and 50% of all commercial applications will switch to open source databases.

Hackers never sleep!

Open source is extremely powerful - after all, Internet protocol, on which the Internet runs, is open source software. It also promotes better integration.

Is it secure?

On the question of security, I must say the jury is still out. On the one hand, the great strength of open source is that its code is open to the scrutiny of all, which means it is better crafted from the get-go and vulnerabilities can be fixed quickly; on the other, that same openness is also its biggest downside - hackers can access and study the source code at their leisure to find vulnerabilities.

This is a complex question which I'm not necessarily qualified to discuss. But, on a practical level, what is clear is that even if a company is not an open source shop, it is likely that open source components are part of the corporate application landscape.

Here's how to get a handle on the security side of things:

Set an open source security policy that stipulates what open source components or software products will be used, and how the relevant developer communities are structured and run.

Identify and track open source components/software across the entire application landscape. If and when a vulnerability is later flagged, or a breach occurs, the company will want to know exactly where each open source component is located.

Put in place a proactive strategy for dealing with any vulnerabilities - and then monitor. If a particular open source vulnerability is identified in several months or years, what is the company going to do? This strategy must cover the company's actions if the vulnerability affects an open source component or an entire open source application. This strategy needs to be paired with ongoing monitoring of new vulnerabilities - hackers never sleep! There are many excellent third-party solutions for this.

Establish the company's terms of open source licence and monitor compliance. In many ways, open source licences are more complex than licences for commercial software because one has access to the source code. Check what the particular code can be used for, and what the company's obligations are in terms of payment and the sharing of code as the company's usage changes.

A final word of advice that does not just apply to the open source world: automate whatever can be automated. In this case, I am thinking particularly of the various tools that can be used to take an inventory of open source components. Check which ones are vulnerable and what licences are needed.

Share