I’ve gone head-first into the world of DevOps, and, it’s been an amazing ride. I’ve had many of my own misconceptions blown away after learning the deep culture and philosophy behind DevOps. That and surrounding myself with people who actually implement the concepts of DevOps have been absolutely enlightening as well.

If you still need a primer check out my DevOps 101 article for a bit more detail. Otherwise, just remember that DevOps isn’t just two words combined together. DevOps is all of the following:

Today, we look at another extremely critical concept: Security as it is "injected" into the entire DevOps process. Before we go on, it’s important to note that there’s already some level of security testing and validation happening even in traditional DevOps practices. However, DevSecOps takes this concept and development operations much further.

“When an organization adopts true DevSecOps practices, you’ll start to see noticeable change within the code and the production applications,” stated Adam Auerbach, vice president and co-head of DevTestSecOps Practice at EPAM, in a recent interview. “Operations teams will move from service providers to real enablers. This means spending more time on critical things like automation to enable developers to have more control over standing up new environments and promoting code.”

Let’s pause here. Injecting security into DevOps can be a contextual practice. What are you developing? What’s the environment? Is it on premise or is it in the cloud? Are you dealing with sensitive data points? At a high level, you continue with your existing DevOps practice while introducing more concepts around "secure coding". This means incorporating both governance and security controls into your development operations. So, you are building around code availability, integrity, and confidence.

From there, you focus on three core areas that bring the security into the development operations process:

Code, service, and data classification. Understanding the type of data that’s being used. Classifying zones and access perimeters. Types of services being leveraged. This can include microservices and containers.

Assurance and automation. Integrating full SDLC controls and audits, continuous code and artifacts scanning, integrated and intrusive security testing. This can also include some manual code reviews.

Policy and process. Analyzing business and resiliency metrics, understanding policies and compliance (GRC), and working with architecture and coding guidelines and best practices.

Code security analysis. Leverage tools that help catch security issues early during development, identify weaknesses in code at exact line locations, testing of dependencies and services. This can also include the identification of integrated and very complex vulnerabilities.

All of that being said, many will argue that one of the most important pieces of DevSecOps is the process of automating security practices within DevOps. The idea is to maintain short and frequent development cycles, integrate security measures with minimal disruption to operations, keep up with innovative technologies like containers and microservices, and all the while foster closer collaboration between commonly isolated teams. However, as RedHat points out, this can be a tall order for any organization. All of these initiatives begin at the human level -- with the ins and outs of collaboration at your organization — but the facilitator of those human changes in a DevSecOps framework is automation.

However, you can’t get stuck on automation alone. In fact, one of the biggest mistakes when creating a DevSecOps practice is only looking at things like tools and automation to do the work for you. “DevSecOps is rooted in lean manufacturing and the theory of constraints,” states EPAM's Auerbach. “While automation will create efficiencies, most likely the biggest improvements can be made when automation is aligned to changes in organizational structure and cultural patterns. The other mistake is leaving security and performance testing out of the equation. While they are more challenging to solve, they will restrict you at some point in the process.”

This means incorporating things like penetration testing, infrastructure audits, and even development processes reviews. Many organizations will go as far as creating ‘pen teams’ analyzing how a target tolerates real attacks, how far an attacker can actually go, analyzes governance and control, and even looks at vulnerabilities within the infrastructure (VPN, WiFi connections, servers, networks, etc.).

Final thoughts and some DevSecOps best practices

As you look at your own practice, how are you involving security with your development process? As a chef in your own kitchen, it might be best to sometimes get an outside opinion. This means working with partners and organizations that are deeply involved in the DevSecOps practices field and those that can guide you in the right direction.

But, to leave you with some food for thought. Here are three things to think about when working to go from DevOps to DevSecOps: