If there is a process that requires minimal amounts of resources, saves money, and creates robust code, what will it take to increase adoption?
There were many answers, but they were all summed up succinctly in 4 options.
1. People are killed, and a lack of a secure coding methodology is directly to blame.
2. Companies go bankrupt, and a lack of a secure coding methodology is directly to blame.
3. A nuclear power plant has a catastrophic meltdown, and a lack of a secure coding methodology is directly to blame.
4. Compliance forces adoption.
I found these dramatic and macabre options disturbing, so I asked, "Is there no business case for secure coding? No cost saving analysis? No risk management prescription?" The consensus in the room was that my suggestions, while potentially possible, weren't going to persuade anybody to break from the status quo. Interestingly, the only factor that seemed to have complete persuasive power was Compliance. In this particular audience, the threat of fines was more of a motivating stick than I've ever seen previously.
In March 2010, Errata did a study asking people what reasons they had if they were not using a secure development lifecycle. By far the most popular answer was resource constraints. The 4 options above would imply that, at least according to security folks, the reason people do not adopt secure coding is because of some black and white risk assessment telling them they are not in danger. So, does this mean that the people in the study aren't being honest with themselves, or that security professionals are out of touch with the motives of the development shops?
3 comments:
well, i am a developer, so i would be part of the development community ben spoke of.
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).
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.
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).
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.
those top 4 things seem right to me as far as what kind of things are needed to overcome corporate inertia.
"People are killed" -- Love it!
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.
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.
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.
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!'...)
But far too often, devs are already cowed by business. Get more things done faster with better stability and features.
-LonerVamp
Post a Comment