Code Reviews: A Method to Reveal Costly Mistakes

Double checking code catches a potential compromise before it happens. 

By: Gary Glover

Successful attackers frequently find routes to sensitive data through poorly developed code. Common coding problems lead to critical data security issues, which could allow attackers to enable bugs like cross-site scripting, buffer overflow, or SQL injection.

Most live application coding errors could easily have been avoided if all code was simply reviewed before launch.

Would you believe only 10% of security professionals surveyed by Veracode said their apps were "reviewed for security before, during, and after launch"? Lack of code review is a bigger problem than most organizations think.

Some developers pride themselves on double-checking and testing their own code, but according to the Payment Card Industry Data Security Standard (PCI DSS), that’s not enough.

To comply with PCI DSS Requirement 6.3.2, every company that creates custom internal or public-facing code must have it reviewed (manually or automatically) by a person, software, or company (other than the original author) to catch mistakes before the code is released.

Who Should Conduct a Security Code Review?

Code review can be conducted by knowledgeable internal personnel (other than the original code author), third parties, or code review tools.

Keep in mind, code review by internal personnel doesn’t mean your development team can randomly review each other’s code. True code review is completed by a person experienced in coding guidelines. Code reviewers must understand how to identify code security gaps, like backdoors. While awesome at cranking out fantastic code, most developers aren’t accustomed to search through the nitty gritty for possible vulnerabilities.

Many development departments trust their code review to automated products. After all, human imperfection is the reason code review exists in the first place. For example, Veracode has an automated software that analyzes source code. Valgrind is an open source option for Linux code evaluation.

That being said, automated tools aren’t perfect. The PCI DSS states, “Keep in mind that it may be difficult or even impossible for an automated tool to identify some coding issues.”

What Code Must Be Reviewed?

The types of code the PCI DSS obligates you to review can be summed up in one sentence:
Any code that could possibly interact with your payment card environment in any way must go through code review. More specifically, this means:

• Code produced internally: Any code developed by your in-house developers/coders must go through code review.
• Any outsourced code: If you outsource an application development to a third party IT company, a freelance coder, your brother, or anybody else, your organization is in charge of ensuring that code is reviewed by PCI DSS code review standards.
• Backend code: The backend holds all the processes that interact with sensitive data, and is also likely the location you store sensitive data. Therefore, it must be evaluated.
• Public-facing code: Public-facing websites, especially those with web payment forms, must be heavily reviewed and fortified.

5 Security Best Practices for Code Review

In order to identify potential coding vulnerabilities, you’ve got to crack down on code review and correction prior to release. Here are a few ways to make the code review aspect of the PCI DSS a little easier to swallow.

1. Bring in an Outsider
Someone with outside eyes could lend valuable, objective insight during a code critique. Although bringing in an independent third party isn’t necessary for PCI DSS compliance, fresh eyes will help catch vulnerabilities that may have been right under your team’s nose.

Unbiased outsiders are also helpful when it comes to bypassing internal policies and politics that may bog down your department‘s code review process. An outsider doesn’t worry about hurting feelings. He cares about finding and auditing code for security errors.

2. Don’t Let Minimal Changes Slip Under the Rug
As the PCI DSS clearly states, code review must happen any time new code is introduced into the environment. That includes all changes, even small ones.

If you don’t think small changes are worth reviewing, just ask Blue Shield of California what they think. Their company underwent a data breach in 2015 due to a simple coding error after a website upgrade.

Don’t let minimal upgrades get you into similar danger. Make sure your process stands, no matter how small the change.

For large code introductions, such as product releases or a new website, consider a penetration test. It’s not a PCI DSS requirement for code review, but to beat a hacker you sometimes have to think like a hacker. Penetration testers analyze code, identify potential vulnerabilities, and try to exploit those vulnerabilities just like a hacker would. They’re an excellent battering ram to test just how rock solid your code is (or isn’t).

SEE ALSO: New 3.2 Requirements for Penetration Testing and Segmentation: What You Don’t Know

3. Check Via Static and Dynamic Review Processes
Although static code review usually picks up the majority of security vulnerabilities, studying your code in action can lead to the discovery of some issues not easily found in a static review.

For example, reviewing code interacting with a SQL database might reveal a vulnerability that could lead to SQL injection.

When conducting dynamic code review, don’t forget to test outside of the production environment.

Tweet

Making changes in a production environment and allowing fresh, untested code into the wild is one of the most insecure actions a developer could ever perform. Unfortunately, it’s extremely common.

4. Make Documentation Part of the Culture
As a general rule, developers write comments in their code to document their code changes. This is an excellent practice, but it shouldn’t stand alone as a coder’s sole source of documentation. It takes just one accidental line deletion to ensure that “documentation” is permanently gone.

However you decide to require documentation in your particular environment (I recommend templated documentation forms), proper documentation will ensure a more streamlined code review process and excellent proof of compliance in the case of a PCI DSS audit.

5. Add Code Review to Your Software Development Lifecycle
Perhaps the biggest bit of advice I can provide is this: follow and disseminate a properly outlined software development lifecycle. This lifecycle should include development methodology, training, vulnerability testing, change control forms, and, of course, code review! 


For example, any time code is changed, developers should use change control forms to document how the change will impact customers, how it might change functionality, how it impacts security, if there are any back out procedures, etc.


A properly integrated software development lifecycle will help your organization and developers create and maintain your applications in a secure manner.

A Necessary Evil

Yes, code review is the bane of most coders’ lives. Yes, having a formal review and signoff process will take more product development time. But as the PCI DSS states, “faulty code is far more difficult and expensive to address after it has been deployed or released into production environments.”

Just like any security process, code reviews aren’t foolproof. But by eliminating 99.9% of code vulnerabilities before going live, organizations stand a much better chance of avoiding attackers and maintaining robust data security.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.