I have blogged about security in software development a couple of times in the past few months. The topic has been on my mind again recently since a new client began questioning me about how we ensure security doesn’t get forgotten in the many iterations of agile development. His point was essentially this: If, in large or complex projects, new code is released a couple of times a week, how can you possibly ensure the code is secure for each release? Surely with such volume, ensuring security is included is not only time-consuming but also easy to forget.
My answer was a little longer – perhaps too long as his eyes began to glaze over after a while, so I will keep it short here. Simply put, the traditional point-in-time security models that we use with waterfall-based clients cannot be used for agile-based development. We have created a different approach to security and one that I believe is much more appropriate. Our method is grounded in one simple precept: security is not a one-time event. As an ongoing process it is integrated into the entire software development process.
In the agile software development method, functionality is added during sprint sections. Therefore we include security in the sprint cycle too. We build the security for any new or changed functionality that is added in a particular sprint, in the same sprint; and we do this for each and every iteration. This means that each piece of the software should be secure from the time it is created. Therefore the whole package should be secure. In addition, whenever the software is tested, it is also tested for security faults.
My client also mentioned the time it takes to do this. It might sound like a very time-intensive method, but I would like to make two points. First, we have developed powerful security automation tools which we use for some, but not all, of the security process. Second, this is security – it isn’t something that can be skimped on. The process may be a little longer, but we want to ensure your software really is secure. What’s more, none of our clients have complained about the length of time of our security build-and-check, so far.
This is a huge simplification of the process we use for security in agile software development. However I hope it conveys the essence for achieving the continual security that agile demands – i.e. planning, using security controls and, vitally, making time in the sprints for security. This ‘essence’ should be very similar in all agile developments, all around the world. If it isn’t you should be questioning the developers closely about their security processes.