Using branching in source control to meet Sarbanes-Oxley requirements

Buck Hodges

February 9th, 20050 0

Someone posted this question recently in the newsgroups.

I have a question concerning promotion processes using Source Control. Due to requirements from Sarbanes-Oxley (SOX), we will need to have tight controls on source code that is being checked into UAT and Production such that it will pass an audit showing that is being tightly controlled by the properly authorized personell. This, of course, is different from the requirements in the normal day-to-day development process.

How will/should scenarios such as this be handled?

Doug Neumann, the Hatteras PM, responded with the following.

This is actually a really involved question and the answer ultimately depends on the tool you are using for source control. I’m a program manager for Team Foundation, so let me explain to you how we advocate users do this. Just in case you aren’t familiar with Team Foundation, you can read more at http://msdn.microsoft.com/vstudio/teamsystem.

With Team Foundation, we advocate that users model promotion levels with branches. Effectively, successive levels of promotion are handled in different branches of the source code. Developers typically do their work in the branch corresponding with the lowest promotion level. Changes are merged to higher levels of promotion when they are ready. Following each promotion, there may be a period of stabilization in the target branch when developers can check in to that branch directly in order to address bugs that weren’t caught before promotion. With Team Foundation, we even have the ability to cherry-pick specific bug fixes when merging between branches, so you don’t have to take unwanted changes from the source branch, even if they exist in the same file.

With Team Foundation, as with VSS, we create branches in the path space of the repository. To the user, the branch operation looks like a copy operation, but we maintain a lot of state about the relationship between files that makes it possible for us to handle merging changes in an intelligent fashion. One nice thing about path-space branching is that we can use normal file system ACLs to manager access rights. Where this comes into play with promotion modeling is that you can lock down each branch so that only authorized users are allowed to check in to them.

So to get the SOX compliance you’re looking for, we’d advise you to create at least 2 promotion levels. The first would be the dev branch where day to day work is performed. The second is the approved branch where approved changes are merged. You would then lock down that second branch so that only the authorized personnel could check into it. Because your source is in version control, you’ll always have the audit trail of who changed what to prove that only authorized people have been making changes in that branch.

[Update] Fixed formatting.