The Impact Of Heartbleed On Open Source Security

Considering it had the potential to be the biggest security breach in the history of the Internet, we can breathe a collective sigh of relief that we managed to get off so lightly with the Heartbleed vulnerability. Apart from a relatively small number of isolated cases, there was no great plunder of data, and the worst outcome for the majority of web users was suffering the inconvenience of changing some passwords.

But with the dust beginning to settle on the episode, what can the technology industry learn from this? Many commentators were quick to point out that OpenSSL was an open source project, and that because of this, open source software was inherently secure. In their minds, Heartbleed busted the myth that, due to peer review of source code, open source software is more secure than proprietary software.

What becomes of the broken hearted? 

Proponents of open source software have long argued that community peer review has the potential to make open source code more secure than code that is not freely available. This is the classic counter to the argument that open source code cannot be secure because it is freely available for vulnerabilities to be found and exploited.

Potential is the key word here.

Peer review of code relies on a community or team committed to maintaining a codebase to ensure its quality. Open source software projects are ever-evolving beings with new code being added all the time. It is up to the core management team of a project to make sure it all fits together and works to improve the codebase.

A problem that exists with many open source projects is that everyone wants to contribute code, but nobody wants to check it afterwards. OpenSSL, like many other open source projects, relies on volunteers for testing and tidying up of the codebase to ensure that the project continues to function. A lack of adequate testing and checking can be identified as the reason why the Heartbleed vulnerability went unreported for two years.

OpenSSL is depended on by around 75 percent of the world’s web servers, yet up until Heartbleed was detected, the project was run on an operating budget of $1 million, a core team of eleven members, with only one full-time paid member of staff. With this level of resources, it does not seem surprising that a vulnerability was found within its hundreds of thousands of lines of code.

This isn’t a problem with open source security per se, but a problem with the industry taking open source projects for granted. Some of the biggest companies in the world use OpenSSL for critical online security, yet contributions in terms of resources or capital into improving the project remained extremely low.

Better tomorrow

But those critical of open source security have selective memories. Code flaws and vulnerabilities are nothing new, and proprietary software is just as susceptible to the kind of human error that caused this issue. Very recently we’ve seen an example of a long-term latent vulnerability in Microsoft’s Internet Explorer, and no one can argue that development teams in Redmond are under-resourced.

To its credit, as an open source project, it was possible to pinpoint exactly when the offending code was contributed to OpenSSL, and who was responsible for it. This is a level of transparency that never could have been achieved with proprietary software. One of the big software companies is unlikely to ever divulge who was responsible for a flaw in its code, let alone how the error was made.

While the reputation of open source software may momentarily have been damaged by Heartbleed, in the longer term, this incident can have a very positive effect on the future of open source software.

Two weeks following the revelation of the vulnerability, the Core Infrastructure Initiative was launched by the Linux Foundation to help support and provide funding for open source projects critical to the web’s infrastructure. Support from big players including Amazon, Cisco, IBM, Intel and others should ensure that the resourcing problems that affected OpenSSL should not be an issue for similar software projects in future.

The OpenSSL project has also been forked in the guise of LibreSSL, with the aim of creating a more secure, less complex and stable implementation of the SSL protocols. Within a week it had removed 90,000 lines of ‘redundant’ code from the OpenSSL codebase and had attracted new volunteers to the community to manage the project. More importantly, it offers a choice for those looking at SSL encryption which can only be a good thing for both end users and the technology as a whole.

Perhaps most importantly, however, is the attention it has brought to the importance of open source projects like OpenSSL. There is a renewed sense of responsibility from key players that they need to support the development and maintenance of communities and codebases. It will also undoubtedly lead to more rigorous testing and review from project managers across the net.

Heartbleed was an open source problem, but one that has been fixed in a very open source way. This won’t be the last vulnerability detected in open source code, but you can be sure that this is a watershed moment for open source projects. Because of Heartbleed, open source software will be better engineered and more secure, despite what its detractors might like to think.

This opinion was contributed by Steve Nice, CTO at Reconnix (formerly ForLinux), an open source technology solutions provider.

How well do you know open source software? Take our quiz!