The "just get the bloody thing to work" is usually an attitude foisted on developers by the business side.
I work in an internal application security function for a large enterprise and i'm yet to meet a developer who wasn't concerned about security. Developer education is very important and we have a lot of it available for out developers, some of it even compulsory. However, unless there is the will of the business behind it, developer concerns are oft pushed aside in the interest of expediency. I find the business side usually does have a genuine interest in "security" and "quality", however they are concepts that remain largely unquantifiable, and in the case of security you only need to mess up once to end up with a nasty situation. It's can be a tough sell getting time to focus on these things, given they can be so vague. In the case of my organisation, business side support comes from both internal advocacy of security practises by our function and externally imposed legal requirements. Mostly the latter ;) Filtering inputs is NOT hard, and most developers are getting better at things like that. However, the problems of application security go beyond the developer level, and it's important not to lose sight of that fact. If there were an easy solution everything would already be perfectly secure. Pete On Wed, Aug 26, 2009 at 12:26 AM, Goertzel, Karen [USA]<goertzel_ka...@bah.com> wrote: > For consistency's sake, I hope you agree that if security is an > intermediate-to-advanced concept in software development, then all the other > "-ilities" ("goodness" properties, if you will), such as quality, > reliability, usability, safety, etc. that go beyond "just get the bloody > thing to work" are also intermediate-to-advanced concepts. > > In other words, teach the "goodness" properties to developers only after > they've inculcated all the bad habits they possibly can, and then, when they > are out in the marketplace and never again incentivised to actually unlearn > those bad habits, TRY desperately to change their minds using nothing but > F.U.D. and various other psychological means of dubious effectiveness. > > Great strategy! Our hacker friends will love it. > > Karen Mercedes Goertzel, CISSP > Associate > 703.698.7454 > goertzel_ka...@bah.com > ________________________________________ > From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf > Of Benjamin Tomhave [list-s...@secureconsulting.net] > Sent: Monday, August 24, 2009 8:35 PM > To: sc-l@securecoding.org > Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? > > Two quick comments in catching up on the thread... > > First, security in the software development concept is at least an > intermediate concept, if not advanced.... > _______________________________________________ > 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. > _______________________________________________ > _______________________________________________ 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. _______________________________________________