Author: Tracie Berardi

The Heartbleed Bug reinforces the need to monitor the quality of open source software

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 customers’ 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 run tests 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. Advances in automated testing, penetration testing, and static analysis, along with the availability of temporary cloud computing resources 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. It’s always better to be safe than sorry.

What are your thoughts on the Heartbleed Bug? Share them with us in the “comments” section below.