I decided to write a blog about building secure web applications to try and share what I have learned about making security a first class citizen in software development. The process of software development can be so focused on producing new features many others things are outsourced to other parts of the organisation, security among them. I believe this is dangerous, because the best person to fix a security problem is the person who is writing it as they are writing it, because they have the best knowledge of the implications of the vulnerability, and how to mitigate it, they just need to know that it is a problem at that moment.

As I am writing this I have been working as a professional software developer for over four years and looking back I am still surprised at how little security played a part in the development process of building web apps for large enterprise customers. This is not to say that these enterprises did not take security seriously, they had security teams, they engauged pen testers, they had firewalls, but all these things happened after we had finished development.

Getting started in professional development you learn a lot about developing “quality” software. You learn about style guides, unit test coverage, static code analysis, documentation, indentation standards that you need to pass before the software you write can be deployed. Your features will be tested for functional correctness many times, the deployment of the build will be tested many times. If anything goes wrong you will hear about it, either by a robot with attitude, or face to face with the person who found the problem. These things are your life while building features, this is the feedback that allows you to grow.

Compare this to how we treat security in development. For the most part developers were interested in writing secure web apps, but the only feedback is delayed and very specific, in that sometimes a pen test many weeks later would find a security hole in the a feature that you had released. The problem is also that if you didn’t hear back about that feature, you had do assume that it was fine. I have now learned that this is not a safe assumption, many problems are introduced and no one notices, you just have to do your best to write the most secure code you can.

Writing secure code first time is important because right now the feedback loop is so long between writing code, and having security testing look at it, by the the time you get the results your team probably has moved on to something else. Shrinking the feedback loop, would be fantastic, but is not a reality for many of us at the moment. We have to bring it into our teams ourselves, checking the security of the code as we write it.

This blog is about moving from writing code and hoping it is secure, to writing code that is demonstrably as secure as it can be. There are more than enough security bugs in software now which no one knows about without us writing known bugs out of ignorance. Let us start taking security as seriously in development as we take code indentation and unit test coverage.