So lets start this blog post off being super inflammatory, DevSecOps is broken and there is nothing that the security community can do to fix it.

Now that we have that out of the way… Here’s what I am actually trying to say. There is a fundamental problem with DevSecOps that it seems like a large part of the community is attempting to ignore.

The problem that we are facing is that fundamentally the problem with cybersecurity and application development isn’t the application, it’s the developer.

The solution that we are taking to solving this is like saying that we would like a gallon of milk so we drive to the middle of a cow pasture, stick our heads out the window and hope that a gallon of milk hits us in the hand. The root of the issue is that fundamentally isn’t how it works. The problem isn’t with the software, application, or the IoT device. The problem is at the development team and product manager level. The problem is that there is a lack of desire to do what it takes to make software development a success in this space. So we dump huge amounts of money into trying to solve the issue through the use of software to try to fix software. As an industry we have gotten to the point where we are adding layer upon layer trying to solve an issue without addressing the underlying problem.

I see this more and more being compounded as I talk through some of the conferences, the conversations can usually be broken down into a hand full of different categories:

• We implemented tools, they were so loud so the just turned it off.
• We implemented tools, then white listed everything so now we are secure…
• We implemented tools, then struggled to the point where struggle became our normal mode of operation.
• We implemented tools, and made it someone elses issue.

But the interesting point of all of this is that the tools aren’t the problem and they really aren’t the solution. The base of the issue is that most of the development teams that I have interacted with do not have a fundamental understanding of what security is beyond the need to watchout for sql injection and cross site scripting. The problem is that they don’t know the why. Education is something that has to break through he static of the daily standup, there needs to be real integration of security as part of the development community and the conversations that spring out of that need to permeate to higher levels.

Part of this conversation goes back to my own frustration that I experienced working as a developer. The main problem that I would run into as a developer was the fact that I worked in complicated spaces, spaces where nuance matters. When you are dealing with a complex piece of code simplifying it will only get you so far before you start to destroy some of the value that is offered. There is a reason that complex business rules exist. Optimizations help recover something that’s lost.

So how do we turn this around? I think that the Infosec Color Wheel is a good start, because it places security and developers on a level playing field. It shows where they exist as part of the security community. The problem with the standard red and blue, is that when security starts talking about patching servers and adding firewalls, the development team checks out. Those aren’t part of their world for the most part. But from personal experience if you start talking to developers and developer management about resilience and code based issues you have far more involvement from the teams. Like I said before this isn’t something that the security community can solve, we have to get to the development teams and get them to the table, talk about relevant application based security, and get them thinking about topics like Threat Modeling.