I just finished giving my new talk on the care and feeding of your developers in a security culture at DerbyCon, and I wanted to lay out some of the thoughts I presented in written words as well.
There is a solvable set of problems that are causing the divide between infosec and development. Almost all of it revolves around risk-averse infosec practitioners and risk-accepting developers seeing the same issue from different sides. For instance, infosec may see a feature like framability as a risk (due to UI Redress) where developers see it is a nice thing to offer users. Even when a security flaw is found, differences abound. Infosec view and reports the flaw as a vulnerability, wheras to developers it is just a defect. Severity is an issue; infosec inflates the severity of questionable vulnerabilities for legal or headline-grabbing reasons but developers just don't see the urgency. This language shift is exaserbated by the divergent personality types in infosec and development.
That's not all though. infosec fails to understand the basics of how a developer lives their life. The Software Development Lifecycle, or SDLC, be it a more traditional document-style or a newer agile-style process, rules the developer's day to day existence. Introduction of non-customer impacting bugs just doesn't have a slot in the process. Also, information security needs to understand their products' underlying platform, along with it's strengths and weaknesses.
So now that we have a grip on the problem, what do we do?
First, we automate. Some things in development just need to be autiomated. Testing, deployment, and confirmation, for instance, are three areas where good, well vetted automation will make it a whole lot easier to focus on the real hard things. Give dev and QA the tools to automate their jobs, and teach them to use them. When it comes time for application vulnerability analysis, put your static code analysis in the QA build, and let it focus on what it does best; same with the dynamic code analysis. Don't make someone have to push a button, just automate it.
But some things a human does well. You can't have a report run from an automated scanner and then jsut thriw it over the wall to the devs. Find the vulnerabilities that matter, focus on those, speak about them in terms of defects, and add them to bug tracking.
There are other things that humans do too, like pentesting and code review. This is the human side of static and dynamic analysis. It must be understood that a grasp on the platform you are testing, and the business case in question, makes all of the difference. If you take a report, especially from someone outside of the company with an imperfect understanding of your environment, the report will be of no use to the developers at all.
A third thing that humans do well is apply foresight. Use of tools like the OWASP Proactive Controls or Application Security Verification Standard will make the transition into a security culture so much easier because the developer can see a path to more secure software. They look ahead - way better for a dev than looking behind.
So what should you do today? Well, remember that devs like spicy food and expensive beer. Get your dev staff together over a few beers and don't just train - teach! A pattern that has worked well for me is to start with a 'test yourself' approach, then talk about secure coding, and then tie it down with security principles. Or start with the principles. Or start with the coding - just make sure to hit for the cycle. There are very few appsec specialists out there, so it behooves us all to make a few. Giving the developer the tools, and then teaching them how to use them, is more likely to make you an appsec person than just about anything.
We're in this fight together, folks, take it or leave it. The end goal is to make usable AND secure software, in a reasonable amount of time and under a reasonable budget. All of us do different things well, so if we agree to sit around the table and communicate, we can all get the job done. Remember that security isn't developer's first concern and shouldn't be. Give them the tools, teach them how to use them, and provide reasonable, valuable analysis of the apps, and you'll see things get better soon.