I am a Software Developer with a passion for Security, ALM, Agile, and Coding Practices. I have been working in .NET as a developer for over a decade, a network admin for years before that. I have worked for large companies and small ones, many that you would recognize some that you probably interact with. I am opinionated and deeply curious about the world. If you have a problem there is a good chance that I would be interested in hearing about it. More than that I want to help others, mostly because I believe that helping a single person raises the quality for everyone.

Developer security is a wholistic view of the applications security, it’s been something that I’ve been working on for several years. The problem with application security is that inherently it focuses on the product, the application. The alternative approach seems to be DevSecOps, where we make security part of the operations session, indeed shifting left from the application to the build process but really I think that this is still missing something. Since we are still focusing on the output of the process and not the process itself.

Inherently if we are looking to improve security we have to go to where the security issues get into code, the developer. To accomplish this most of the focus for the moving pattern is going to have to be placed on the education process and the management of the measuring where you are in the process. Education is pivotal because it is designed to change the mindset from our attackers are super elite hackers, to the majority of the attackers that we are seeing are people who simply have more time to dedicate to the focus of security (squirrels). In this way we have to figure out how to take all of the time that the attacker would focus towards attacking our site and focus it into the defense of the product that we building. This approach puts a heavy amount of thought and work into the developer, and what their workflow looks like. The goal of the process is to get the developer to focus in on what they are developing and ‘develop the attacker mindset’ (more on this in a moment).

Okay now on to the elephant in the room, developers aren’t attackers, and telling a developer to think like and attacker is like telling a developer to think like an elephant. Inherently they can’t do it, because it’s not their frame of reference. That’s okay, instead we want to shift their focus from thinking about security to thinking about resilience and safety, because on the Venn diagram of security those are the overlapping pieces that allow for a common mindset. Once we have that in place it’s a very small jump to the next level to make sure that we are accounting for the, ‘what can go wrong?'. Once we get to this mindset I think that we are in the sweet spot for moving forward.

So how is this going and what are some of the main things that we have been able to do to figure out where we are going and what we are doing as part of the process? Short answer is that so far things are going okay, it takes a long time to boil the ocean and there are a lot of tasks that we have to focus on as part of the process, there really isn’t anything that we can do to get around that. This is one of those ‘We do these things not because they are easy, but because they are hard’, it is the right thing to do.

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.