I'm coming from the dark side, compliance, and am looking to gain better knowledge on DevOps & how to implement SOX controls on these processes. I'm hoping to build a good knowledge base in order to be able to recommend controls that will provide good assurance to the auditors while minimizing the impact on the actual operations. Also, so that when I meet with our internal DevOps teams, I can speak knowledgably on this.

I've done some research through ISACA whitepapers and various other sources:

Do you have any other suggestions on resources for building control frameworks for DevOps workflows? Or just DevOps in general?

3 Answers 3


what you are looking for is compliance and security for containers. There are companies that can do this out the box for you, and even though I'm not advocating for either you can see what they offer and use that as a template.

https://www.twistlock.com/platform/container-compliance/ https://www.aquasec.com/use-cases/container-auditing-compliance/

As a HIPAA security officer and DevOps manager, I've been reviewing these processes. The way to think of DevOps in your sense is probably the automation and culture of ship fast, fail early and fail often. The goal is to not disrupt the pipeline from security and compliance. Technically this looks like adding automated compliance checks in the pipeline before, during and after go live. As automation gets built, you can replace the automation with a manual process'. You can check out subjects like DevSecOps which is the same concept of ensuring compliance and probably closer to what you'll need to do.

here's an AWS diagram that might help https://aws.amazon.com/blogs/devops/implementing-devsecops-using-aws-codepipeline/


This has been referenced before in the links that you posted, so I will just add some specifics. Compliance testing can be thought of as a kind of QA or integration test, just like the other tests that your application(s) may have. In order to make it useful, a compliance test should fail the build in some meaningful way and guide the both developers and those responsible for operating them applications (hopefully part of the same team) what guideline is being infringed upon and how to regain compliance.

This also means that the compliance team needs to be able to write tests which make assertions on the deployed state of the application, preferably before it is deployed. If compliance is done after the deployment, you face the need to roll back or apply hotfixes.

I have found that Chef Inspec is a good tool for this job. It allows the compliance team to write profiles right off of best-practice documents. It can be kept in an independent repository, to be picked off the shelf if need be and applied to arbitrary workloads, or included in the same repository as the application. The former scenario allows global compliance testing across the entire org's suite of applications, while the latter helps to foster better collaboration between the developers and the security teams. Of course there are several options in-between.

A good example of how to write a compliance profile is available from Chef's training site.

Who should write the profiles depends on several factors, including proficiency, role and of course operational responsibility for the application. I have found that it is best when the profiles are written by a second set of eyes than those who write the deployment code. This is in the interest of keeping the audit process independent and unbiased.

As to where the compliance tests should be inserted in the CI/CD pipeline, this is often a matter of discussion, and depends on your delivery and deployment model. Others have mentioned the benefits of shifting left and this makes sense too in the DevSecOps world.

The key however is to test actual production states. Often people would use the staging environment for this, which would be a good idea if it is as close as possible to the production environment. The reality however is that certain aspects of compliance affect certain aspects of the application or environment, so it often makes more sense to inject the compliance testing into the various stages of CI/CD deployment similar to Figure 3.1 of :

Credit: https://www.oreilly.com/library/view/devopssec/9781491971413/ch03.html

Different tools come into play in different stages, and as you move down the delivery pipeline, the compliance envelope becomes increasingly complex. After deployment, you also don't have absolute certainty that the state has not diverged from what is in the codebase (people could log in and do things). At some point you should need to assert overally compliance of the application, and have it inclued as part of your monitoring system.

Having a set of compliance profiles executable as code and able to break the build makes it a bit easier to implement continuous improvement, give immediate feebdack to developers and operators, thereby shipping quality code faster. It also allows you to give concrete information to the auditors when they come knocking.


Have your read NIST 800 190? This document was co written by John morello who is the chief technology officer for twistlock, the company which does container security.

This NIST document helped me in understanding various attacks and what you can do. This might help you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.