This week the world saw a serious vulnerability manifest itself. Of course we are talking about the infamous Heartbleed vulnerability. By now it should need no further introduction. In the wake of it various recommendations and thoughts are beginning to emerge. I stumbled upon a blog entry yesterday where the author tries to combine Heartbleed with lack of good password systems and handling. The baseline was that users has too many passwords to remember and that they reuse their passwords – thus a fix is needed. As a proposed solution the author stated that collectively “we” (?) need to reinvent and update the Internet to support modern usage.

Having that in mind for later Slashdot reported that the issue was just an honest mistake. It was a slip that went undetected through the internal processes for the OpenSSL project. The developer made a slip making it vulnerable, the authority to approve the fix/feature passed it through not noticing the slip. Both instances failed. How could this happen? It’s simple. Because of humans. During any development there are many things to keep in mind at the same time. A developer must always think about consequences – but being a human it is impossible to think of everything at the same time. Every now and then issues like this goes wild. Stating that OpenSSL is Open Source would automatically makes it safe falls directly to the grounds. Slips happen in closed source software too. Just look at the various CVE databases for a given product. Ask yourself – what makes Apple and Microsoft vulnerable – why is that?

Back to the original example. No. I do not think we must “reinvent” the Internet and passwords – completely. What “we” need is better focus on quality. Developers need testing tools and education. As of now many corporations states “we do testing” without specifying what testing implies. Sure – unit testing can make us do better. But only so far since it requires competence to write such tests properly. Same things applies to other testing techniques. Code reviews is often placed into the testing category. Code reviews requires knowledge of what to look for. From experience – I’ve seen inexperienced developers do code reviews. On the other end I’ve seen experienced developers having no clue of what to look for falling back to looking for improper indentation and missing documentation blocks. We need knowledge to know what we are looking for, the implications of items found and how to properly mend it. But – we are not safe even with this scheme.

As developers I believe we need better automatic testing tools. Having a tool scanning your code and properly test it by fuzzing, looking into common anti patterns, common mistakes and what not’s would indeed come in as an important factor to raise quality when making software – thus making the web connected world safer. And – these tools exists. This raises another question: why aren’t we? I can not speak of the entire world on why this is. My theory includes costs and lack of knowledge of their existence. Costs being that management see no economic opportunity with regards to both time and money. During my years in development I have seen no implementation of such testing tools. It appears, to me, that developers and the management don’t know such tools exists. Or it could be because of economy – yet again. The cost of such tools is higher than what a given software project would cash in. I suppose the same things applies to open source projects also.

My five cents on the matter.