“Heartbleed Bug Affects Gadgets Everywhere”
“Heartbleed: Android Phones Still at Risk for Data Breach”
“Heartbleed Bug Responsible For Zombie Apocalypse”
It’s not hard to find an article about the catastrophic Open SSL bug, Heartbleed, aptly named due to its stealthy exploitation of a TLS heartbeat extension vulnerability. Affecting more than 17 percent of the Internet’s secure web servers (a conservative estimate puts it around 500,000 worldwide!), Heartbleed essentially exposed the multitude of private keys, user cookie sessions and passwords in said servers to the seedy underbelly of web crooks. It really is a bloody mess.
It’s my general opinion that tech news bloggers can be a bit hyperbolic when it comes to security hack headlines; this time I highly recommend that you listen to the hype and take some time to change your passwords. Especially those of you with ten passwords that all happen to be the name of your first born. I will address you in a later blog entitled Things That Keep John Basso Awake at Night.
Now this is the part of the blog where you may be expecting us to diverge into a downward spiral of increasingly complex technical drivel about the bug. I will save you from such a digression. Suffice it to say that Heartbleed is now a Common Vulnerability and Exposure, security bulletins have been issued, passwords will be changed, investigations drag on… and so it goes. But what is the big picture of the Heartbleed madness? What is the lesson?
Few Developers, Many Testers
In the programming world, there is a widely accepted theory that if you make code publicly available it will result in a higher quality product. In a utopian nerd world, the Open Source methodology enables many developers to participate in the design, development and implementation of a given product. Since each developer has their own unique skillset and point of view, the idea is that the product will be more sound and robust as a result. More programmers, more good ideas, less vulnerabilities.
Recent articles from popular tech blogs and news sites have exposed a lesser known aspect of open source projects: the majority of code is a labor of love from a small group of core contributors. The major benefits of open source development have always been attributed to the size of the developer community supporting them, and in many ways this holds true. The community is made tangible through a multitude of forms that any techie can read or participate in for help on that particular product. The result is a small group of developers actually committing code to enhance the product, and a supersized community of testers.
9 Nurses Don’t Make a Doctor
While I am enthralled and excited by the idea of an army of testers, there are chinks in this armor as well. More doesn’t always equal better, particularly in the realm of software QA and testing. Take Heartbleed for example: this bug has been surging on for almost two years completely undetected in Open SSL’s enormous active community. Of course nobody is necessarily to blame for the latent discovery of Heartbleed, but therein lies the issue. A lack of testing processes creates the potential for large oversights in community testing environments. The massive communities of most open source products are essentially performing feature testing, a crucial step indeed, but certainly not the whole enchilada. A deeper understanding and technical skillset is required for effective security and performance testing, not to mention a carefully executed, comprehensive testing strategy.
According to a recent development article in Venture Beat, data from a report published out of development testing service Coverity confirms this distinction between the level of testing in open source and closed system projects. “Large open source projects tend to lack standardized processes to ensure code quality, and so the error rate increases. In commercial or closed-source software, developers experience almost the opposite conditions. Large projects tend to have well-defined formal testing processes, which ensure higher code quality, and small projects tend to be hasty, quick endeavors that show the effects of growing pains, as no standardized testing is in place.”
When you have a cold, it’s pretty easy to find treatment. You can go to your primary physician or even just make a quick stop into the nearest urgent care facility. If you are a do-it-yourself kind of guy, you might even consult WebMD for some over the counter medicines and home remedies. But for a more serious ailment, let’s say cancer, urgent care isn’t going to do the trick. You need a specialist, probably even a team of specialists, on your side.
For more blogs about QA, testing, and the occasional radical technology prediction, check out my other blogs!