A primer on secure DevOps: Why DevSecOps matters

This post was written by Chris Romeo during his tenure at Security Journey.

I’ve been in the world of security for 20-plus years, I have seen trends come and go, but I’ve never seen anything as disruptive to the entire technology ecosystem as DevOps, often described as a methodology to build software fast and connect together development and operations.

Gone are the days of tossing a build over the wall and hoping that it works in production. Now development and operations are joined together as one in DevOps matrimony. DevOps accelerates the velocity with which products are deployed to customers. However, the catch with DevOps is that it moves fast, and security must move faster to keep up and make an impact.

I’ve spent the past few months on a journey trying to understand how security fits into the world of DevOps. What I’ve discovered is that most of the “experts” out there are just reiterating the statement that mixing DevOps with security is a good thing, without telling you how to actually do it. I’m scratching my own itch by diving deeply into the world of security with DevOps to figure out what this means and how to achieve it.

In the next two parts in this 3-part series, I’ll share my actionable findings on the processes and tools for security with DevOps, while leaving the principles of security to others.

Get your head in the game, app sec

In the good old days, products were built under the waterfall process. With waterfall, the release cycle was measured in years, so security process could take almost as long as it wanted. With the onset of agile development, things got speedier. Agile time is measured in weeks instead of years, and people stand up at meetings. The people can still implement the security process with agile, because the pace is just slow enough. Face it, DevOps is here to stay, and it is not getting any slower. Application security must speed up to keep pace with the speed of business. Security automation is king under DevOps.

DevOps is agile on steroids, and feels like it is, but without all the people. The people are still involved under DevOps, just in a different capacity. The people are not the process: The pipeline, the set of phases and tools that the code follows to reach deployment, defines the process. The phases include build, test, and deployment. Build automation includes the tools needed to grab the code and compile it. Test executes the automated test cases, while deployment drops the build into its final destination. The people monitor the process and respond to process failures.

Why all things continuous matters

A perspective on DevOps begins with all things continuous. Continuous Integration (CI) is the principle that code changes are checked into the source code repository in small batches. With each check in, the build system automatically checks out the latest version of code and goes through the build process. If the code that is checked in “breaks the build,” your changes get backed out and you get to figure out what caused the breakage.

‍Continuous delivery and deployment are principles for how the results of testing are reviewed, and the system automatically makes the decision as to what to do with the build. With continuous, a set of tests is run and, if the code passes, the build moves to a staging environment.

This is the point at which a human jumps into the process and manually makes the decision to push the new code into production. Continuous deployment is similar to delivery, except that testing is automated, as is the decision to push to production. There are no human beings in the build pipeline, so now you see why security must be automated, just like everything else in DevOps.

The secret to secure DevOps: It's in the code

There are two foundational principles you must embrace for the success of DevOps and security: security as code and infrastructure as code (IaC). Security as code refers to the building of security into the tools that exist in the DevOps pipeline. This means automation over manual processes. It means the use of static analysis tools that check the portions of code that have been changed, versus scanning the entire code base.

‍IaC defines the set of DevOps tools used to setup and update infrastructure components. Examples include Ansible, Chef, and Puppet. Gone are the days of system administrators spending time fixing problems on a system. With IaC, if a system has a problem, it is disintegrated and a new one (or two) are created to fill the spot.

Security is a culture thing and a people problem

In any process or methodology, people create the vulnerabilities. Luckily, DevOps is also a culture thing. Teams do DevOps and live and breathe the culture behind it. The hinge to success for DevOps security lies in changing the underlying DevOps culture to embrace security—with no exceptions. As with any other methodology, security must be built into DevOps.

Name confusion

There's massive confusion across the security community as to what to call security in DevOps. People call it DevSecOps, SecDevOps, DevOpsSec, and even rugged DevOps. How can we have so many different terms to describe the exact same thing?

This gives us a hint as to the disconnect that exists within security in DevOps. It’s still the wild west. There is no standard that defines security for DevOps, and the chances of a standard ever developing is small because different organizations are doing things their own way, and can’t even agree on a standard name. And while there is a standard for the secure development lifecycle (ISO/IEC 27034-1), few organizations are ever validated against it .

DevOps + security is goodness

Each of these terms refers to the same exact thing: the principles of how you apply security to DevOps. The term DevSecOps appears to be seizing the day and mind share across Twitter and at conferences. DevSecOps is the current “movement,” with its own website and a manifesto.

DevOps had the attention of the security community from almost the start—or at least from its infancy. DevOps + security is not easier than security for waterfall or agile, but it isn’t any more difficult. It is just different, and a heck of a lot faster.