Heartbleed: What happens when people don’t work properly.
Heartbleed has captured the public’s imagination and drawn lots of attention to open source, some of it good, some of it bad. First of all, open source was not the cause of this bug, the cause of all bugs will always be the same. People.
The key to this bug and understanding the fallout is identifying the lessons to be learned and appreciating just how much the open source approach has limited the damage caused by humans being human.
People are fallible and always will be, we need to find ways to cater for that fallibility.
Where there are methods to help us with our fallibility, we need to properly apply them.
There is an ever evolving science of testing software. Initially developers themselves simply responded to user’s bug reports and fixed the issues as they arose. The days of using users as testers are for the large part behind us and now more robust testing is focussed on bug prevention rather than bug fixing. The problems arise when software is inadequately tested and Heartbleed falls into this category.
At Reconnix, we develop software in a quality-focussed way and employ over-arching strategies such Test Driven Design (TDD) and unit testing as well as functional and user testing. However, none of these methods would have exposed Heartbleed, what is required for high security software is lengthy fuzz testing. Fuzz testing is typically used for testing closed-source software as it makes no assumptions as to how the code is written it simply bombards the inputs of the software with large amounts of random and unexpected data and then monitors the software for crashes, memory leaks, and in Heartbleed’s case unexpected output.
So while ever humans are still writing code, we will need robots to test it.