Agile is not an ideal development methodology from a security perspective, but then again - what is? the Agile family of methodologies represent the dominant approach to building software today. In some ways they are quite helpful to security, not when compared to theoretical SDL approaches but when compared to actual, real world alternatives. So while Agile is not the be all, end all from a security viewpoint, as your Mom told you - make the best of it. Here are some things that work well in many Agile projects
* Test focus - this is easy. From the beginning Agile, XP et al emphasized Test Cases over almost everything else. This actually plays well with infosec's primary strength - white box and black box testing, putting the tools to work here make sense assuming that we can cope with...
* Short release cycle - infosec must be able to deal effectively with fast iteration of Agile projects, being ready to execute vulnerability assessments every few weeks, automation is a must have, and this is possible if you have...
* Dedicated staff - infosec needs team members dedicated to Agile projects, in the same way DBAs are assigned to support developers, infosec must assign appsec people to work with specific projects. To make this work, the security team must change from its traditional structure. The infosec team cannot sit in a separate group that checks in once a month or less frequently with development teams, they must be way more engaged with a infosec person carving out dedicated time to each project. Infosec should have a representative identified for each Agile project, they may not be in each and every daily Scrum meeting (though this is ideal) but they need to know the feature list, backlog list, prioritizations and other project drivers as well as everyone else on the team
Staffing up to deliver on the above positions infosec to get some ancillary benefits by being embedded with the project teams:
* Emphasis on roles - one strength of Agile is a focus on actor roles, this is a good head start on working on RBAC models for applications
* Close communication - helps to understand dev team priorities, and what and how much security is potentially going to be able to ship with which release. Visibility into what else is in the bug list
* Short release cycle - less time to to identify issues
* Heads up on what is shipping - gives better view into the assets that are being deployed, ability to inventory what may need to be fed into operational monitoring systems, and IAM
* Discover dependencies -whiteboards don't crash, but code does. Often not thinking through dependencies is the root of future problems, so being close to the ground with the development teams is essential to shake out these issues early
Permit me to dream, a bit. The issue in Agile, and all other methodoloigies, that always comes is the negative requirements that security has in spades. The long list of things we don't want to happen, these can be expressed via Threat Models, Misuse Cases and non-functional requirements, but these rarely fit well in an Agile project. Checklists can help to fill this gap by enumerating known bad ways to do things and giving specific guidance on how to avoid.
So Agile is not be everything you need for a successful appsec program, but most security teams do need to figure out how to work with Agile to make appsec happen. What have you seen be successful (or not) in Agile appsec?