Skip to main content

DevSecOps Roadmap: From Architecture to Automation

Copado DevSecOps - Blog Series

Originally published by New Context.

Every good DevSecOps roadmap starts with a strong foundation. A robust architecture that incorporates scalable, adaptable solutions will help firms create a platform that allows them to respond to emerging threats. One of the best possible ways to create this process is to look at traditional, successful business solutions of the past. The Lean business model is an ideal jumping-off point for establishing the DevSecOps framework. 

Lean works for information security because it’s a cycle of solutions repeated in perpetuity. As security issues are never static, it’s essential to have a dynamic response. A lean security approach is that solution. A DevSecOps roadmap should be based on the principles of observability, detection, delivery, and resolution to allow for continuous improvement. 

What Is Lean?

The Lean philosophy was initially born on the factory floors of an automotive manufacturer. Henry Ford developed the concept in 1913 to increase production by utilizing all his resources to their fullest extent. That included setting up the factory to allow one task to flow into another and eliminate unnecessary processes that wasted time. This initial method gave birth to a wide range of other business strategies to improve productivity and eliminate waste. 

Toyota was the next to switch their manufacturing methods to a lean model. However, one obstacle was the limitations when it came to variety. Ford’s production worked to create the same product over and over again. Toyota needed a method that allowed many different products. They managed this by focusing on the complete process rather than the individual products coming off the line. Updated machines permitted the creation of a variety of parts, applicable for multiple projects. Worker upskilling and continuous improvement perfected the process. All of this eventually constituted a basic cycle that set the standard going forward:

  1. Identify value. What value does the product have to the end-user? 
  2. Map the stream. What steps are needed to bring the project to completion? 
  3. Build flow.  How can the stream be improved? 
  4. Create pull. Allow the customer’s need to drive demand
  5. Perfect. Continuously review results and improve issues.

A quick review of the stages in this continuous cycle shows that it’s relatively easy to adapt the model to improve results in software and security. Leveraging it is almost entirely necessary to establish an automatic system capable of adapting to threats. This is the essence of DevSecOps.  

A DevSecOps Roadmap Based on Lean Security 

In the first half of 2020, we saw the number of records exposed due to cyber-attacks and breaches grow by 273% when compared to the first half of 2019. This shows us that hackers are growing more sophisticated and developing better tools to escape detection. A lean security cycle is built upon traditional methodologies while allowing companies to stay on top of these ever-evolving threats. This is a four-step process.

A DevSecOps Roadmap Based on Lean Security - Copado

#1: Observe

The right configuration management tools are essential for defining and enforcing proper behavior. Secrets management also builds in observability at an individual user level. Cyber threat intelligence allows companies to monitor threats and proactively prepare for them based on trends. 

In DevSecOps we look to achieve continuous monitoring of our pipelines and automation. There are many moving parts to any pipeline, making it important to separate signal from noise by focusing attention on the important aspects. Generally speaking, we’re concerned with  categories: what’s being built, what goes into the pipeline, what comes out of the pipeline, and what’s in production. We’ll break down those categories in a future article, but you can always contact us to discuss your immediate observability needs and blind spots.

#2: Detect

Proper log management allows firms to identify abnormal system behavior and respond to it as it happens. Immutable logs are vital here, as the activity is not traceable if its integrity is in question. A proper infrastructure allows for exception-based management, where leaders are informed of abnormal system behavior while regular activity stays in system logs. 

Detection is firmly coupled with observation, so you’ll find most tools in the space will pair one with the other. In order to ensure objectivity of your detection processes, it’s important that they are positioned adjacent to your systems. If the same systems run applications and their observers, it’s possible for a single attack to compromise the application and impede or prohibit awareness of the problem.

#3: Deliver 

Just as we use automation to build, test, and deploy our applications, DevSecOps strives to bring the same level of just-in-time convenience to the end points for the consumer. API management helps firms create and publish interfaces to respond to threats, enforce proper usage, and analyze the system to get a total view of its real-time status. Containerization separates running the application from the systems hosting it, which can eliminate bugs that interfere with function. 

#4: Resolve 

The resolve step is about the big picture of the program. During the delivery stage, firms respond to individual threats. In the resolve stage, they evaluate how those responses could apply to threats on the mass scale. Infrastructure as code and security as code are solutions that can be leveraged to respond to issues for the long term in a repeatable, scalable way. 

A DevSecOps roadmap based on lean principles ensures continuous improvement needed to respond to an ever-evolving list of threats. Solutions to small problems can roll out on a larger scale to automate future resolutions. Of course, all this starts on a secure framework like Copado’s Secure Compliant Data Platform. This builds in the functions that firms need to automate their security and stay several steps ahead of bad actors.