DevSecOps - It's Just a Name. Get Over it.

Apr 14, 2018 3:27:16 AM By John Willis John Willis - 780 x 390

For years I resisted the numerous attempts to change or modify the name “DevOps”. Different groups, mostly analysts, would make attempts to call it things like DevMarOps, DevNetBusOps, DevNetOpsSecBus and numerous other variations that would take many characters to express in this post. In fact, my personal favorite was the ill-fated “NoOps”.

At the time my general pushback was always to simply say - “It’s just a name. Get over it”. If you look at the history of DevOps, it was originally just a word that we used to drive a movement, although the original conflict was an attempt to describe the difference between developers and operations. Over time the name became a metaphor for local groups that needed to collaborate to deliver efficient services, not just for developers and operations.

In my mind, DevOps was an abstraction for a movement or if you like, a metaphor. More importantly it was a word that was working very well for the movement and in fact has worked well over the years. My general conclusion about names has always been if the name works then it’s a probably a good name. Therefore, my push back on attempts to rename DevOps would basically always fall back to, it’s just a name, get over it.

At the time I didn't want to see us repeat the early days of “cloud” discussions where we wasted way too much time trying to define and argue on the meaning of cloud. I would always flippantly try and end those silly arguments by saying a cloud is, “a visible mass of particles of condensed vapor (such as water or ice) suspended in the atmosphere of a planet. Now can we get on to the more constructive part of the discussion?" 

Fast forward to February 2017. I was speaking at the RSA Conference in San Francisco and I started seeing for the first time people talk about security as an interesting new way of integrating it into DevOps. They were unapologetically calling it DevSecOps. They were talking about this in a way that included security as a systems (end to end) approach to the traditional DevOps pipeline.

This was not the first time I had heard people talk about security and DevOps. I had known about the “Rugged” movement and the Rugged Manifesto but this seemed different. DevSecOps looked like a systems thinking approach.

The thing that most caught my eye was that this approach was clearly putting the ownership of security on the developer. I immediately thought back to Werner Vogels', the CTO of Amazon, statement of “You Build It, You Run It", back in 2006. However, what I was hearing this time was “You Build It, You Secure It”. This thing they were calling DevSecOps was describing a holistic and systems approach to security as part of the software delivery pipeline.

Figure 1 below shows an example of a DevSecOps reference architecture for a regulated environment. If you look closely at the figure, what you see is every step in the pipeline has a security solution described. With an even closer look, you might notice that the overlay of these security functions built into the pipeline inherently empower developers to own the security experience without them having to be security experts.

The security expertise, the meta, policy, and automation were being integrated into the pipeline by the security professionals. If you look back at the early days of DevOps this was an inflection point for developer and operation collaboration. Operations professionals put their knowledge meta, policy, and automation into the pipeline but the developers owned the delivery. Later on, we saw the same thing happen by including QA professionals in a similar way.


John Willis - Reference Architecture
           Figure 1 - DevSecOps in a Regulated Environment


A few weeks after the RSAC event I had an opportunity to visit Fannie Mae to observe their self-defined DevSecOps implementation. I met Chitra Elango, who ran AppSec at Fannie Mae. She was previously a developer who was now in charge of an AppSec team.

Again, if I go back to the early days of DevOps one of the things that fundamentally drove a lot of today's successful patterns and practices was this idea that early on, developers were driving and owning a lot of the operational patterns of their service. Basically, you had developers forced to own operations. The developer's natural tendencies were to treat operations as a development problem.

A lot of today's DevOps patterns of putting everything in source control, using configuration or infrastructure as code, and a lot of other of today's best DevOps practices were born out of this notion that a developer had to own the operationalization of their service.

What was interesting is that Chitra was doing this at Fannie Mae in a similar way with security. She was creating meta, policy, and automation into the software pipeline in a way that developers understood, could use, and accept security without having to be security experts. This notion of the developer owning security being clearly identified through this new name called DevSecOps, had me slowly becoming a believer.

The final notch on my 180 flip from resisting using the name DevSecOps and ultimately accepting the name was another meeting I had in early summer 2017. I was having lunch with an SVP who is a well known successful implementer of a large scale DevOps transformation. I asked him if he had heard of this new thing people were calling DevSecOps. I watched him lean in and his eyes lit up. His response was, "Please tell me more about this."

It was clear that this single word worked with a senior level IT professional. Since then I have had numerous similar conversations with the same results. The word DevSecOps works. I know in a perfect world we shouldn't have to call it DevSecOps and security should just be a natural part of the DevOps discussion. In fact, I still fundamentally believe that. Hopefully, someday we will have a world where we no longer have to use the world DevSecOps and security will be an inherent part of all service delivery discussions.

Until that day, and at this point, my general conclusion is that it’s just three new characters. More importantly, the name really differentiates the problem statement in a world where we as an industry are not doing a great job of information security. So now, ironically, my response is, "DevSecOps, It’s just a name. Get over it". Added to that, a lot of well-known organizations are using the name with great success. Who am I to argue?

If you have been tracking the activity of presentations called DevSecOps over the past year you will see there are hundreds of them. There is early evidence showing that more security professionals are showing up to DevSecOps events and presentations than there were to DevOps presentations.

I'll close with two points. One, the train has left the station.  Two, by all indications the name is working. Please, just get over it.