What restrictions, if any, exist over source code repository management under PCI-DSS?

Question

What restrictions, if any, exist over source code repository management under PCI-DSS?

The company I work at wants to develop a credit card processing service for clients hosted under our network. At the moment we're using SVN for version control. It's secured so that only the developers who need checkout/commit access have it. Meanwhile I was planning on moving from SVN to HG. However, the security team has expressed reservations about using a distributed SCM tool due to lack of access control on remote clones. Specifically, they claim this would violate PCI-DSS compliance. Does it?

Answer 1

First, I'll just say that I'm basing my answer on a quick read of PCI-DSS 2.0, specifically Requirement 6.

I don't see why using Mercurial would be a problem if you use it in a way comparable to how you used Subversion. Here are some reasons why I think this:

• Presumably you do not store customer data in your repository (only code which operates on that data).
• PCI-DSS often uses words like "standard industry practices" or the like. Mercurial is by now a quite common VCS, which is helpful.
• It seems to be the ability to push changesets that needs to be locked down. And specifically, the ability to push to a "canonical" clone of your repositories. Just because Mercurial has these "remote clones" and developers could push random (even malicious) changes into those clones, does not mean that those changes will (or should) end up in your production system.
• With Subversion, it sounds like you had permissions in place to restrict checkins to a subset of your developers (or maybe even just one "gatekeeper"?).
• With Mercurial you can set it up to use SSH on the central (canonical, "production" repository. Give each developer their own SSH credentials for this (this is required by PCI-DSS--no sharing passwords!). In this case you can set permissions on the filesystem where the central repo is hosted, and only give write access in the Mercurial directories to specific users.
• With Mercurial you can instead (or also) publish your central repo via HTTP. In this case you can use Apache (or another web server) to do the authentication and authorization.
• You could also disallow writes to the central repo entirely, and decree that all source changes must be sent through one or two specific people, who will review the changes before pulling (or applying) them.

So I think there is plenty of scope to be PCI-DSS compliant while using a DVCS like Mercurial. Everything above would apply equally to Git.

Answer 2

As others have said, this is one to raise with your QSA if you need more advice. That said, PCI is about having the right controls in place rather than mandating one technology over another.

When developing, you need to think about:

• Segregation of duties between test/dev and production systems
• Being able to detect changes, where they originated, when and by whom
• Having change control procedures when pushing to live

Nothing in this should stop you using the repository manager of your choice