Give me a pound for every development team I’ve heard saying that they use an “Agile” methodology and I’ll be able to fulfil my planned dream of retiring to a small Greek Island where I’ll spend my days picking olives and feeding the goats. Dig a little deeper though and I wonder whether or not most of the time the word “Agile” is used as a euphamism for “very quickly without any plan.”
It goes without saying that the outcome of poor planning is poor delivery. But Agile has got nothing to do with a lack of quality. In fact, when approached correctly, I think that Agile development is the best way of all because of the continuous communication between developers and customers, the objective to keep things as simple as possible, the iterative ways of working, and the regular reviews of code, quality, and behaviour.
This is fresh on my mind right now because of a project that I’m reviewing the security for. The lack of any documentation has been put down to the work being Agile however, I call it CAC – Cutting All Corners! It also reminds me of some work I was involved in a few years ago where I had to work with a pair of so-called “extreme programmers.” They took a pride in the speed with which code could be developed but the reality was a good deal of time spent fixing bugs and redesigning work because of misunderstood intentions.
Worst of all though is when Agile is used as a excuse for not including security requirements. Does an Agile methodology allow a secure product to be developed? Yes it does. Some of the Agile processes that become a natural match for security include
– Pair programming and peer reviews
– Version control and change tracking
– Static analysis of source code (various semi-automated tools are available for this)
An integral Agile practice is “test-first” development where work is performed in very short cycles. A test is considered alongside the business code for it. Once the tested module is working, work is continued on the next cycle. For security aspects this process would be integrated, and the opposite case – “abuse case” – tested. For instance, if a test is based around authentication then security related tests will be based around failed authentication and efforts to force entry to the application.
Where there is not time to specify all the criteria upfront then this isn’t an issue because Agile – done correctly – allows you to add these as you go as well as the facility to return to previous tests as new risks are learnt.
What do you get as a result: reduction in the number of errors, faster time to market, fewer post-deployment issues.