First of all, good luck.
It would be nice to know exactly what sections you are trying to satisfy so we could provide a more specific answer.
PCI is mostly concerned with separation of duties. (The second thing it is concerned with is the opinion of the auditor, but that is a separate matter). This is to say, developers should not have access to QA, QA should not have access to production, and so on and so on. The other consideration here is the software lifecycle that you use to promote code into production. We based ours off of the Microsoft SDLC, and I suggest you take a look at it.
Basically it follows something like this.
- Ticket comes in, get assigned to ba/dev for "requirements gathering"
- Security assessment is done. This is in the form of a questionnaire. Basically, does the code touch anything to do with card processing, etc etc.
- Based on security questionnaire results, specific security requirements are determined. This is to say, do you need a code review? (external of course). Etc
The separation of duties could look something like this.
- Code is made available in source control system for QA to checkout/build.
- QA "tests" code. This may include security testing as per questionnaire results.
- If required, 3rd party conducts code review. There are many 3rd parties to chose from
- QA passes documentation and built binaries to Production Support team
- Production support implements.
What you will find, is you will want to create PCI "zones". IE: High risk zone would be any code that touches/interacts with any system/process that deals with credit cards. Obviously any changes in this area will require a code review by a 3rd party (especially in the case where you don't control the development, etc). You would then have a secondary zone. Code changed in this area does not need the same rigor as code changed in the primary zone.
The above only really deals with a couple subsections of the PCI requirement. Really, you have to remember that PCI is more about standards and documenting those standards. Picking "best practices" and then showing that you comply to said best practice. Code reviews are a major win in this area.
The auditor in your case may be concerned with who has access to your source code, and how they gain access to it. Of course you cannot prevent someone from taking a screen shot or copying code by hand, but they may want to see some controls in place so someone can't just copy all the code to a USB and leave with it.
