How to conduct a secure code review

Secure code review vs. application security testing

Security must be included during every stage of the software development lifecycle -- planning, analysis, design, implementation, testing and integration, and maintenance.

It is important to not confuse secure code reviews with application security testing. Many ways exist to test the security of an application: penetration testing, fuzzing, dynamic testing and so on. A review of the code, however, is the only way to scrutinize the entire attack surface. Evaluating the attack surface makes it easier to identify potential weaknesses in edge cases and elusive application states.

Secure code reviews can be performed at any point in the software development process, but most often occur during the development phase, when bugs are relatively easy to fix using a combination of automation and manual inspection. Dynamic application security testing and pen testing, on the other hand, require a running system and sample data to complete a review.

How to conduct a secure code review

The following key issues should be checked for in every secure code review:

• failures in identification, authentication and access control;
• potential exposure of sensitive data;
• inadequate error handling; and
• all types of injection flaws.

Automated code scanning tools, known as static application security testing (SAST) tools, can identify several common coding errors that lead to vulnerabilities. Such analysis tools flag vulnerable and outdated components and ensure code meets the organization's coding standards by enforcing naming conventions, formatting and comments. A well-commented and consistent coding style makes manual code review a lot easier.

Plenty of commercial and open-source SAST tools can be run straight from the developers' integrated development environment while they are coding. This means baseline tests can be run anywhere the developer wants to check the code, which helps eliminate many basic and common errors, such as those in the OWASP Top Ten and the Common Weakness Enumeration's Top 25 Most Dangerous Software Weaknesses.

SAST tools, however, don't understand dynamic data flows, so they are unlikely to detect flaws embedded in complex business logic and bespoke applications. Manual code inspections, therefore, help developers focus on security-critical components and the implementation of security requirements specific to the project. Manual code requirements come from the threat modeling report completed during the software design phase. These reports identify potential security threats and vulnerabilities as well as the necessary controls to mitigate them, ensuring security policies and privacy and regulatory requirements are met.

All code should be security checked before developers merge new code with the main branch of a project. Keep in mind that small pull requests are easier to evaluate and review. Developers should run SAST tool and unit tests and correct any errors and warnings generated by these tests before making the pull request. Ideally, the SAST tool will generate code complexity metrics; overly complex code is difficult for others to understand and makes finding potential bugs harder.

A manual code review should be performed by individuals who have secure code training and can follow complex control and logic flows. Confirm the business logic and security requirements are correctly implemented. Reviewers, armed with a threat modeling report and a good understanding of how the application needs to work, won't need to check every line of code. They should instead concentrate on critical entry points in the application, such as authentication and authorization, data validation and encryption, user account management, and high-risk business logic and data flows.

Then it's a case of stepping through the functionality of the code to identify vulnerabilities in control or logic flow paths that the original programmer was unaware of or missed.

Security vulnerabilities are most likely to occur when the code does not correctly handle the following:

• authentication
• authorization
• access control
• cookies and tokens
• input and data validation
• encryption
• errors

Reviewers should also check that injection and cross-site scripting attacks are not possible and that sensitive information, such as passwords, is not embedded in the code.

The code can be merged with the main project once it passes inspection, but if there are issues, the pull request should be rejected. Each review is an opportunity for developers to improve their security knowledge and the quality of their next pull request. If the same issues arise frequently, increase training and policy awareness to improve security and team efficiency. Metrics generated by these reviews -- such as the number of rejected pull requests, the seriousness of errors found and the length of response times -- improve code quality and productivity in the future.

Software will never be bug free, but the impact of a security vulnerability can be widespread and potentially life threatening. You must conduct regular security code reviews. They improve the overall security of an application and provide cost benefits and metrics on how well developers are writing secure code and eliminating common errors.

It's better to ensure code is secure before release than rushing out a critical update that users may never install.