Security practitioners, implementers of  at Secure Development Life cycle (SDL), I urge you ask yourself the following question:

What am I doing to enable developers to innovate securely while they are designing and writing software?

The developer-centric manifesto attempts to crystalize this question into the follow precepts:

• Enable development teams to be creative and to innovate
• Ensure that developers have as much specificity as possible to “deliver security correctly”
• Build tools for developers to check for correctness
• Deeply participate such that security earns its “rightful place”
• “Prove the value” of security processes and tools

As I wrote in Core Software Security, developers, development teams must execute the SDL. Delivery of security is not executed by security people. Besides, there aren’t enough of us to scale to the tens of thousands of developers who design, code, and validate the millions of lines of code upon which we in the Internet Age depend.

We can let security’s dependence on developer execution lead to ever more restricting policies, standards, and mandates – but in doing so, we strangle the very innovation that is our collective lifeblood, organizational mandates, and upon which we have become dependent.

Or, we can

• Think like an attacker and a developer – thus providing the bridge between security and development
• Consider how to become part of existing work flows – thus avoiding creativity crushing interjections
• Become deeply engaged in the process, become supporters not stoppers
• Listen, always listen – sometimes, security might just be wrong

Let’s start a movement. You have an open invitation to contribute, refine, and practice developer-centric security.

cheers,

/brook