Developers are blissfully ignorant in knowing how insecure the code they write is. To overly simplify, an application security specialists job is to remove a developers bliss, their happiness. Happiness is not something a person will want to let go of willingly unless an equitable replacement is offered. If this is what it takes, no wonder application security is so challenging. Perhaps that is what the Rugged Software movement is all about. Replacing happiness with pride.
You know the drill -- an application security specialist sits down with a group of developers. The developers know anytime "security" comes around they’ll being asked to do more work. They must resist new tasks or revenue generating features will be placed on the back burner, product deadlines will slip, and upset their bosses. They’ll probably have to sit through training programs when they could be doing important work. And, for what?! To make sure nothing unexpected happens. The developers feel that this person, this ASS, is supposed to be the one responsible for “security” anyway, not them. They are doing someone else's job.
The ASS starts by going over the results of a recent penetration-test, which resulted in a number of reportedly high-risk security vulnerabilities. Right there, the first stage of Web security grief begins -- Denial. The developers are thinking there is no way their code is exposed to something called Cross-Site Scripting or SQL Injection. They ask for proof, to which the ASS happily complies with ready made proof-of-concept code. The document.cookie alert strings were confusing and unimpressive, but extracting raw database content was rather disconcerting. Next enter the Anger stage.
But, why all the fuss? Why don’t developers write secure code? Wait, strike that. “Why should developers write secure code?” There, that’s the question the application security industry needs to be answering, and answering convincingly. Secure code is NOT implicit, its explicit. Meaning, code cannot not be considered even remotely secure unless one specifically asks for it, in "the requirements," and then it must be developed smartly and tested thoroughly. If secure code isn’t explicitly asked for, you almost certainly won’t get it.
To further emphasize the point, if you read any software end-user licensing agreement (EULA) you’ll notice software makers directly state that there is no warranty and no guarantee regarding the performance of their product, which includes security, and at the same time they waive all liability should any errors occur. Therefore unless a new and profound legal precedence is set regarding the enforceability of these EULA provisions, secure code being explicit, rather than implicit, is unlikely to change. I’m not holding my breath.
What are the reasons why developers might want to develop, or learn to develop, "secure code?"
Perhaps these skills, with formal training and certification, may make them more attractive to employers, lead to promotions, bonuses, etc. I submit while this may happen occasionally, it is largely the exception than the rule. Instead, learning iPhone Development, HTML 5, Ruby, Python, Ajax, and Flash are far more financially rewarding. Don’t take my word for it, next time you attend a security conference, try to find an actual developer. It’ll be like playing Where’s Waldo. Clearly, they are not seeking out application security on their own.
OK, that’s the carrot, what about the stick?
If a website is hacked due to shoddy code -- or maybe just a vulnerability spotted by a customer, how often is the offending developer singled out and punished (written up, stern talking to, pay cut, job loss, etc.)? Rarely is my experience. Now, I’m not necessarily advocating these, just citing the facts. On the other hand, what a developer knows for certain is that if a product doesn’t ship on time, then there will be real consequences, which incentivized skipping a security stage in the SDL.
Maybe Adrian Lane has it right about what things really lead to secure code, “the techniques that promote peer pressure, manifesting itself through fear or pride, are the most effective drivers we have.” Through peer pressure, if a developer can feel proud about good work or embarrassed when not, then real change can be affected.