PCI Requirement 6.3.2 – Review Custom Code Prior to Release

by Randy Bartels / October 13th, 2017

How to Review Custom Code Prior to Release

PCI Requirement 6 requires your organization to go through many phases of development before production to ensure that software applications are being securely developed. PCI Requirement 6.3.1 requires that any testing data being used in the development and testing phases is removed before the application goes into production. PCI Requirement 6.3.2 adds another level of information security to the application by requiring you to review custom code prior to release or production. PCI Requirement 6.3.2 states, “Review custom code prior to release to production or customers in order to identify any potential coding vulnerability.”

This review process should include the following elements, according to PCI Requirement 6.3.2:

• Code changes are reviewed by someone other than the original code author and who is knowledgeable about code review techniques and secure coding practices. Just because someone can develop code doesn’t mean that they can review code, so it’s vital that whoever is responsible for code review is properly trained in how to do this. It’s also important that code reviews are performed by someone other than the developer of the code to allow for an objective review.
• Code reviews ensure code is developed according to secure coding guidelines.
• Appropriate corrections are implemented prior to release. If a security vulnerability is discovered and is not corrected, this puts your application at risk. The PCI DSS also points out, “Faulty code is far more difficult and expensive to address after it has been deployed or released into production environments.”
• Code review results are reviewed and approved by management prior to production. This isn’t suggesting that management performs the code review, but rather, management signs off that the necessary corrections have been made and the development process is working as it’s defined.

So now in your development process, you’ve developed code, it’s been developed against an SDLC that contains all of the necessary security attributes that we’d like to see, you’ve developed the application to meet PCI DSS requirements, and met all the logging and authentication requirements. Now, we want to make sure that you have someone within your organization that’s going to review that source code for any vulnerabilities.

There’s several things we need to look at here. First of all, the person that’s reviewing the source code for any vulnerabilities should be trained in how to do that. Understand that just because you’re developing does not necessarily mean that you can develop secure code, and just because you’re developing secure code does not necessarily mean you can do code review. One of the things that we as assessors like to do is look at what those processes are. It’s not really called out within the PCI DSS, but some of the things that I look for in your development process is how you comment your code. It’s important to us for you to understand that when somebody else is looking at that code or if you should not be the one developing code anymore (if the application developer doesn’t exist at your organization two to three years from now), what is it that this part of the application is doing? While it’s not required, something that I recommend you do is use good commenting within your application. Understand that the person reviewing the code should not be the same person that’s developing the code. You need to have a separate person doing that. The code review needs to be done by someone that’s competent to perform that activity. After the code has been reviewed, where there is a security vulnerability or an issue that’s discovered, it’s expected that your organization actually goes back and corrects that code.

Lastly, as part of this particular requirement, management is going to be signing off that all of the necessary corrections have been made. It’s not suggesting that management is doing the code review. The expectation, from an assessment perspective, is that management is signing off that all of your SDLC, processes, and the things we’ve defined and have been talking about, have been followed and that the process is working as it’s been defined.