The Heartbleed security vulnerability dominated tech headlines last week as a critical risk to the foundation of the Internet.
Heartbleed is a flaw within the open-source OpenSSL cryptographic library that is widely used on Linux servers and cloud services around the world. While OpenSSL is widely deployed, some have argued that it is not widely supported and that the open-source model itself might be at fault.
Truth is that open source is not about cost; it’s about code that is freely available to consume and contribute to. In the case of OpenSSL, the flaw was found in part because the code is open and the mitigation also happened because everyone has the code. That type of review and remediation mechanism is just not possible with closed source code, where end users and enterprises must wait for the closed-source vendor to release an update for everyone.
As an example, take a look at how Microsoft handles security vulnerabilities in a closed source code product. Microsoft’s Internet Explorer Web browser today is at risk from multiple zero-day flaws that were first publicly demonstrated at the Pwn2own hacking challenge in March. Hewlett-Packard, the sponsor of Pwn2own, only disclosed the flaw to Microsoft, so the risk isn’t widespread.
Still, the simple fact of the matter remains that there are unpatched flaws. In the open-source model, you can’t hide behind a closed door, which in my opinion, provides better security. Security in obscurity might work some of the time, but if you’re secure in the open, you’re likely better off.
The other big question raised against OpenSSL is the level of support it receives. This is a very serious question and one that open-source vendors do need to address. The way OpenSSL works is there are a very small number of core contributors and then there all the various Linux distributions and embedded vendors that consume and package OpenSSL for their own needs.
In the open-source development model, the Linux distributions will also contribute back fixes and even features as they come up. As such, it’s difficult to measure the precise size of an active development community for OpenSSL.
That said, it is now very clear that OpenSSL development could benefit from dedicated full-time, properly funded developers. It’s a need that Steve Marquess, co-founder and president of the OpenSSL Software Foundation (OSF), is now openly advocating for.
In a blog post, Marquess noted that the OSF typically receives only $2,000 a year in donations. Since news first broke about the Heartbleed bug, the OSF has raised $9,000 in donations.
“Even if those donations continue to arrive at the same rate indefinitely (they won’t), and even though every penny of those funds goes directly to OpenSSL team members, it is nowhere near enough to properly sustain the manpower levels needed to support such a complex and critical software product,” Marquess wrote.
Will Open-Source Money Prevent the Next Heartbleed?
Marquess added that, in his view, the ones who should be contributing real resources are the commercial companies and governments that use OpenSSL extensively and take it for granted.
“There should be at least a half dozen full time OpenSSL team members, not just one, able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work,” Marquess wrote. “If you’re a corporate or government decision maker in a position to do something about it, give it some thought. Please.”
Having more people dedicated to OpenSSL seems like an obviously good idea, although I’m not sure that donating money directly to the OSF is necessarily the only, or even the best, approach to improve OpenSSL.
For other open-source projects, like Linux or the OpenStack cloud, what typically happens is that the big companies that benefit most dedicate their own full-time staff to a given project or feature. The open-source model means that even though developers are working for their own companies, the code is open and shared across the entire community of a given project.
So what I’d suggest for the OSF is to open up its model, take on corporate sponsorships, which include both money as well as full-time equivalent developers. In that manner, in addition to core OSF dedicated staff, there will be multiple core contributors working full-time across the multiple vendors that actively consume OpenSSL.
In addition to more humans, there is always a need for more testing automation. Most automated development and continuous integration testing suites today are focused on making sure that code commits don’t break existing functionality. I’m not sure that automated testing suites would have caught the Heartbleed flaw when it was committed, but having automated test suites that look for security flaws in code is the right thing to do.
Through a combination of automation, people and funding, the open-source model can further be improved and hopefully prevent the next Heartbleed flaw from ever occurring.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.