Agile teams are known to produce reliable and high quality code quickly. However, it is observed that the pressure to deliver quickly might result in short cut reviews, curtailed testing and lack of attention to secure code. Is secure development as good as wishful thinking with Agile?
A study based on small and medium enterprises suggested that, Agile teams do not take security seriously even when building systems which are accessible over the web. The study quotes,
The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives.
Adrian Lane too looked at the risk of developing software with Agile methodologies in terms software security. According to Adrian,
Focusing on the efficient delivery of features, textbook implementations of Agile come at the expense of secure software development, and push security verification and services outside of the software.
Rocky Heckman suggested that with techniques like TDD and pair programming in place, most of the focus continues to be on functionality.
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 modeling.
Does Agile development mean a total disregard for security? There seems to be a way out.
Jim Bird suggested that with a little caution it is possible to deal with risks in an incremental way.
According to Jim, the security practices have to be burnt into the teams just like other quality practices. Teams could use incremental Attack Surface Analysis to watch for changes in system's security risk profile which might occur as a result of changed architecture of interfaces.
Threat modeling doesn't have to be a big deal for teams that are building software incrementally and that know the code well. Most changes that can be done in a 1-week or 2-week sprint are small and incremental, and shouldn't take a lot of time to review even when you have changed the attack surface.
Jim also mentioned the use of security sprint, which Microsoft calls a security spike or a “mini security push” where the team looks for security bugs in existing code before making any further major changes. Jim quoted Adrian Lane when he mentioned that security is primarily a development team concern than the customer. The development team should take responsibility of giving adequate attention to security in their development process.
Even a strong and well-intentioned Customer can't be expected to understand application security issues or how to build secure software. They already have too much on their plate.
Thus with the right measures and mindset it is possible to weave in security as a part of the development process.
As Jim put it,
There's no reason that Agile Development has to = Security Fail. The technical work, the commitment to quality and detail that is required to build secure software is the same, regardless of what development approach a team follows.
