Increasing SOX Compliance with Go

Implementing Go can help an IT organization increase their SOX compliance in four ways: 

1. Separation of duties, including limits on who can change the release process
2. Repeatable, documented release process
3. Eliminating extraneous builds
4. Verification of deployment artifacts

Separation of duties

One core principle of SOX is the separation of duties. As it applies to the software release process, this means ensuring that an individual who introduces a change to an application does not have the ability to deploy that change. Go enforces the separation of duties by separating build pipelines from deployment pipelines and allowing for different permissions (based on user or group) for each pipeline. This ensures that a developer can build an application but cannot release the application.

Furthermore, Go makes it possible to separate people who can use the process from people who can change the process. This makes it possible to enforce the official release process defined by the organization. In combination with the appropriate security measures on the deployment hardware, Go makes it impossible to release software in a manner that circumvents the sanctioned process.

Repeatable, documented process

Any SOX audit expects to find a repeatable, documented process for releasing any software that has a material impact on the business. The best way to achieve this goal is to replace manual, human-bound processes with scripted, automated processes. Manual processes suffer from the fact that humans will --intentionally or unintentionally-- deviate from the scripted process. In contrast, a process that is automated with Go is guaranteed to always be executed the exact same way every time. Additionally, Go is self-documenting, i.e., you can inspect the system to determine its configuration, so the release process documentation is never out of date. Go also tracks all changes to it’s configuration providing full visibility into the change history on your release process.

Eliminating extraneous builds

Every time you rebuild an application you introduce the risk of unintended changes. Obviously a good change management system can help reduce this risk, but the best way to reduce this risk is to minimize the number of times you rebuild your software. By implementing Go you can eliminate all extraneous builds, reducing the risk of introducing unintended changes.

Verification of deployment artifacts

For SOX compliance it is critically important to ensure that the software you build is the same software you deploy and that no changes have been introduced outside of the change control process. When Go sends a build artifact to the artifact repository it captures an MD5 checksum on each file. Later in the deployment process when Go fetches an artifact from the repository it validates the MD5 checksum to ensure that nobody has tampered with the artifact. If the artifact fails the checksum test the release fails and modified artifact is never deployed.