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.
_______________________________________________
