After my "Making Security Invisible by Becoming the Developer's Best Friends" post, Daniel posted a reply on his blog, and here are my comments on it (as posted on his blog):
Hi Daniel, Thanks for your comments, I think you make a good representation of the security camp that defends that "security is EVERY developer's business" which although well intended, unfortunately doesn't scale, and, in fact it doesn't work.
We will never achieve secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc...
Note that I didn't say that NOBODY should be responsible for an Application's security. Of course that there needs to be a small subset of the players involved that really cares and understands the security implications of what is being created.
The core idea is that developers should be using Frameworks, APIs and Languages that allow them to create secure applications by design (where security is there but is invisible to developers). And when they (the developers or architects) create a security vulnerability, at that moment (and only then), they should have visibility into what they created (i.e. the side effects) and be shown alternative ways to do the same thing in a secure way.
The other idea that I'm trying to push our (the application security) industry to adopt, is this concept: "One can't protect/analyze what is not understood, so application security teams create models (and tools) that help them to visualize and understand how the apps works, and since this 'application visualization metadata' is also VERY valuable to developers, let's work together (devs+qa+appsec) so that we can embed application security knowledge and workflows into the SDL"
For example, a very good and successfully example of making security 'invisible' for developers was the removal of 'buffer overflows' from C/C++ to .Net/Java (i.e. from unmanaged to managed code). THAT is how we make security (in this case Buffer Overflow protection) Invisible to developers
If you are looking for an analogy, "a chef cooking food" is probably the better one. Think of software developers that are cooking with a number of ingredients (i.e. APIs). Do you really expect that chef to be an expert on how ALL those ingredients (and tools he is using) were created and behave? It is impossible, the chef is focused on creating a meal. Fortunately the chef can be confident that some/all of his ingredients+tools will behave in a consistent and well documented way (which is something we don't have in the software world). I like the food analogy because, as with software, one bad ingredient is all it takes to ruin it.
