OpenSSL came under fire this past week through the now infamous Heartbleed bug.
This open source encryption software is used by over 500,000 websites, including Google, Facebook, and Yahoo! to protect their customer's valuable information. While generally a solid program, OpenSSL harbors a security vulnerability that allows hackers to access the memory of data servers and potentially steal a server's digital keys that are used to encrypt communications, thus gaining access to an organization's internal documents.
Technically-known as CVE-2014-0160, the Heartbleed bug allows hackers to access up to 64 kilobytes of memory during any one attack and provides the ability for repeat attacks. Faulty code within OpenSSL is responsible for the vulnerability and -- as an open source project -- it's hard to pinpoint who is responsible much less scrutinize all the complex code created for the SSL project to find such a minute vulnerability.
While I'm definitely not knocking open-source projects -- Wordpress and Mozilla Firefox are both open-source and world-class programs -- there needs to be careful scrutiny over any contributed work submitted to open-source projects. As Zulfikar Ramzan, CTO of Elastica, told the New York Times, "Heartbleed is not the main part of SSL. It's just one additional feature within SSL...So it's conceivable that nobody looked at that code as carefully because it was not part of the main line."
The owners of open source projects need to examine the testing harnesses used prior to checking in code, and upgrade their quality assurance strategy to check for both functional and structural software quality problems. Testing collections of contributed modules alone is not enough -- we need to also test against the whole integrated system to ensure that the new variables and call-outs work dependably and securely with the main body of code. For example, Salesforce.com requires that builders of custom code also build test harnesses, run those tests, and submit the results as well as the original and test code back to them for review. Only after review will Salesforce.com allow the introduction of custom code for a deployment into their Force.com platform. Open source projects should demand the same from their contributors.
If you are integrating open source software into your proprietary code, don't take quality for granted. You too should be running your own functional and structural quality checks against the introduced code as well as the whole integrated system. This means that those incorporating open source code should run their own traditional functional test suite, along with system-level static and dynamic analysis. It's always better to be safe than sorry, and advances in automated testing penetration testing, and static analysis, along with the availability of temporary resources in cloud computing have reduced the cost and effort of continuously running and verifying tests.
The Heartbleed bug was around for quite some time before finally being exposed. Don't leave the discovery of a lurking menace up to chance; be proactive and protect yourself and your consumers.
Sam Somashekar is the Program Manager for the Consortium for IT Software Quality (CISQ), an IT industry leadership group comprised of IT executives from the Global 2000, system integrators, outsourced service providers, and software technology vendors committed to introduce a computable metrics standard for measuring software quality and size. Founded by OMG and the Software Engineering Institute at Carnegie Mellon, CISQ is a neutral, open forum in which customers and suppliers of IT application software can develop an industry-wide agenda of actions for improving IT application quality and reduce cost and risk.