Greetings SC-L,
(Sorry for the previous message; I see that my (new) MacGPG is
causing grief for Mailman, so I'm re-sending this message unsigned.)
I saw an article on Dr. Dobb's (via Slashdot) this morning that made
me pause a bit. The article is on "Quick-Kill Project Management" --
full link is here:
http://www.ddj.com/dept/architect/189401902
The article describes a small project team (say 5 developers) who
have suddenly had their dev schedule drastically accelerated on them
by powers outside of their control. It describes some techniques
that the dev leader can use to concentrate the team's focus on
killing (hence the name) the most pressing of issues. Not
surprisingly, there's no mention of security in the article, although
they do talk about conducting code reviews, but only for functional
defects in the code.
What caught my attention here is that I'll bet that a *lot* of small
dev teams end up in situations very similar to the one described in
the article's opening statements. In that sort of situation (where
the company VP says "finish this yesterday"), I'd expect that doing
just about any sort of security review is the first thing to be
dropped from the dev schedule. I wonder, though, if teams that have
already integrated (say) static analysis tools into their build cycle
might have a fighting chance at *not* dropping those checks during
this kind of "death march". Put another way, how does a team hold
onto its good practices (not just security reviews) when they're in
crisis mode? I'm sure that the answer varies a lot by team,
priorities, etc., but I'd welcome any comments, opinions, etc. from
any of you who have been in similar situations.
Cheers,
Ken
Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
