10484Re: [scrumdevelopment] Security in an Agile Project
- Dec 4, 2005John wrote:
> Does anyone have any suggestions or real-world experience onI've had some success by implementing some smaller, discrete
> implementing Application Security Life Cycle in an agile project? It
> seems like a full security review each sprint is not realistic, and I
> would be interested in any experiences that you all may have in
> implementing security in a Scrum and/or XP project.
tests that prove certain things about security. For example,
some of the typical set of log in-cases (multiple tries lock
out, password has to be X characters) fit here, as well as
other tests that can be used to show the system is behaving
in a secure way. Some of these tests poke at components to
prove they are secure, and feel more like engineering test.
Of course that's not all there is. I've also worked with
teams that incorporate some smaller security reviews during
their iteration cycles. In the best case, they are working
very collaboratively (e.g., pairing) and the reviews are very
small and continuous. The security review criteria focus on
those things that are harder to test for, like the design and
the way things are coded, and these things become part of the
check list for the ongoing reviews. The security reviews
involve those with the security expertise, perhaps pairing
up with a developer.
I've seen that many organizations feel the need for a wholly
separate and independent security audit, and those are hard
to work into each iteration, so the teams schedule those to
happen every X iterations, where X is as small as possible,
and it happens sufficiently before release to have time to
incorporate the feedback before too much commitment is made.
I see a parallel here to functional testing -- it is more
traditionally practiced as a single, large event, and often
done by a discrete group of people from the core team. Just
like functional testing, I believe security testing benefits
in a agile environment from pulling apart and spreading it
out across time, so that it can be accomplished in a more
parallel and continuous way, and by pulling the security
folks into the team so they have the opportunity to do their
work in smaller, continuous chunks, and to provide their input
and feedback closer to the development work.
That kind of touched on it. Let me know if you want more
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.
- << Previous post in topic