Has Heartbleed Made You Think Twice About Open Source Security? Think Again.
By now, unless you have been woefully under-informed, you’ve not only heard of Heartbleed, you have likely had more than your fill of emails from web sites advising you about their patches. Ironically, as those emails pile up in your inbox, Heartbleed starts to seem like more of a nuisance. But the fact is, the personal information of millions was put at risk and it may be some time before we completely realize the damage that has been done.
Some have used this as an opportunity to point fingers at OpenSSL and Open Source frameworks in general. They point to the collaborative nature of the applications as an increased security threat. The argument is that when anyone can submit changes to an open source project, there is no way to know if a malevolent developer will intentionally create a vulnerability, similar to Heartbleed, with the sole intent of exposing security weaknesses within the software.
However, Heartbleed isn’t a result of the fact that OpenSSL happens to be open source software. As we’ve seen time and time again, even the most robust enterprise software can be compromised by security flaws. This truly is not a question of whether open or closed source software is more likely to be compromised. As long as software is being written, whether open or closed, there will be holes to be patched.
When thinking about the security risks of open source software, there are two key points to remember. First, when backed by effective open source communities, open source software is made safer because so many developers actively test and fix the code.
For example, Spree has one of the most active developer communities in the world. Spree developers communicate regularly regarding all kinds of issues, be it feature improvements or bug fixes. Of course, Spree also utilizes extensive testing tools before releasing any software. With the combination of our in-depth testing and the community’s vigilance, we can be much more on top of quick resolution of bugs than closed software systems.
Second, when there is a need for a security patch or other bug fix, the person in control of implementation is…you. With closed source, you need to wait for the enterprise in control to fix the problem and make it available to users. For example, Akamai, one of the best, most sophisticated technology firms on the planet, is still working to address its Heartbleed vulnerabilities. Thus, users have no choice but to wait on Akamai for a complete fix. Open source users can do what they want with the code. They can use a patch that has been made available on Github, or can otherwise modify their code as they see fit. In fact, because Spree is open source and its users control their own code, they can choose to replace OpenSSL altogether if they so desire.
At the end of the day, the truth is that no piece of software is perfect, and that both open source and closed source frameworks are vulnerable to security flaws. The fundamental difference to remember is the relative ease with which these inevitable bugs can be found and fixed in open source platforms, so that consumers can again be protected as quickly as possible.