Attackers often try to find paths to sensitive data through poorly developed code. Common coding issues lead to critical data security issues that allow attackers to enable errors such as cross-site scripting, buffer overflow, or SQL injection.
However, most live application coding errors could have been easily avoided if all code had been reviewed before going live.
Some developers take pride in double-checking and testing their code, but the Payment Card Industry Data Security Standard (PCI DSS) says that’s not enough.
Every organization that generates private internal or public code must personally or automatically evaluate the code to catch mistakes before publishing it to the live environment to comply with PCI DSS Requirement 6.3.2.
What is Code Review?
Code review is the checking of the written code by one or more software developers before going live. There are points to be considered here; of course, one cannot review his code. The person making the Code Review must have competence on that subject. Before submitting the code for testing, it is necessary to do a code review to ensure that it is free of bugs and other security risks.
One of the social activities carried out to improve the code quality in the projects under development, to enable the developers to improve their code skills and their command of the language, including libraries or frameworks, to minimize bugs and to practice ideas on alternative solutions, is a team review of codes.
See Also: What Are the Impact Analysis Requirements for PCI DSS Compliance
The purpose of code review is to ensure that the team is familiar with the whole process and exchange ideas on security vulnerabilities, unnecessary duplication, error catching and management, resource usage, and performance regarding the development process.
In the code review process, the reviewer is defined as the author whose code is reviewed. The reviewer can be a person or a tool that can check.
A code that functions and fulfills its purpose means that it has accomplished its task. However, this does not mean that all relevant code or application was written in the most “correct” way.
See Also: PCI Secure Coding Training Requirements
Therefore, it is a practical, safe and understandable way to have the code reviewed by a more experienced developer before reaching the user.
Poorly written code will put the coder or another developer on the team in more trouble than planned many times.
Code Review How should it be done?
First of all, there must be specific criteria for code quality. The requirements you will determine should be the rules that must be followed for each project in its way. For example, there may be specific criteria such as variable naming, which may vary from project to project.
- While committing the transactions, piece by piece and meaningful pieces should be committed together.
- Keeping in mind that the code reviewer criticizes the code, not the developer, it should be evaluated accordingly. We should not forget that the comments made will bring the programmer to a better point.
- The software developer reviewing the code should find the errors or deficiencies in the code and explain or correct them in a formal language to the software developer who wrote the code.
- If the code reviewer imports a significant software development, he should check it piece by piece.
- Before reviewing the code, the developer needs to open the code on the feature branch. After the code has passed all approvals, it must be merged.
- If the development is a complex one, the developer should explain his work by writing a comment.
- In the development, the question should be asked whether each function is doing its job. A function should not be made to do more than one job.
- It should be checked to see if the developed code has been used before or a function can perform this task.
- It is necessary to check whether there is information embedded in the code that should not be shared outside.
- After all the processes are finished, the code should not merge directly into the test environment. The code needs to be run by the developer reviewing it locally, making sure that it doesn’t break elsewhere in the project.
Why Code Review?
First, it would be appropriate to create a checklist for code review. In this way, the developer can follow his development, and review meetings can be conducted in a more functional and social practice. The checklist can be expanded most appropriately in the relevant code and application, especially in standard writing formats.
Commenting in the review process should be about the code, not the developer, and should not contain personal opinions. A proposal should be put forward with references such as comparisons or a link to the documentation.
See Also: Best Practices and Recommendations for API Security
General acceptance is to make the code most functional before it reaches the user. It can be said that the most appropriate process is before the relevant task is considered as done to avoid test repetition.
For this reason, code review can be done before the code is merged or by branching to local. If the reviewer approves the improvements made in the development environment, the code can be merged into the master branch. Code that has not been reviewed and approved under normal conditions should never be merged into the master branch.
The author should remove unnecessary whitespace or comment fields that could potentially distract before code is reviewed. However, comments with reference links can be protected.
The evaluation process should not be impersonal, and all opinions should be made within the framework of measurable and analyzable expressions as much as possible.
The most significant purpose of code review is for the software developer to improve himself and develop better quality codes. Now let’s examine these reasons;
- If the code is reviewed before the development and testing, possible bugs are prevented.
- The competency levels of the software developers in the team are different from each other. This is how experienced developers can transfer their experience and knowledge to less experienced developers.
- It should not be forgotten that not everything that every code reviewer says may be true. Here, it is necessary to find the most correct mutually.
Code reviews also positively affect the competence of software developers. Not all programmers in a project have the same competence, some are more experienced, and some are less experienced. When Code Review is done, the knowledge of other software developers is transferred to increase the competence of everyone.
What Should the Competencies of the Code Reviewer Be?
We use many methods to increase code quality in the projects that we are developing. One of these methods is code review. Unfortunately, software developers consciously think that all the code they write is the best. But in some cases, that code snippet is proven to look good only when viewed with the programmer’s eyes.
What matters is this proven time. If the written code has already reached the user, it may be too late for everything. Not every lousy code written will affect the user, but every awful code written will come back to the programmer.
This is where Code Review comes into play. We can briefly say that Code Review is that a few of our teammates look at the code we have written, check how well we have written it, and give feedback.
- Code review can be done by knowledgeable internal staff, third parties, or code review tools other than the original code author.
- Developers reviewing the code should not succumb to their egos.
- It should not be forgotten that code review is an activity for both sides to develop and to detect security vulnerabilities in advance.
- The programmer who reviews the code should examine the code without hurting the developer.
- If the code reviewer has poor communication with the other party, disagreements and problems may arise within the team.
- Code review can be done by knowledgeable internal staff, third parties, or code review tools other than the original code author.
- Remember, code review by internal staff doesn’t mean your development team can randomly review each other’s code. The actual code review is completed by someone experienced in coding guidelines.
- Code reviewers should understand how to identify code vulnerabilities such as backdoors. While experienced at generating great code, most developers aren’t used to looking for the basics to find potential security vulnerabilities.
- Many development departments rely on products that have automated code reviews. However, automated tools aren’t perfect either. After all, human flaw is the reason code review exists in the first place. Note that it may be difficult or even impossible for an automated code review tool to identify some coding issues.
What Are the PCI DSS Code Review Requirements?
PCI DSS Requirement 6 requires code to go through many stages of development before it goes into production to ensure software applications are developed securely. PCI DSS requirement 6.3.2 adds another level of information security to the application by requiring you to review custom code before release or production.
See Also: PCI Web Application Security Requirements
PCI DSS requirement 6.3.2 requires you to analyze custom code for potential coding vulnerabilities before releasing it to production or clients.
According to PCI Requirement 6.3.2, this review process should include the following elements:
- Changes to the code are examined by someone who is not the original author of the code and is familiar with code review methodologies and secure coding practices. Just because someone can write code doesn’t mean they can review it. Hence the person in charge of code review needs to be well taught. It is also essential that code reviews are performed by someone other than the code developer to allow for an objective assessment.
- Code reviews ensure that code is developed according to secure coding guidelines.
- Appropriate corrections should be applied before the code is published. If a vulnerability is discovered and not fixed, it puts your application at risk. PCI DSS also states that lousy code will be much more difficult and expensive to handle once distributed or released in production environments.
Code reviews can be done manually or using automated tools. However, if an organization uses an automated tool, code review isn’t just about the tool. Before the application goes into production, there should be processes to address the identified vulnerabilities, and critical, high, or severe vulnerabilities should be addressed. Most organizations perform such testing as part of the quality assurance process.
See Also: Source Code Analysis for PCI DSS Application Security
Most code analysis tools can integrate into the developer’s workbench and perform vulnerability testing while code is being developed. However, while this ensures that specific code modules are secure, it does not guarantee that all modules that make up the application are secure as a whole. Therefore, the completed application should be scanned for vulnerability to ensure that the application as a whole is safe.
Before going into production, the results of the code review are evaluated and authorized by management. This does not mean that management has performed the code review; rather, leadership certifies that necessary fixes have been made and that the development process is working as described.
Which Code Should Be Examined?
The types of codes that PCI DSS requires you to review can be summarized as any code that may interact in any way with your payment card environment. The following types of codes should be examined in more detail:
- Internally generated code: All code developed by your in-house developers must undergo code review.
- Any outsourced code: If you outsource application development to a third-party IT company, freelance coder, or someone else, your organization is responsible for ensuring that code is reviewed against PCI DSS code review standards.
- Backend code: The backend contains all the processes that interact with sensitive data and is also where you store sensitive data. This is why backend code needs to be evaluated.
- Public code: Public websites, especially those with web payment forms, should be heavily reviewed and strengthened.
Security Best Practices for Code Review
To identify potential coding vulnerabilities, you should do extensive studies of code review and fix before release. Best practices are described below to make the code review aspect of the PCI DSS a little easier to understand.
1. Include a Different Person from the team
A different person from the team can provide valuable objective insight during a code review. While it’s not necessary to bring in an independent third party for PCI DSS compliance, a newbie will help catch vulnerabilities that your team may not be aware of.
Neutral outsiders are also helpful in bypassing internal policies and policies that can disrupt your department’s code review process. A stranger is not worried about hurting his feelings. It cares about finding and auditing code for security errors.
2. Don’t Skip Minimal Changes
As PCI DSS clearly states, a code review should be done every time new code is added to the environment. This includes all changes, even minor ones. Don’t let minimal upgrades put you in similar danger. No matter how small the change, make sure you keep up with your process.
For extensive code changes like product releases or a new website, consider a source code analysis. While source code analysis isn’t required by the PCI DSS, thinking like a hacker can help you beat a hacker.
Source Code analysis tools analyze the code, identify potential vulnerabilities, and exploit them like hackers. It’s a great way to test how robust or not your code is.
3. Check Code Through Static and Dynamic Review Operations
Although a static code review usually detects most vulnerabilities, examining your code in action can lead to issues that are not easily found in a static review. Examining code that interacts with a SQL database, for example, may identify a vulnerability that allows for SQL injection.
One of the most dangerous activities a developer can take is making modifications in a production environment and enabling new, untested code to enter the environment. Unfortunately, this is extremely common.
4. Make Documentation Part of the Process
Comments are written in code by developers to document code changes in general. This is excellent practice, but it should not stand alone as a coder’s sole documentation source. Comments can be accidentally deleted or changed, resulting in documents permanently lost.
Appropriate documentation will provide a more streamlined code review process and excellent proof of compliance in the event of a PCI DSS audit.
5. Add Code Review to Your Software Development Lifecycle
The most crucial point in the software development lifecycle is that you follow and disseminate a neatly summarized software development lifecycle. The software lifecycle should include development methodology, training, vulnerability testing, change control forms, and code review.
For example, when any time code is changed, developers should use change control forms to document how the change will affect customers, change functionality, affect security, rollback procedures, etc.
An adequately integrated software development lifecycle will help your organization and developers build and maintain your applications securely.
