Application developers use a variety of tools to identify flaws in their software. Many tools, like dynamic analysis tools, cannot be used until later in the development lifecycle, as they require a staging site and sample data and often require a compiled build. In contrast, manual code reviews can begin any time and do not require specialized tools - only secure coding knowledge. It can be performed on every check-in, build, or other intervals that work for your development process.
Code reviews can find vulnerabilities that are difficult to discover with other testing techniques, such as integer overflows or missing encryption on sensitive data. While anyone involved in the building of software can conduct them, developers are usually in the best position to find problems since they are closest to the logic and syntax of the code. Most security code reviews combine human effort and technology support, i.e., static analysis security test (SAST) tools. Such tools don't understand dynamic data flow or business logic; they are suitable for broad coverage to set a minimum baseline.
The scope of any given software project and its requirements might run through the hands of several developers. The code review process can serve as a check and balance against different interpretations of that scope and requirements compared to the code that is delivered.
Security code reviews enforce a consistent coding style throughout a project, thereby making source code readable by anyone who might be introduced to the project at any given time during development.
During a security code review, developers can also share new technologies and techniques with others on the team. Sharing techniques transcend seniority, where every developer is equally able to share, cooperate, and improve their skills. Due to a lack of experience, some younger developers might be unaware of optimization techniques that could apply to their code. This security code review process provides an opportunity for these developers to acquire skills and boost the performance of their code.
Tips for Effective Security Code Reviews
Manual code reviews can be laborious if reviewing every line of source code. That's why it is critical for developers to know how to organize code reviews, prioritize code segments that need review, and conduct best practices for maximum efficiency.
- Set time limits - when reviewing code, it's easy to get lost in the details and lose track of the higher-level security bugs you seek. Set a reasonable time limit on your review, and then use this to keep yourself from getting stuck. If you find yourself spending too much time in any one place, especially if it is not a high-priority area of code, flag it for later review and move on.
- Set time and Lines of Code (LoC) limits - studies suggest reviewing no more than 400 lines of code (LOC) or for 60 minutes at a time. The brain can only effectively process so much information at a time, and beyond that, the ability to find defects diminishes.
- Understand inputs and outputs - dataflow analysis is a powerful mechanism for finding security flaws. Understand every source of data in the code you are reviewing and where the data will end up. How much trust you are willing to give the source and the ultimate destination of the data significantly impacts the level of data validation the code should have.
- Review iteratively - rather than waiting until the end of a project and reviewing everything then, review at each check-in. This allows you to focus on what's changed rather than trying to find all the problems at once.
- Set clear objectives - spend time in the beginning to understand vulnerabilities that are possible in the code. Understand the patterns of bad code you want to eradicate and then review with a clear idea of what to look for.
- Review only for security - the more you are looking for during a review, the less likely you will find any of them. Stay focused on the discrete set of security objectives.
- Use checklists - checklists are the most effective way to eliminate frequently made errors and combat the challenges of omission-finding.
- Update coding standards - identify problems that occur repeatedly. Add coding standards to address these problems.
- Focus on Hot spots - these are areas that were, likely, highlighted in your preliminary scan - areas of code with many 'hits' from static analysis, code that mitigates a known threat, complex code (cyclomatic complexity measures can help.) Vulnerabilities tend to cluster in code, so be on the lookout.
- Identify what's out of scope - clarify what you will not be looking for so you don't waste time.
- Review with a partner - a second set of eyes and the resulting dialog will increase the odds of finding vulnerabilities and keep you fresh longer.
-
Conduct against a threat model - rather than randomly trying to find problems, a threat model guides the review and ensures scrutiny is focused on the application's most critical threats, assets, and components.
As illustrated, a secure code review does not attempt to identify every issue in the code; instead, it uncovers insight into what types of problems exist and arms developers with information to help remediate them.
About Lisa Parcella, Vice President of Product Management and Marketing
With a background in security awareness, product management, marketing communications, and academia, Lisa leverages her vast experience to design and deliver comprehensive security-focused products and educational solutions for the company’s diverse client base. Before joining Security Innovation, Lisa served as Vice President of Educational Services at Safelight Security. She holds a B.A. from the University of Vermont and an M.A. from Boston College. Connect with her on LinkedIn.
