I think everyone is now familiar with the term DevOps, but what about DevSecOps?

While DevOps means different things to different people (perhaps due to marketing hype), I think the best one line summary I’ve read describes it as “giving a **** about your job” A more polite version would include sentiment about people working together more effectively.

This seemingly obvious cultural shift of teams breaking down walls and out of silos, combined with enabling tech such as Chef and Docker which drive automation, reuse and agility is adding value across IT departments globally.

So, is this the end of innovation in this space? Have we achieved code-delivery nirvana? Definitely not – we’ve in fact been missing a key component….

I was recently in Seattle with some gurus from AWS and we discussed a term somewhat less familiar to many I think: DevSecOps (also known as SecDevOps in some frowned upon circles).

What is DevSecOps?

The concept, as you may gather from the name, is somewhat similar to that of DevOps. With DevOps, the aim was to bring the Ops team into the Dev team so that it wasn’t just something to be tacked on to the end of a project. Chucking a release “over the fence” to Ops is now not something any sensible company does. The same applies with DevSecOps – we need to ensure security is no longer an afterthought for an isolated department to worry about, but integrated at all stages of a project and beyond.

How might you do this? Well, you’d engage your security folks in all project standups for starters – and get some automation setup asap. You might run security tests against code as it’s committed, pen test as part of your release process, embed tooling like the awesome AlertLogic offering into your platforms, and you’ll definitely log all of this in an auditable fashion.

To put things even more simply, you need to embed your security processes (or maybe create them in some instances!) into every step of your DevOps pipeline. The fundamental shift here is about not just considering security at every stage, but about it no longer being seen as something that slows down “real” work and productivity.

If you think about it honestly, the rush to get your product to market is often the primary driver so security can fall by the wayside. In reality, what is the number 1 worst thing that could happen with your lovely new product/application/website? A security breach. Let’s do something about it then. Let’s move from patching broken code, to protecting ourselves as the code is built, tested and delivered.

There are some more detailed examples of how to embed security into your life cycle all over the web. won’t repeat that again, but I will re-stress the point that you need to think about getting your security team involved in your DevOps processes now now. Your teams should be excited about this – the Security guys can learn about DevOps, the DevOps guys can learn about Security. If they’re not excited about that opportunity to learn, then question if you have the right team.

Ignoring all the terminology and hype, which you may or may not agree with, the message from me is the movement(s) discussed are about making people work more effectively towards a common goal – something we should all support.