If DevOps combines development and IT operations, DevSecOps introduces a triangular relationship in which security plays a significant role. A good thing, but not worth the hype. DevSecOps sounds like a new goal to pursue: the illustrious successor of DevOps. But if taking security seriously is a new and hip goal, what are DevOps teams doing these days?

1. Breaking down silos

In retrospect, it sounds obvious: letting the developers who build applications get to know IT experts who maintain the app in production. And yet, DevOps was (and is) a revolutionary way of working. Companies in general and IT in particular have traditionally enjoyed working in silos. One department develops, the other rolls out and manages. Simple enough on paper, but a recipe for misunderstandings and inefficiency in practice. Combining the two in DevOps was a spectacularly good idea.

What are we to think of DevSecOps, then? In practice, IT security is still in a separate silo today. DevOps builds, IT security ensures that hackers do not break into the new app via a back door and so access the customer information of the whole company. But how? We all know that perimeter security has now earned its own display room in the Museum of IT. The entire IT infrastructure of a company has to be permeated by security.

2. Integrated security

In other words: if you build an application with a login portal, you have to make sure that the portal is not made of Swiss cheese, don’t you? Developers often want a quick and efficient leap from business logic to a functional application. In practice, security is rarely more than an afterthought, and certainly not a priority.

That is a DevOps problem. You can’t engage in continuous integration and continuous delivery without the necessary security checks. If those are not part of the DevOps workflow, then DevOps loses a lot of momentum. The initial idea was to get rid of these annoying silos. If security remains a silo, then DevOps has not achieved its goal.

3. Toward a pleonasm

A car has airbags, brakes and ABS. We refer to a car that has those functions simply as a car, not a ‘safe car’. The same must be true for DevOps. Security must be part of the DevOps workflow, so that the term DevSecOps becomes a pleonasm.

That is something you can apply in practice. As a developer, it is useful to have your finger on the pulse of security trends, but the right mindset is even more important. Security must be present in the CI/CD pipeline as a priority. Build with security at the back of your mind. Take into account the changing security needs and adaptability, so that your essential security elements can easily be updated when the need arises. Don’t just test for functionality and stability but at the same time also for security, giving it the same priority. Then roll out an application that is both secure and useful.

Don’t forget that today there are tools that can help you keep an eye on things. After the roll-out of the new code, you can check via automatic scans whether or not there are new known vulnerabilities in the application, so that you can adjust them right away. For containers, the open source tool Clair is a fine example.

So feel free to turn up your nose at DevSecOps as hype. Not because it is a bad idea, but because a good developer has long been concerned with security in a DevOps context.