Agile development methodologies might be the new fad in software design but how much emphasis is there on secure code? Australian .NET developer and consultant at Readify, Rocky Heckman, reveals some concerns of agile development methodologies.
commentary I was at the Ruxcon Security Conference in Sydney a while ago and some of the conversations were around Agile Development Methodologies (ADMs). At the conference I overheard a discussion where one of the delegates said, -We need to target -ReallyBig” Corp. for penetration testing and security consulting because they just adopted Extreme Programming as their development methodology so they’ll be easy targets”. It started me wondering on just what ADMs have sacrificed for rapid development and what impression this has left in people’s minds.
The general consensus was that ADMs certainly don’t do threat modelling, or security focused code reviews. Even with Test Driven Development (TDD) the focus is on creating tests that prove functionality and exercise the class. While this is a good technique and does well with code coverage, they don’t mention testing for security. The tests focus on high quality code from the perspective of the features and reliable repeatability of operations. There is little or no mention of penetration style testing or threat modelling.
Even with Pair Programming the onus for ensuring that the application and code are secure lies entirely with the developers writing it. Most ADMs don’t allow for security advisors reviewing designs and code. This is how we got into trouble in the first place. Quite simply developers still aren’t as well versed in secure coding as they should be. It’s critical to take the time to focus on the security of the applications. ADMs don’t lend themselves well to ‘taking time’ for anything.
While there is time allocated to putting together a design for the product, these methodologies do not propose security reviews of those designs. There is no threat modelling or attack tree development. They also don’t allow for an independent security advisor to review the designs for logical security flaws or flaws in proposed protocols.
Isn’t it a little worrying that you can pick up almost any book on ADMs and not find one mention of security in it? Security has to start with the Software/System Development Life Cycle (SDLC), and the design. If you are designing on the fly with a focus to just getting the functionality out the door for this push or sprint you aren’t thinking about securing your product. The design won’t take into account the bigger picture and the security impacts of this piece of work. ADMs are great at getting the right product to the customer in a timely fashion. They produce systems that make happy customers within short timeframes.
Where the problem arises is that security takes time. It’s not hard, it just takes time, and that is time that ADMs don’t’ want to spend. The focus is getting the product to the customer. The quality of the product is in the functionality and meeting the customer’s needs. They are very good at that, but it is often at the expense of thorough security.
If security reviews, and attack/defence patterns can be applied easily, in more of a template style, they wouldn’t be as much of a burden on the timeline of a project. A set of common attack patterns and the recommended defences would be easy to follow and therefore more palatable by the ADM developers because they don’t have to spend a lot of time worrying about security. They can get back to what they do best, coding the features.
How do we secure ADMs without sacrificing what they do well and preventing the products from being labelled as soft targets? This post has been fairly pointed because I would like to generate some discussion on this and get a feel for people’s positions around this topic. Please express your opinions but keep it civil!
Rocky is a .NET developer/consultant specialising in software design and
secure software development. He is currently working for Readify. He can be contacted from his Blog at