The Developer Did It…

My pinned tweet got a lot of attention online, in fact it’s got more attention than probably ever one of my other tweets combined – even more than that time I had a Rap Battle over twitter! Tweets are short, you’re limited to 140 characters and it’s difficult to give depth and context in such a small message.

From my pinned tweet most people seem to agreed with me, however some people very much did not – however I felt the attacks against this message seemed to miss the underlying point I was trying to make; a point simply of semantics.

To address the point of the message being inaccurate – The point I was trying to raise that vulnerabilities lie in code and not in attackers intensions. The point I was trying to raise was that in my professional experience, of actually working through exploit development, the vulnerability itself is never put in place by an attack but instead a developer. A hacker working through a buffer overflow did not set a static buffer without bounds checking, the developer did. A hacker exploiting SQL injection did not insecurely concatenate user input, the developer did.

To address the nature of it being trite, or dull through overuse – I felt that it was an important distinction to raise as many people are taking an incorrect point of view on issues such as this one which is damaging companies ability to effectively defend themselves. Blaming attacks on nation state level advanced persistent threat groups might sell newspapers, but it won’t make applications more secure; understanding the origins and reasons why vulnerabilities emerge will.

I also do not believe that we should blame developers. They operate under very different restrictions to security researchers and are often under pressure to just make something work and get it shipped. Furthermore, Security is hard!

My message is not one of blame, but understanding. Blaming hackers won’t fix security vulnerabilities but understanding the origin of a security flaw and the fact that it is built-in to code not forced-in to it will allow a company to build more secure systems. If we take a step back from the world of zero days and APT groups and spend just a moment trying to understand the reasons that vulnerabilities are introduced into applications we’ll be in a much better position to minimise occurrences in the future.

We have to empower developers to ensure security. We have to give them time and resources to do things properly. We have to stop pushing until the due date and then just releasing it and hoping for the best. We should instead ensure that security testing is done throughout the development lifecycle, not bolted on to the end.

I feel that my tweet opened an important discussion online and I’d like to thank everyone who commented, positively or negatively. The discussion is important.  So here are a few of my favourite replies:

…and my personal favourite: