In April 2014, a major security bug was discovered in the OpenSSL cryptography library, which is widely used across the Internet (chances are that if you’ve been on a secure site with an URL starting with https, you’ve used OpenSSL). The bug itself was promptly fixed, but the fact that it could even have existed for two years without anybody noticing raised major concerns. How could such a crucial building block of our modern Internet infrastructure, used by major organisations across the world, go unnoticed for so long? What other security flaws were waiting to be discovered? Around that time, we held a round table (see the report) to hash over these questions, which highlighted a few interesting findings. In many ways, the issue was an eye-opening lesson. Eric S. Raymond’s saying (often wrongly attributed to Linus Torvald) that “given enough eyeballs, all bugs are shallow” was put into question. Just because a project was Open Source didn’t automatically mean it was more secure. But the alternative was even scarier: who knows what security flaws remained hidden in proprietary code? Furthermore, many people were astonished to discover that OpenSSL had been developed by a team of 11 people, 10 of which were volunteers, and that resources for the project were coming exclusively from small, individual donations. The conclusion was as simple as it was frightening: critical parts of the Internet infrastructure were grossly under-resourced.
16 months later, how has this situation changed? Let’s first look at OpenSSL itself, and then at the larger perspective. In the wake of Heartbleed, two major projects forked out of OpenSSL: LibreSSL and BoringSSL. Forks sound scary, but they’re actually a really important feature of the Open Source model: they allow developers who are not happy with the direction that a project is taking to try to set their own, thus ensuring that communities remain harmonious, collaborative places to work. Most importantly, they generate healthy competition between projects, which is ultimately to the end user’s benefit. OpenSSL wasn’t left out, either. Predictably, donations came flowing in after Heartbleed was discovered. But without some sort of regular campaigning, these were likely to quickly dry out. A more durable solution was needed, and one which would help not just OpenSSL, but all of the many under-resourced Open Source projects on which the modern Internet infrastructure relies. Not a one-off solution, but a systematic change to avoid future Heartbleeds.
One attempt to solve this challenge came a few weeks only after Heartbleed, when the Linux Foundation launched the Core Infrastructure Initiative. The idea was sound: 19 companies agreed to commit to an initial funding pool of almost $4 million, which would be used to finance Open Source projects that are critical to the functioning of the Internet and other major information systems. This has allowed, for example, the funding of two full time developers to continue working on OpenSSL. It’s too early to tell if the Core Infrastructure Initiative has been a success, but just last week it launched a new voluntary badge program, aimed to help developers identify Open Source projects that have made security a priority. The program will consist of a set of criteria and a self-assessment mechanism to help project maintainers evaluate whether their projects comply with security best practices – and if they do, to let consumers of the projects know about it.
If nothing else, Heartbleed will at least have helped to raise awareness within the industry that Open Source projects need resources to be successful and minimise the risk of security vulnerabilities.