PCI Requirement 6.3.2 says that custom code should be reviewed prior to release. As the PCI DSS points out, “Faulty code is far more difficult and expensive to address after it has been deployed or released into production environments.” To identity potential coding vulnerabilities, the code review process should include the following steps: 

Separation of duties plays a critical role in code review. If the goal of code review is to expose and identify unknown vulnerabilities prior to production, then it’s an insufficient, redundant process to have the originating code author perform the review. Code review must be performed by someone other than the originating code author, who can come into the process with an objective view. Additionally, just because someone can develop code doesn’t mean that they can review code. It’s vital that whoever is responsible for code review is properly trained in how to do this. To comply with PCI Requirement 6.3.2 in an AWS environment, you need to have someone (internal or a third party) perform code review who has knowledge and training in AWS security as well as secure coding methodologies. 

For more information, visit the OWASP Code Review Guide. 

The PCI Requirement 6.3.2 requires that you perform code review in order to identify any vulnerabilities prior to the code going to production. I want to talk for a moment about separation of duties because that really relates to what this requirement is getting at. 

When you look at the requirements of 6.3.2, it says that the code review has to be performed by someone different than the originating coder. This is a challenge for a lot of organizations that we work with. They don’t have the necessary resources or personnel in order to separate duties like this. But code review is very, very critical and having a process within your software development lifecycle that speaks to how you’re going to perform code reviews (whether manually, using some tool that you’ve acquired, or it might be that you’re even using a third party to assist you in this) is very critical. You need someone other than the originating coder to perform these code reviews. The point of the code review is to identify vulnerabilities that are not known. You want to expose these things by using secure coding methodologies to evaluate the software that you’re developing and, so, you will turn to something like OWASP in order to evaluate your code against a very well-respected industry framework. 

When we’re working through audits with clients who are deploying code to production, we will ask questions about the training and knowledge of the individuals involved. You don’t want to have someone performing a code review to simply check the box, update the ticket, and move it along through the pipeline. You want someone who actually understands these secure coding methodologies – someone who you have invested in to send them to training – maybe they’ve attended some SANS training or maybe they are subscribed to some of the resources that Microsoft provides for .net security practices. There are lots of different ways to accomplish this requirement, but the idea is to get that security knowledge on your team so that someone can have that responsibility to review to identify these vulnerabilities before code is pushed to production.