Is using external repositories PCI-DSS compliant

Question

We are considering using BitBucket rather than hosting our Git repositories internally. Does anyone know if this breaks any rules of PCI compliance? I haven't been able to find much information on this.

Answer 1

I'm basing this off of the 3.0 version (https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) though I will admit that I might miss something (I'm most familiar with 2.0).

From the "highlights" pdf https://www.pcisecuritystandards.org/documents/DSS_and_PA-DSS_Change_Highlights.pdf there is something that catches my eye, though I can't find corresponding requirements in the DSS:

Enhanced requirements for system development processes including periodic security reviews, verifying integrity of source code, a versioning methodology, use of application threat-modeling techniques, and a formal authorization process before final release.

Though this is a proposed update I will note that the verification of integrity of the source code and versioning methodology are... interesting.

When working with an external host (or even an internal host), you likely need to validate that it was you that committed the code and not something else that someone did saying it was you. I'll point you to What are the advantages and disadvantages of cryptographically signing commits and tags in Git? which goes into this a bit and in particular http://mikegerwitz.com/papers/git-horror-story.html

In theory, you are already doing this. Working with external repositories this becomes even more critical that the source code can be verified. I'm not sure why you are migrating to an external tool for hosting the code, though you might wish to investigate a more "polished" internal tool such as Atlassian Stash

Section 6 is where development issues are at hand and appears to be mostly unchanged from 2.0. Mostly you need to verify that the code (6.3.2). Having an external hosting, this becomes even more critical.

There is nothing in the requirements that say where you need to or can't host the source code. The one thing to watch out for in this (that becomes many things) is the question of "is the server where the code is hosted a system component". If it is, then a number of requirements get raised as things you need to watch for and be able to demonstrate to an auditor that you are doing things correctly. These include 7.2, 8.1, 5.*. You may need to be able to ask the provider "are you installing security patches within 30 days of availability." Its not holding cardholder data, but... if they consider it a system component you've got some fun.

Depending on the familiarity with things of the auditor this could go many different ways (the ones familiar with it would want to verify that you're signing tags or commits and let it go at that, the ones that are tracking down every thing and can't tell a production source code hosting environment from a production cardholder data environment may want to see the audit access logs from BitBucket). And that's where things may get difficult.

My reading of the PCI DSS 3.0 and remote hosting of the code:

• You're good if you sign commits and/or tags and build only from these code lines.

You may need to alter how you work with git in order to do this (push branch and merge vs fork, tag, pull request -- I suspect the later would be considered to be better for explaining how it works to an auditor - that "verify integrity of source code and versioning methodology bit" in the proposed requirements)