The DevSecOps Manifesto

The bad guys don’t break in through the highly secure bank vault door; they attack the crumbly bricks and mortar of the vault walls. The same is true for application security. The vast majority of incidents don’t target security features like encryption, authentication, and authorization… the bank vault door. Rather, they target vulnerabilities in the “boring”, non-security parts of the code… the crumbly bricks and mortar of the vault walls.

The security function is still largely throw-it-over-the-wall at many organizations, but things are changing. There is growing awareness that you cannot prevent the vast majority of incidents with a bolt-on approach to security. You have to produce applications that are free of such vulnerabilities as they are being developed. In other words, you have to build security in.

A decade ago, I was part of an effort to create a new approach to cybersecurity called Build-Security-In. I was at Carnegie Mellon at the time and with Noopur Davis and Gary McGraw, we led the documenting of an approach (along with all the necessary content) that was not bolt-on but rather built in.

The initiative had some success, driven by the content and Gary’s consulting business, Cigital, but it never became the dominant paradigm for cybersecurity as we had hoped. The ops-oriented, bolt-on approach to cybersecurity is arguably as prevalent today as it was back then.

However, I believe the DevOps movement is new fertile soil from which the build-security-in concept can be reborn, renamed, and remade. The agile movement was all about breaking down the business analyst and quality assurance silos and getting the development team to take ownership of this work. The DevOps movement continued this trend by getting the development team to take responsibility for how their product behaves in production. It’s not nearly as far a leap from there to the development team also taking responsibility for security.

I believe the DevOps movement is a new fertile soil from which the build-security-in concept can be reborn, renamed, and remade.

So, with this post, I introduce the values of the DevSecOps Manifesto.

• Build security in more than bolt it on
• Rely on empowered development teams more than security specialists
• Implement features securely more than security features
• Use tools as feedback for learning more than end-of-phase stage gates
• Build on culture change more than policy enforcement

While there is value in the things listed on the right, there is more value in the things on the left.

Build security in more than bolt it on

Bolting a highly secure bank vault door onto any old room in a building is not going to be very secure. The bad guys will just bust through the walls. A truly secure application is designed from the beginning with just as much care put into the everyday functionality (the walls) as into the security features like encryption, authentication, and authorization (the door).

Rely on empowered development teams more than security specialists

When developers take responsibility for how their application behaves in production including security implications, they make fundamentally different prioritization decisions. When it’s ops’ problem, they can ignore a lot but a transformation occurs once the developers start getting called in on Saturday to respond to incidents. In their planning meeting on Monday, you can hear them saying, “I know the ops team has been asking for this for years but if we’d just had this extra little bit of information in the logs, I could have resolved the weekend’s incident in a fraction of the time.”

Implement features securely more than security features

When you mention the word “security” to a developer, he/she immediately thinks of security features like encryption, authentication, authorization, etc. This clause of the DevSecOps Manifesto is a reminder that you need to pay attention to the security of all of your code.

Use tools as feedback for learning more than end-of-phase stage gates

The best security testing tools find no more than 20–30% of the latent vulnerabilities in an application. If you use them to gate release to production, then you are still shipping with 70–80% of the vulnerabilities remaining. However, if you use the tool early as a feedback mechanism for developers, they learn how to write vulnerability-free software from that point forward. You’ll eventually end up producing radically more secure code as this learning spreads.

Build on culture change more than policy enforcement

The security apparatus thinks they only have one lever, better policies with more teeth. However, policies frequently get ignored and the policies-with-teeth approach encourages development teams to hide information and applications from that security apparatus. Their saving grace used to be that they could refuse to let the applications get into production without going through them, but as DevOps takes off, they no longer have that mechanism. Besides, if you insist upon a least common denominator policy, you’ll rarely get any better than that minimum. On the other hand, if you assume that development teams want to their best and that they just need help understanding how to do it, you create a completely different dynamic. Suddenly, the security leaders are helping rather than policing the development teams.

Credit: The Build-Security-In Manifesto and the Secure Development Lifecycle initiative principles at Comcast are inspirations for this DevSecOps Manifesto.