Will Open-Source Money Prevent the Next Heartbleed?

By Sean Michael Kerner  |  Posted 2014-04-14

Will Open-Source Money Prevent the Next Heartbleed?

The Heartbleed security vulnerability dominated tech headlines last week as a critical risk to the foundation of the Internet.



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.





Will Open-Source Money Prevent the Next Heartbleed?


"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.



Rocket Fuel