Ask HN: How to Reconcile SOX Segregation of Duties with DevOps? | Hacker News Reader

Ask HN: How to Reconcile SOX Segregation of Duties with DevOps?

5 pointsyukinon4 comments

I'm in a Fortune 500 company that is under pressure to have proper segregation of duties between (1) who develops the code, (2) who approves the code, and (3) who deploys the code. In other words - SOX compliance, Change Approval Boards, etc..

But from reading books like Accelerate, and the DevOps Handbook, to become a high performing organization, the organization needs to enable and empower developers to create automated pipelines to get their changes into production safely but as fast as possible. So it would fall under a "you build it, you run it, you own it" etc..

I'm struggling to understand how it is possible that in a world of SOX compliance, how it is possible to practice CD effectively? Or how to reconcile the agile iterative processes and embracing failure if you have to deal with a Change Approval Board?

Has anyone had any experience with this in their org of how to reconcile these two concepts?

So a while back Gene Kim and a few others wrote up the Devops Audit Defense Kit, which talks about this exact scenario (There's a link in https://itrevolution.com/devops-audit-defense-toolkit/, then see page 12). Gene Kim also wrote the Phoenix Project, which is worth checking out, even if it feels outdated now

Essentially, SOX requires separation of duties, it doesn't specify what that separation of duties should look like. That separation of duties control is to reduce the risk than an engineer could deploy unauthorized code. The most common answer is to require an approval prior to deployment at the code review/pull request step, and having automated test suites doing the quality checks. If you do end up having a change approval board, then you want to get most code changes authorized as standard changes. Major product or feature launches would go through the change approval board, but minor features wouldn't need to go through it.

Our workflow that is sox compliant:

A single team can write and deploy their own services. We deploy multiple times per day as a team and hundreds of times per day as an organization.

The dev who wrote it is not the dev who approves it. We have automated test suites. Tests pass and someone on the team acts as quality assurance by verifying code and tests that were added. Anyone on the team can deploy at any time.

For auditing, all code and configuration changes are tracked in jira. If it changes the system, it gets a ticket. That ticket links to the pull request (and vise versa). The pull request cannot be merged until another person clicks approved. The PR branch is ran through the test suites and after merging, the main branch gets the same treatment. The artifacts for deployment are gated by passing master/main builds. If everything is green, then the CI/CD system allows us either to automatically roll out changes or gate them with another manual step of clicking a button. At the step right before something would be released, the approver (who didn’t write the code but is on the same team) comments on the ticket that it is verified and approved.

That’s pretty much it. From the trenches of a public company. And I got to be part of going through a dozen person start up to a several hundred person public company and go from everyone has root access with the same account and password to the world of access controls. A wild ride for sure :)

One way is to isolate the applications that actually need SOX compliance and have separation of duties for those. The ones that don't need to follow SOX compliance don't need those controls.

Dev 1 builds it, team code review (which is good for cross training too), Dev 2 hits the production deploy button.

Reply on news.ycombinator.com