DevSecOps in Practice: How to Embed Security into the DevOps Lifecycle

You’ve heard of DevOps. And by now, you’ve probably also heard of DevSecOps, which extends DevOps principles into the realm of security. In DevSecOps, security breaks out of its “silo” and becomes a core part of the DevOps lifecycle.

That, at least, is the theory behind DevSecOps. What’s often more challenging for developers to figure out is how to apply DevSecOps in practice. Which tools and processes actually operationalize DevSecOps? Until you can answer that question, DevSecOps will be just another buzzword.

To help bridge the gap between theory and practice, let’s walk through what DevSecOps means from a practical perspective, and how to go about embedding it into your development workflows.

DevSecOps, defined

If you’re familiar with DevOps (which encourages collaboration between developers and IT operations engineers in order to speed application delivery), then the meaning of DevSecOps is easy enough to understand. DevSecOps adds security operations teams into the equation so that they can collaborate seamlessly with developers and IT engineers.

DevSecOps places a DevOps spin on basic security concepts. Just as DevOps encourages continuous delivery, DevSecOps is all about continuous security – meaning the constant and holistic management of security across the software development lifecycle. Similarly, DevSecOps encourages continuous improvement in the realm of security – meaning that no matter how secure you believe your environment is, you should always be looking for ways to improve your security posture even further.

DevSecOps in practice

These are all great ideas to talk about, and it’s easy to see why they are valuable. Security postures are indeed stronger when developers, IT engineers, and security engineers work together, rather than working in isolation. It’s much easier to optimize security when developers prioritize security with every line of code they write, and when IT engineers think about the security implications of every deployment they push out, rather than viewing security as something that someone else will handle down the line.

The big question for teams that want to embrace DevSecOps, though, is how to go about putting these ideas into practice. That’s where things can get tougher. There is no simple methodology that allows you to “do” DevSecOps. Nor is there a specific tool that you can deploy or a particular role that you can add to your team.

Instead, operationalizing DevSecOps means building holistic combinations of processes and tools that make it possible to integrate security into DevOps workflows. While the best approach to this will vary from team to team, the following are some general best practices for implementing DevSecOps.

Scanning early and often

One basic step toward implementing DevSecOps is to ensure that you perform security tests and audits at the beginning of the software delivery pipeline. You don’t want to wait until code is written and built to start testing it for flaws (and you certainly don’t want to let it get into production before testing it). Instead, you should be scanning code as it is written, by integrating security tooling directly into your IDEs if possible.

Importantly, security scanning should continue as code “flows” down the pipeline. You should scan your test builds and application release candidates before deployment. Security monitoring and auditing should also continue once code is in production.

Automation

Automation is a founding principle of DevOps, and it’s just as important to DevSecOps. Automation not only makes processes faster and more efficient, but also helps reduce friction between the different stakeholders in DevSecOps: developers, IT engineers, and security engineers.

While it may be theoretically possible to “do” DevSecOps without automated workflows in place, it will be virtually impossible to pull that off at scale in practice. In order to implement DevSecOps, you will need security tools that fully automate security scanning, auditing, and testing.

Multi-layered security testing

Because DevOps goes hand-in-hand with next-generation “cloud-native” technologies like containers and microservices, it’s likely that the applications you secure with DevSecOps will run in a scale-out, cloud-based environment that consists of a variety of layers: physical hardware, host operating systems, container runtimes, container registries, orchestration tooling, and more.

To secure all of these layers, you need multiple security tools and workflows. Scanning application code alone is not enough, because there may also be vulnerabilities in your orchestration tooling, your host operating system, or a variety of other places.

Scan dependencies

Along similar lines, many DevOps teams make heavy use of upstream open source code, third-party container images, and other tools that were developed externally. This makes it critical to scan any and all dependencies that your applications and environments rely on; even if you trust the source, there is no excuse for failing to perform your own security checks. Remember, if you import it, you own it.

Embrace security as code

A final essential practice for operationalizing DevSecOps is to adopt security as code. Security as code refers to the use of written policy files to automate security processes, as opposed to relying on manual checks. For example, DevSecOps teams can write rules that define pod security policies for their Kubernetes clusters, IAM rules for cloud environments, or access policies for code repositories.

Because security as code rules can be reused across software delivery pipelines, they promote repeatable, automated, and consistent security operations. They also provide a common set of rules and policies that all participants in DevSecOps processes can reference to determine the state of security and practices for applying it.

Conclusion

DevSecOps doubles down on the value of DevOps by making security processes just as automated and seamless as core software delivery practices. To make DevSecOps work in practice, however, your team must do more than merely talk about why it is important and how it relates conceptually to DevOps. You must embrace tools and practices that help to embed security into the software delivery pipeline in an automated, scalable manner. 

For more guidance, read the Secure Coding Best Practices Handbook.