Security is every developer’s job

In one of his latest blog posts published in the OWASP feed, Dinis Cruz points out, that secure development and application security itself must be invisible to developers. I can’t completely agree to that.

On one side, Dinis is right: The frameworks we use must be way more secure out of the box and way easier to use. But this will take a long time, and probably never be true for all the frameworks and functionality we are using in our everyday work.

Having said that, I always want developers to think about security while implementing a feature or a bug fix. As they (should) think about general code quality. They should ask questions like 'What can an attacker do here?' and 'How do I have to protect this method?'. These questions do not require being a security expert; they just require some basic security knowledge and awareness. And those questions even make sense when using secure frameworks.

So how can we make our software more secure? First of all, we need security aware developers. In other words: secure development training. Not all of them have to be e.g. cryptography or LDAP authentication experts (one per team, if required at all, is enough). But basics like input validation/ output escaping and the correct usage of prepared statements is a must for every developer. Don’t rely on the chosen framework here and that somebody else will clean up your mess. This is every developer’s job!

And secondly, we need more secure frameworks, as Dinis points out. I don’t want security features hidden to the developer, but easy to use and enabled by default. Look at the prepared statements example again. Why is it possible to use a secure alternative for normal statements in an insecure way with String concatenation (which leads to SQL injection)? There should be no way to do that. And why do I have to configure all the web.xml parameters myself, that make my application more secure (like http-only and secure for cookie handling)? OK, the last one is more a configuration than an actual framework issue, but you can see the point.

In the end, we can’t and shouldn’t stop secure development training for our developers. Even if it is expensive to train them all, one security aware developer is not enough. Companies really caring about secure development and application security train their developers. It’s that simple. And we should stop using insecure frameworks, and/ or influence their (open source) developers to make it more secure out of the box. Make suggestions on how to use functionality more easily and more secure. I bet that most communities welcome such contributions.

In my opinion, it is only the combination that will lead to more secure software: training and (more) secure and easier to use frameworks. Picking one will not bring us much closer to the ultimate goal of secure applications.

Published by Dominik

Java architect, developer, author, trainer, speaker, JCrypTool project lead and secure programming enthusiast.