SEI Insights

DevOps Blog

Technical Guidelines and Practical Advice for DevOps

A DevOps a Day Keeps the Auditors Away (and Helps Organizations Stay in Compliance with Federal Regulations such as Sarbanes-Oxley)

Posted on by in

Aaron Volkmann
Senior Research Engineer
CERT Division

In response to several corporate scandals, such as Enron, Worldcom, and Tyco, in the early 2000s congress enacted the Sarbanes-Oxley (SOX) act. The SOX act requires publicly traded companies to maintain a series of internal controls to assure their financial information is being reported properly to investors. In an IT organization, one of the main tenets of SOX compliance is making sure no single employee can unilaterally deploy a software code change into production. DevOps automation techniques and technologies, such as continuous integration (CI), continuous delivery (CD), and infrastructure as code (IaC), can appear on the surface to throw a shop out of SOX compliance. This blog post examines how DevOps automation can help organizations not only stay compliant, but actually increase their compliance.

When faced with transitioning software change control processes from a traditional manual approach to a more automated process many organizations fear that checks and balances will be lost and the organization will fall out of SOX compliance. In a traditional scenario shown in Figure 1 below, a developer makes a change to a piece of software, the code goes through a peer review process, and the code is then built into a deployable bundle either manually or by a build system. The new version is then submitted to a change control process for deployment into production. A manager then approves the change to production, and a production services engineer deploys the change. While there are many ways to manage this process, there is no guarantee that the version of code that was looked at by code review is the same version of code that was deployed into production.

Figure 1 - When there is a manual build or handoff, we are not guaranteed what source code contributed to that build.

By using a CI server as illustrated in Figure 2 below, a software shop can log and track precisely what version of each source code file contributed to a particular version of the software. There can be pauses in the continuous deployment process that can allow human actors to inspect the change going through the pipeline into production, so that any unauthorized change cannot move forward.

Figure 2 - When we are using CI, the version of each source file can be logged and each build is tagged to assure that what we're deploying is what's been reviewed.

CI enables the precise versions of the source code files that were used to build the software to be logged and audited. The shop also gains the ability to centralize automated testing so every build of the software can be scanned for security flaws.

Another area where there may be resistance to automation is in server infrastructure provisioning. At the SEI, we have often seen resistance to IaC for server provisioning due to the need for an administrator to manually check the server build. When using IaC tools, such as Chef, Docker, or Puppet, we can treat our infrastructure provisioning scripts as verifiable, testable, trusted software artifacts that produce reliable, reproducible results. IaC gives us the opportunity to focus on developing and testing the provisioning scripts while allowing automation to carbon copy our tested server image, reducing the risk of human error.

Every organization--and even every technology or business area within an organization-- can have unique requirements and constraints. The level of automation that makes sense in a particular area may vary. By carefully putting the machinery in place to automate the movement of software through your pipeline, the ability to control, audit, and protect your organizational resources and ensure compliance with federal regulations like SOX can only increase.

Every two weeks, the SEI will publish a new blog post that offers technical guidelines and practical advice for DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar DevOps Security: Ignore It As Much As You Would Ignore Regular Security by Chris Taschner and Tim Palko, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.

About the Author