Agile Manifesto Analysis - Part 1

I've been re-reading the main principles of the Agile Manifesto recently, and although they are very interesting they don't really address security issues.  Over the next couple of posts I wanted to take a look at these principles and see how they related to security concerns.  The principles are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

 First up:

Individuals and interactions over processes and tools
On Agile teams looking to build secure software every individual has to have a base level of knowledge of secure coding.  Every developer has to be able to trust that the other developers are doing the right thing with regard to security.  Collective code ownership is a cornerstone of Agile development methodologies and it requires common coding standards.  Building secure software requires secure coding standards.  If Agile teams are going to create secure software, then all developers have to be trained in secure development to avoid injecting technical application vulnerabilities into code they write.  You have to be able to trust your team members.

That being said let's not rule out the use of tools.  From open source and freeware tools like FxCop to commercial tools like Fortify, there are a number of tools that can easily integrate into Agile processes that can help to enforce base-level security standards at the source code level.

Also processes can help to enforce consistency.  And when it comes to security, consistency is crucial  A chain is only as secure as its weakest link and an application is only as secure as its least secure point.  Integrating security into Agile methodologies requires selectively moving away from iron-clad processes and procedures.  This tension will be a theme discussed repeatedly on this blog.

To sum it up: individuals are important and at the end of the day it is individuals who write secure or insecure code.  But let's not throw tools out the window because they can be a force multiplier by helping to ensure consistency and provide a baseline from which individuals can improve.  And let's not throw process out the window because consistent execution is required for dependable security.

Comments

[James]

The perspective of agilists in corporate america is more inline with secure coding practices than the consultancies that pitch it...

[Dan Cornell]

I would tend to agree with this. Most of the groups we work with on integrating security into their SDLC are already thinking about security, but unsure what specific tasks they should be undertaking and when. Whenever we talk to folks who have had mentoring in Agile (or other) development methodologies the focus of the Agile consultants was always on the particulars of the specific methodology and security was never mentioned.