Where are you on the DevSecOps maturity model continuum?

Applications are organizations’ lifeblood, and the DevOps model enables companies to develop, deploy, run, and update products and services quickly. But if your code is not secure, it’s going to get thrown back over the wall by the security team, negating any efficiencies gained by DevOps in the first place. This is where DevSecOps comes in.

Taking full advantage of DevOps means integrating security into the full lifecycle of your apps. But true DevSecOps requires much more than just doing the real-life equivalent of sticking “sec” between “dev” and “ops.” Rather, taking full advantage of the agility and responsiveness of the DevOps approach requires a purposeful transition through a maturity model—including a frank assessment of the organization’s place along that lifecycle continuum.

Here's how to know where you are on that continuum, and what should come next. 

Beginner: Manual and siloed

At the beginner stage of the DevSecOps maturity model, you’re doing everything manually—from developing the applications to deploying and maintaining the applications to creating the systems that run your applications. (This is true for most organizations right now). This means that everything has to be just right, since most of the applications and systems are snowflakes that can’t easily be updated or patched. Also, though you may have moved some non-business-critical applications to public cloud platforms such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform, and you may be using SaaS platforms such as Office 365, you are mostly running physical and virtual machines in a traditional data center.

In addition, your teams are likely siloed. The development team, the operations team, and the security team each does its own thing, often resulting in duplication of effort, with little to no consistency, collaboration, or cross training.

It might seem impossible to move from where you are to DevOps, much less DevSecOps. The organization can get there from here, but it will require nothing less than a shift in culture and tightly integrated cross collaboration.

One of the most important requirements is top-down support, in the form of both resources and, perhaps more importantly, influence. The bottom-up approach is usually not enough to drive the culture changes required for successful DevSecOps. Members of the dev, sec, and ops teams have been doing their jobs in the same way for a long time, and DevSecOps likely represents a significant change in all those processes. Without a high level of executive championing, it will be difficult to get people to change their ways.

To get everyone on board, top management should make clear its support for DevSecOps, its commitment to implementing DevSecOps, and the model’s value to the company. Champions within the dev, sec, and ops teams, meanwhile, are key to creating positive buzz (especially through proofs of concept) and engendering bottom-up support, cross collaboration, cross training, and engagement.

Intermediate: Chain, chain, chain … chain of tools, and automation

To move from the beginner stage to the intermediate stage, you have to move beyond doing everything manually and toward creating an application assembly line—with code coming in on one end and secure products and services going out on the other.

The development, operations, and security teams must all work together to determine the requirements that need to be in place to get from code to secure code on top of a dynamic, scalable, and hardened infrastructure, while at the same time determining which steps along the way can be automated—immediately.

The goal should be to automate everything by implementing everything as code—infrastructure as code, security as code, and compliance as code. Start with low-hanging fruit, such as automating and codifying configuration management, and work out from there. By having everything as code, you will have repeatability, consistency, and auditability, and you will make it easier for teams across the organization to collaborate, since everything is codified and behind a change-control system.

Once you have automated several things on the apps, security, and ops side, it’s time to standarize on a tool chain such as Jenkins, Tekton, or GitLab. In this so-called GitOps model, everything is codified, to the point that you can completely build up a system or application from scratch with code and have it integrated with security tooling in an automated app-assembly line.

This should be the goal, whether you are running applications in physical systems, virtual machines, public cloud, or containers and Kubernetes in a hybrid cloud environment. The closer you can get to the latter model, the easier it will be to create and deploy apps at scale in a DevSecOps model.

Advanced: Doing DevSecOps at scale with automation and cloud technologies

At the advanced stage, you are looking to do DevSecOps at scale by improving processes—such as configuration management, patch management, and compliance—by scaling your existing automation and using cloud technologies such as containers, Kubernetes, and public cloud services.

Containers, which were built to run in any environment, are a great tool for making DevSecOps easier by allowing you to do DevSecOps at scale with faster deployment and scaling of applications. Containers also improve security and enable DevSecOps because they are immutable and therefore are never patched in runtime. They are simply replaced with new versions—shifting much of the security controls to the “left,” or upstream, in the development lifecycle. Kubernetes provides a unified approach for container orchestration and eliminates many of the manual provisioning and other time-consuming tasks of enterprise IT operations. The declarative syntax used to define the deployment state of Kubernetes-deployed container clusters greatly simplifies the management of the delivery and deployment of containerized applications.

With cloud technologies, such as containers and Kubernetes, the DevSecOps assembly line becomes faster and more efficient, which gives organizations the ability to deploy apps at scale in a dynamic environment securely.

Expert: Netflix and Google goals

Truth be told, you may never reach the expert stage of the DevSecOps maturity model—not unless your organization ranks among the Netflixes and Googles of the world.

For these companies and their ilk, everything is API-first in a cloud-native world. They have fully automated deployment pipelines, continuous delivery practices, shorter development cycles, increased deployment frequency where they are deploying code every 10 seconds on average, and faster time to market. These organizations have a commitment to a culture of cross collaboration, cross training, and innovation. They are leveraging cutting-edge technology models such as serverless and microservices, and taking advantage of artificial intelligence and machine learning to make better decisions about how to evolve infrastructure, security, and application development—all while deploying code hundreds if not thousands of times each day on top of a dynamic and hardened infrastructure.

Indeed, most enterprises will not have the scale issues of a Google or a Netflix. But even if your organization doesn’t breathe this rarefied air, it can improve and expand its DevSecOps processes and practices by putting Google’s and Netflix’s lessons learned and best practices into relative context.

Take it one step at a time

Moving through the DevSecOps continuum is not easy, but it is worth it. Every step your organization takes is a step closer to continuous development and deployment of applications with security built in early in the application lifecycle, designed to meet customer demand and business goals without sacrificing security.