Mike Boberski <mike.bober...@gmail.com> wrote: > A toolkit example that comes to mind, to keep this email short: the > highly-matrixed environment (and actually also the smaller environment, now > that I think about it) where developers fly on and off projects.
I don't quite grok what you're saying here. The syntax looks like you're saying that matrix management is a tool or toolkit, which doesn't make sense to me. Your next paragraph: > Toolkits that enforce coding standards, and that are treated like any other > module of the application in terms of care and feeding, are the only things > that give security a fighting chance in environments like those. seems more like you're saying it's an environment conducive to bad security. Now that I can agree with, and would extend it to quality in general. A typical large-company matrix management environment seems very conducive instead to an attitude of "who gives a flying fig, all I have to do is make it work well enough to get the customer to sign off." A given worker is unlikely to ever work on that same project again, so the usual "write it well so that you can read it well later" doesn't apply, and there's little to no other reward to "write it well to be nice to the next poor sod who has to read it". All the more so in the typical Beltway Bandit (DC-speak for government contractors, especially defense) environment, where they'll probably be laid off in a few years anyway, so they won't be pestered by colleagues with questions, As for the tools, again absolutely agreed, though I'd place less emphasis on some of the pickier aspects of "coding standards" (like do block-opening braces get their own line, and do you put a space before the opening paren of a function call's argument list), and more on any automagically detectable security (or other types of quality) flaws. A couple years ago I was on a project where I was trying desperately to get the company to buy some kind of static analyzer, so we could use it as part of our CM process and have Subversion automagically reject changesets that introduced flaggable flaws. I did at least manage to set up the makefiles so that it would warn if any module had no unit tests, and fail to build if any unit tests failed.... On the other claw, I still don't grok what you mean by "treated like any other module of the application". Maybe it's just a matter of preferred phrasing, but "like any other *aspect*" is closer to at least my own thoughts on it. IOW, they usually ask "does it do the job right" (verification) and maybe "does it do the right job" (validation), but should also ask (for security) "does it Do The Right Thing (whatever that may be) in the face of all forseeable types of attacks", and (for quality) "diDTRT(wtmb)itfoafto *errors*" (including those forced by an attack!) and "is it maintainable". -Dave -- Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII -------------------------------------+ Play: davearonson.net | \/ Ribbon "Specialization is for insects." | Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net | Email<>Web _______________________________________________ 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. _______________________________________________