Secure at every step: A guide to DevSecOps, shifting left, and GitOps

DevSecOps, shifting left, and GitOps: you’ve probably heard all of these terms recently, but you might not be sure about what they mean. The reality is that these practices share a lot of the same principles—to reduce the time developers need to spend on security, while achieving better outcomes. And who doesn’t want that? Let’s clear up some confusion and deconstruct what these terms mean, and how they apply to your security and development teams.

What is DevSecOps: Applying DevOps principles to security

DevOps is an increasingly popular trend in recent years—a shift that makes developers more accountable for operational issues. The idea is that when a system goes down, it’s everyone’s responsibility to fix it. And so is preventing outages to begin with. Rather than separating development and operations, DevOps posits that the responsibility for these functions is joint, between all parties that write, ship, and manage that code.

The same mindset shift you’ve seen in the industry generally with a move towards DevOps has also been felt within security specifically. It’s commonly called DevSecOps. This is about making all parties who are part of the application development lifecycle accountable for the security of the application, just as they are accountable for operations and supportability.

So what’s the difference between DevOps and DevSecOps? In the first, everyone becomes accountable for outages, even if they don’t manage the infrastructure. In the second, everyone becomes accountable for vulnerabilities, even if they didn’t write the software. Just like the business goal of DevOps is fewer outages, the business goal of DevSecOps is no data loss (which is also aided by fewer outages—availability is part of the CIA triad, after all). DevSecOps addresses the concern of development teams not satisfactorily addressing security requirements.

Not everyone likes the term DevSecOps, though. And it’s not just because the order is confusing, but because it makes security seem special. The reality is every function should be tightly integrated this way, at every step in the development process. Continuous security draws a parallel to continuous integration and continuous delivery: you should continuously integrate security into your development process as well.

Since this is a mindset shift, there’s no canonical list of practices, but rather the principal change is to apply security practices earlier in the development lifecycle.

Practicing DevSecOps: Shifting left allows development teams to implement controls earlier, including security controls

In practice, to hold teams accountable for what they develop, processes need to shift left to earlier in the development lifecycle, where development teams are. By moving steps like testing, including security testing, from a final gate at deployment time to an earlier step, fewer mistakes are made, and developers can move more quickly.

The principles of shifting left also apply to security, not only to operations. It’s critical to prevent breaches before they can affect users, and to move quickly to address newly discovered security vulnerabilities and fix them. Instead of security acting as a gate, integrating it into every step of the development lifecycle allows your development team to catch issues earlier. A developer-centric approach means they can stay in context and respond to issues as they code, not days later at deployment, or months later from a penetration test report.

Shifting left is a process change, but it isn’t a single control or specific tool—it’s about making all of security more developer-centric, and giving developers security feedback where they are. In practice, developers work with code and in Git, so as a result, we’re seeing more security controls being applied in Git.

Managing security controls consistently: GitOps uses Git as a source of truth for your environment

GitOps capitalizes (literally) on the trend of thinking about everything in your environment as code. Sure, GitOps is infrastructure as code. But it’s also configuration as code, policy as code, and anything else you can think of as code. (Well, not anything. Don’t keep secrets in code. You thought your secrets were safe? You were wrong.)

In contrast to DevSecOps and shifting left, which are mindset and process changes, GitOps is more prescriptive in terms of its implementation. GitOps is the system of using Git as a source of truth for your environment, and using properties of Git like history and review tools to manage how you make changes to that source of truth. 

It’s also what you built on top of your code, to make deployments as automated and error-free as possible. With GitOps, you can push a change to code and review the change as part of your Git workflow, and then use automation to do all the hard stuff of deploying, monitoring, and adjusting live changes in production.

GitOps is the system that best supports the ideals laid out in DevOps, and specifically in DevSecOps. It allows you to separate deployments from development, so you can deploy as often as you want. We know from the DORA State of DevOps reports that developers can move faster when they have version control, continuous integration, test automation, and other tooling that’s available with Git. 

In DevOps, this matters specifically with mean time to recovery (MTTR) to respond after an outage. In DevSecOps, this matters with mean time to remediate (conveniently, also MTTR). Having version control means you know what’s in your environment: you know if you need to upgrade, and if you’re susceptible to a vulnerability. Having sufficient testing in place means you can very quickly deploy a fix, like a patch, knowing it won’t break your infrastructure.

By using Git, you have a single source of truth for your infrastructure, configurations, and applications. And by extension, a single process to make changes. You can implement necessary controls and gates on this process to make sure you meet any security needs you have for your development pipeline, and having a consistent development process allows you to shift left by verifying security requirements earlier, at code (or config) check-in, or build time, not just deployment time.

To summarize, DevSecOps is the mindset shift to recognize and continuously apply security practices as part of the development lifecycle, with responsibilities shared across teams. This is frequently accompanied by shifting security testing left to earlier in the lifecycle as part of development. This keeps security—and developers—in the flow and in context, allowing security issues to be addressed earlier. And, by using Git as a source of truth for your environment, you can more easily apply these principles not only to your code, but also to everything around your code, like your configurations. There’s no one way to apply these concepts, but rather, they are acknowledgement that security is an increasingly important and integral part of your development workflow today.

By empowering all developers to take responsibility for security, performing security testing earlier in your development lifecycle, and using Git, you can help your development teams find and remediate security issues faster. In future blog posts, we’ll also break down what this means for your first and third-party code.

Looking for more easy ways to keep your code secure? Stay tuned for upcoming posts in this series or check out our security ebook.

Written by

Maya Kaczorowski

@mayakacz