By now you’ve likely heard about the Heartbleed bug, a critical vulnerability that exposes potentially millions of passwords to attack and undermines the very security of the Internet. Because the flaw exists in OpenSSL—which is an open source implementation of SSL encryption—many will question whether the nature of open source development is in some way at fault. I touched based with security experts to get their thoughts.
Closed vs. Open Source
First, let’s explain the distinction between closed source and open source. Source refers to the source code of a program—the actual text commands that make the application do whatever it does.
Closed source applications don’t share the source code with the general public. It is unique, proprietary code created and maintained by internal developers. Commercial, off-the-shelf software like Microsoft Office and Adobe Photoshop are examples of closed source.
Open source does not necessarily mean open season for hackers.
Open source, on the other hand, refers to software where the source code is available to the public. Open source projects are generally collaborative efforts because any developer is free to review the code, edit or enhance it, or add features. Popular examples of open source software include Linux, the Apache Web server, and OpenSSL.
Open source (in)security
When anyone is free to view the source code, and any developer can submit changes to the open source project, there are potential security concerns. Without properly vetting the developers, there is no way to know what—if any—secure development practices are being used, and the possibility exists for a malicious developer to intentionally introduce a vulnerability like Heartbleed for the express purpose of exposing the software to attack.
Does that mean that open source tools are inherently insecure, or less secure, than their closed source cousins?
“An argument could be made that the collaborative nature of open source software development compounds the challenge of ensuring security is considered throughout the software life cycle,” David Shearer, CISSP, PMP, and Chief Operating Officer of (ISC)2, said in a statement sent to PCWorld.
The security implications of what should be a simple diagnostic capability in OpenSSL is a prime example. According to Shearer, “One could go as far as to say that we may be heading toward a time where some of the key security architecture components that are available as open source software may need to be more closely managed and monitored.”
But while it’s true that there are some security concerns unique to the collaborative nature of open source and to having the source code open to the general public, there are also ways that open source strengthens security.
“The advantage to open source is that it is so transparent that we can detect and fix quickly,” TK Keanini, CTO of Lancope says.
The truth is insecure code is not an open source vs. closed source debate. In spite of much tighter control of software development, and management of source code, crucial security flaws are still frequently discovered in commercial software that customers pay a lot of money for.
“Finger pointing at the open source development communities or persons or processes isn’t going to fix the problem,” notes Andrew Storms, senior director of DevOps for CloudPassage. “Open source software along with commercial software will always have bugs.”
So, while it’s natural to look for a scapegoat for a flaw of this magnitude, it would be foolish to dismiss the many benefits of open source in the name of security.