Is open source the culprit of the Heartbleed vulnerability?

The news about the Heartbleed vulnerability sparked heated discussions on the web. This loophole from the OpenSSL project allows an attacker to steal user information over a wide variety of encrypted and transmitted network data. As OpenSSL is widely used in web servers, mail protocols, and communication protocols, the number of users affected at a time Hard to estimate.

The Heartbleed Vulnerability once again shows the vulnerability of cybersecurity, of course for those who value security vendors, which also gives them the opportunity to upgrade the basic services to increase security strength. This may seem like one of the few "benefits" brought by this serious security threat.

So let's take a look at the relationship between OpenSSL and open source.

Deadly Vulnerability in OpenSSL - SSL encryption is implemented via open source (Secure Sockets Layer). Perhaps many people may question: Is the technology developed using open source tools a mistake? If you use closed source will appear such a result? However, we still listen to the safety experts to explain.

Open source or closed source?

First to explain the difference between open source and closed source. Our so-called Source refers to the source code of the program, that is, the text command that really drives the App to run.

Closed source App will not share its source code to the public, the code is mainly written and maintained by internal developers. We know Microsoft Office and Adobe Photoshop are the best examples of commercial closed-source.

Open source, as its name implies, is to expose the software code to the public. Open source projects are often done collaboratively, so any one developer can see the source for free, write code, add functionality, and more. More typical open source projects include Linux, Apache Web server and OpenSSL.

Potential dangers in open source projects!

If Developer A submitted a revised document for an open source project and Developer B was modifying the code in the project, the potential danger could have come from there. To make matters worse, if some malicious developers deliberately introduce some kind of heartbleed vulnerability into open source projects, the consequences are unthinkable. Are not open source tools inherently unsafe? Not as good as closed source security?

"This leads to the conclusion that the security implications of collaboration in open source software development are one of the key determinants of the entire software life cycle," said ISC COO David Shearer.

In fact, it is best to take advantage of a simple safety diagnostics function to accomplish this task if it is not possible to detect errors in the project manually. Shearer said: "In fact, open source teams can take a while to focus on the full range of key security architecture / component reinforcement, in particular, open source software to do more collaborative part to do more closely manage and monitor."

Of course, the security issues that exist in the open source project collaboration team can not be explained by the fall, so the way to enhance open source security is not the only one.

"The advantage of open source is that the entire process is transparent and we can quickly detect and promptly modify bugs in our programs," said Lancan CTO TK Keanini.

Although it is not unexpected to see such a Heartbleed loophole, it would be a bit arbitrary if all the blame is on the open source. No matter how strict the development and management of the software source code, some unexpected security loopholes will appear in the commercial software, even if you spend a huge amount on this software project.

"Staring at an open source community, individuals or programs can not solve a lot of problems at all." Open source and commercial software are like brothers, but bugs are always their shadow, "said Andrew Storms, DevPaper senior director at CloudPassage.