In a blog post published today, Prevoty make a couple of key points:

“Application security is a people and economics issue. Developers are experts at building value — not security. Security teams are experts at security, but not code development. It is inefficient to ask developers to be security experts and vice versa. On top of that, our market suffers from a draught of both developers and security practitioners. How do we bridge that gap?”

Prevoty, of course, are trying to sell their product.

But that should not make us shy away from the painful truth of the problems that we face. Focusing tightly on vulnerability, in the absence of the context and impact that help us assess risk, is a continuing mistake. Which is at least partly, in my very humble opinion, why “Security teams are experts at security, but not code development”, as Prevoty put it.

If security people continue to scream about “vulnerabilities in your code”, developers will continue to experience that shouting as noise that must be blocked out in favor of helpful information and productive interchange. Which leads to the corollary truism, “Developers are experts at building value — not security.” If security people are seen as some sort of distracting noise, how will developers ever gain enough insight and skill to produce secure designs, which are then securely coded? Short answer: they haven’t and won’t unless security people change the way that they approach the problem.

I’ve proposed “developer-centric security” as a mindset, because, though of course secure design and secure implementation are a technical problem, ultimately, as Prevoty point out, people and economics must be attended to.

Software security people might consider working for a while as a developer. My 15 years (or so) as a developer, designer, lead designer have profoundly influenced the way that I execute software security, the way that I build software security programs. Further, developers will listen to me because I can speak their language and because I understand their problems. This is not just true for me, but for many of the hundreds of security architects whom I’ve taught, coached, and mentored over the years.

Software security is an interaction between the building of software (development community) and the practice of digital security (security practitioners). Acting as though you’re a SWAT team parachuting into a war zone will not help! You are likely to get active resistance. Don’t do it.

Don’t walk in and declare to a hard working development team that they have made a million errors; nobody likes their baby to be shredded. Remember that without developers’ careful execution, you’ve got what we have: mountains of exploitable conditions actively being exploited for every purpose imaginable, and then some. Ergo, the current situation.

cheers,

/brook