Compliance as Code and Applied DevOps

DZone 's Guide to

Compliance as Code and Applied DevOps

Take a look at the three phases of compliance as code to integrate it into your DevOps lifecycle.

· DevOps Zone ·
Free Resource

Image title

Use complaince as code for faster deployments.

Compliance as code is an important form of applied DevOps. This idea resonates with enterprises, who often use DevOps to deploy applications that have a specific purpose. For example, banks use DevOps to deploy applications to help improve compliance and insurance companies want applications that they can derive insights from.

You may also enjoy:  Towards Compliance as Code

It is this use of DevOps to automate the delivery of purpose-driven applications that we call applied DevOps. As enterprises picked up velocity in software delivery with faster development and faster deployments, compliance was left behind and waiting too long to incorporate compliance can undo many of the benefits of a faster delivery process. Organizations have started introducing security and compliance earlier in the software delivery process, making it part of the story from the very beginning rather than bolting it on as an afterthought at great cost.

How We Do It

We start by proving that software assets are secure during each step of the software development cycle and throughout the end-to-end release process. By having the entire team be a part of the process that defines the policies and rules for getting software to production, everyone contributes to the DevOps process of defining and codifying the entire release process. By codifying, you can standardize your rules and policies and share them across different applications and teams.

We have found that without compliance as code, your compliance backlog grows rapidly as your applications start getting deployed more efficiently with DevOps practices. You will also want to burn down that compliance backlog and keep it from happening more in the future by integrating DevOps compliance as code into your release process.

With so many vulnerabilities, such as malware, which may pose threats during different phases of the software delivery cycle, you need to build compliance as code in all phases. Compliance as code also gives security experts the ability to build what they need into the release process upfront based on role-based access controls. These controls limit the potential risk at each phase of the release process.

Compliance as code allows organizations to capture data, produce reports, and have an audit trail of all security and compliance events that happened during the software delivery process. In Lean terms, you are creating Standard Work for inserting compliance into your deployment pipeline.

The Three Phases

One of the things that we help organizations understand is that being successful at DevOps and Compliance as Code is a multi-step process.   

Phase One

Phase One is to simplify existing processes by removing waste and rework. By just doing the tasks that are essential for that process, you will have made compliance easier. You can then start to automate the things that you're doing today to become more efficient. Ad-hoc scripting your release pipelines will only make things harder when you try to scale your process.

Another way that we've found many organizations fall into traps, especially large enterprises, is that they start with their rockstars and key teams, and build out these great pipelines from there. Then, with a simple click of a button, everything builds and deploys perfectly because…well, they are rockstars, right? They can do that. Once you try to scale to other teams, it breaks because no other teams have that same knowledge. So you really need to simplify and then you can start to automate the process as Phase One.

Phase Two

Phase Two is what we call hardening that process. Here is where we introduce Compliance as Code.  We need to introduce security and quality into the deployment process earlier and earlier to make sure that you're meeting all your compliance and audit requirements. You do this by ensuring that every check-in has static analysis and linting performed on it. Each build can also run dynamic application security testing. Web applications can run pre-built GUI tests to ensure compliance.

These are just a few examples of how each step of the process should be validated for the expected result or behavior. Phase Two hardening may vary from app to app, but enforcing compliance is critical for meeting audit and business needs.

Phase Three

Phase Three, which is really the best outcome, is where you have a fully automated process covering security, QA, testing, and all the different components in the software delivery process. Phase Three represents the next level of DevOps maturity and is where Compliance as Code really gets going. By automating the end-to-end DevOps toolchain, you can now collect and unify your DevOps data across all of your tools. Only a select few large organizations are in Phase Three now. These organizations are just beginning to learn how leveraging this data along with predictive analysis and machine learning can bring new insights and improvements to the DevOps process.

We're striving to help customers get to that end game. XebiaLabs recently introduced a new concept that we feel compliments Compliance as Code very well. It is called the software chain of custody. Software chain of custody is tracking all the control points that can affect your software throughout the entire end-to-end software delivery process. You don't have to go through days, weeks, or months of meetings and spreadsheets and collecting of evidence to try to satisfy an audit or compliance request. If you build it in with Compliance as Code, creating your software chain of custody, you can generate these reports when you need them. Developers get back valuable time to innovate, release managers and directors can be assured their software is safe, and auditors get the info they need. 


Compliance as Code helps you understand which compliance checks are run at each stage in your entire software delivery process. Building in Compliance as Code from the beginning of the development process helps both risk and development teams do their jobs faster, so that delays don’t happen at the end. It brings teams together upfront to define policies and rules. It allows teams to build standards and templates, which can be shared across the organization allowing DevOps to scale.

Application compliance is critical to business success. The alternative is just too costly for organizations. We know that today all businesses are software companies, and we're seeing that the only way that they can differentiate themselves is by delivering new features faster and building compliance into the cycle. Compliance as Code is not an option, but a requirement in today’s fast-paced business world.

Further Reading

DevOps vs. Compliance: A Guide to Having It All

Continuous Compliance and DevOps

cicd, compliance, compliance as code, compliant devops, devops, devsecops, lean, secure apps, waste

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}