Can we get something for nothing?

A lot of the time when I'm presenting or discussing implementing a Secure Development Lifecycle (SDL) with clients the same question pops up.  'How much is this going to slow us down?'  Well to be honest, you can't insert anything into a Software Development Life Cycle (SDLC) without adding some time or resources.  The problem is, we've been looking at this from the wrong angle.

We've been creating software for 30+ years now.  To be fair, due to the complexity of software and computers in general, we're barely out of our infancy.  When we stared we flew into it with rose coloured glasses thinking that everyone who actually 'does computers' will know how to use things and will only use them for the good of mankind.  This is par for what humans are prone to doing.

We learned valuable lessons over the past 30 years though.  Computers need to be usable by everyone.  Because everyone will use them, there will be an element of them that will use them for nefarious means. So our initial ideas about how to build software were not structured for the environment that computers would eventually be running in.

Now if we had perfect foresight, we would have seen that software needed to protect itself from all manner of ill intentions.  But we didn't.  We thought everyone would play nice.  So when we finally figured out that we needed structured processes to manage medium to large scale software development, those processes were developed with that rosy tint. 

Now we realise that baking security into our software from the very beginning of the requirements gathering stages is a critical component of a successful project. No longer can we afford to blindly follow our previous rose tinted processes for developing software.  The environment has changed. Our foresight, was short-sighted.

So when people ask, will this slow us down, I say;  Yes, and well it should!  We need to slow down and consider the security landscape we are developing in, and for. We should have baked Threat Modeling, and Secure Code Review, and Penetration Testing right into our development processes many years ago.  Had we done that, then we wouldn't even noticed the extra security precautions that we should be using to develop software.  But since we've been skipping that all these years, we can't add it without some impact.  We should have slowed down and done these things a long time ago.

We aren't trying to break an existing process by introducing steps to slow it down.  We are fixing a process that has been broken for 20+ years since we stared trying to work out formal development methodologies.  When you are considering introducing an SDL to your environment, don't think of it as slowing down an existing process, think of it as finally fixing a severely broken one.