Sponsored Link •
|
Summary
The ICT security community is suspicious of agile processes. "They do not produce formal documentation" is an often-heard complaint. Agile developers, on the other hand, blithely ignore security concerns.
Advertisement
|
I led a discussion at the Belgian OWASP chapter meeting last week on whether agile processes are capable of producing secure software. Received wisdom in the security community has it that they cannot. Security professionals object to the lack of formal documentation. They argue that without formal specifications, there can be no credible assurance argument. The agile community, for their part, has blithely ignored security concerns.
I do not believe formality is the issue. Formal specifications are not a virtue in themselves. They are only useful to the extent that they aid communication. Often the demands security officers put on developers get in the way of communication, rather than furthering it. Developers find them overly bureaucratic and a hindrance to getting their job done.
To many present, agile development was new. Initially, the reaction was very cautious, especially from the security professionals present. The ice broke when one of them observed that while defending against attacks, the ICT security profession tends to work in a very agile way: do, observe, steer, do - iterate as quickly as possible.
So there is an agile mindset on the development side, an agile mindset on the security side, but what passes in between is distinctly non-agile. It does not have to be like that. We have to get rid of the wall between the two.
Have an opinion? Readers have already posted 35 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Johan Peeters adds a new entry to his weblog, subscribe to his RSS feed.
Johan Peeters is an independent software architect who spends a lot of time plumbing and generally fixing leaks. |
Sponsored Links
|