tag:blogger.com,1999:blog-37798047.post3126468772856250361..comments2024-01-16T05:48:33.523-05:00Comments on Errata Security: A discussion at SecTor on Rogue Secure DevelopmentDavid Maynorhttp://www.blogger.com/profile/09921229607193067441noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-37798047.post-27171963675088340002010-11-03T11:08:38.381-04:002010-11-03T11:08:38.381-04:00I am not a developer, but I work with several team...I am not a developer, but I work with several teams of them. I would agree with both Ben and Kurt up above, as well as the 4 items mentioned in you post.<br /><br />I'd also add a fifth: A customer is lost and lack of secure coding is to blame. This is a less dramatic version of #2.<br /><br />Really, any additional process, time, effort, or money *at all* is touchy when there is an absence of reason for it. If business doesn't buy into making things secure for their customers, then they will never buy into any additional resource use for the devs to do it securely.<br /><br />There are two ways that developers can influence a more secure dev cycle: they either come to the table already smart/experienced enough to create secure code, or they make the risk case to business such that business agrees with it. That does happen, sure, depending on how it is sold to the business and the business culture. But the key is the business seeing value (at all) in security. (At least beyond what they just expect between the lines...'of course we build it secure, our devs aren't dumb!'...)<br /><br />But far too often, devs are already cowed by business. Get more things done faster with better stability and features.<br /><br />-LonerVampUnknownhttps://www.blogger.com/profile/10949152012822050629noreply@blogger.comtag:blogger.com,1999:blog-37798047.post-86394476655302558782010-11-02T12:02:07.717-04:002010-11-02T12:02:07.717-04:00"People are killed" -- Love it!"People are killed" -- Love it!jduckhttps://www.blogger.com/profile/08277186239477077950noreply@blogger.comtag:blogger.com,1999:blog-37798047.post-42299966349239710592010-11-02T11:51:14.278-04:002010-11-02T11:51:14.278-04:00well, i am a developer, so i would be part of the ...well, i am a developer, so i would be part of the development community ben spoke of.<br /><br />i also happened to attend sector, but unfortunately i didn't make it to marisa's talk (there just aren't enough of me to go around to all the talks i was interested in).<br /><br />i agree with ben's notion that a lack of process holds back adoption of secure coding practices but i also agree that lack of resources do too. lack of resources hold back adoption of formal processes.<br /><br />it's difficult to make the case for formal processes when a dev shop starts out and only has 1 or 2 actual developers, so man-power resources can be issue. as the shop grows larger, so too do it's customer obligations and so the time and money requirements to shift over to formal processes are hard to justify (again, a resource issue).<br /><br />at the end of the day, corporate inertia (unfortunately dev shops are run by business people, not developers) keeps the status quo in place until the shop encounters a big enough force to get it moving towards change. the folks at the top have to buy into any plan that changes how development gets done because it changes how fast development can get done (formal processes don't lend themselves to cutting corners) and how much they can promise customers and prospective customers in the course of their aggressive sales tactics.<br /><br />those top 4 things seem right to me as far as what kind of things are needed to overcome corporate inertia.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.com