> This is great, and something I have incorporated into our own cycle > previously, as carving out a spot on our team as the "security engineer" > didn't seem to work. But by creating a process for including security > testing, abuse cases, etc. I was able to incorporate security without a big > hit to the team. This sold management on the fact that it can be a simple > and seamless process and soon became adopted. The other half of it is that > you have to be the person on the team who always is thinking in terms of the > corner cases, the worst case scenarios, the one who aggravates the > development team the most.
The fact of proving to management that this isn't an expensive decision is something that I think will start to catch on. By making this part of the process if an issue is discovered you have already scoped out that additional time needed to research and address the issue. QA has always aggravated development this isn't new :) Regards, - Robert http://www.cgisecurity.com/ http://www.qasec.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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
