code review can be as simple as a colleague going through your code and suggesting tweaks to improve the performance, or as extensive as running an automated tool followed by manual analysis to uncover bugs.

 Asecure code review, on the other hand, is the strategic review of a piece of software’s code to identify potential security vulnerabilities. When it comes to the development and release of an application, developers usually don’t consider conducting a review until the very end of the development life cycle or even after the release of the application. However, it should be incorporated into the development life cycle at an early stage, thus reducing overhead costs and the time it takes developers to remediate security bugs.

What problems does a secure code review solve?

A secure code review uncovers flaws in software that are often not readily apparent in the compiled and executing piece of software. For example, imagine a programmatic switch statement that has conditions A, B, and C, suppose that conditions A and B cover 99.99% of the use cases. Legitimate users, quality assurance testers, and penetration testers are likely to only explore 99.99% of the data flows. Security vulnerabilities often manifest themselves in that .01% of use cases, especially when such a condition exists to catch a particular fail state. Reviewing the source code makes condition C apparent. As such, its data flow can be followed and any security implications can be addressed proactively.

There are two primary limiting factors that can make a secure code review tricky: humans and automation. For a human, the limiting factor is the relatively few lines of code that an individual can review in a work day. At best, a human may be able to review several hundred lines of code in a day. Considering that modern software is often comprised of tens or even hundreds of thousands of lines of code, it is highly unlikely for a human to manually review every line of code. It would require nearly as many reviewers as developers to approach the process using manual methods alone.

Automated tools can review code much faster than humans. The trade-off, however, is that automation is far more prone to missing security implications (false negatives) as well as falsely identifying them (false positives). In addition, automated tools often don’t understand the context in which code is written.

To overcome these limitations, a review should be performed through a combination of manual and automated efforts. Automated tools can quickly scan the code base to identify areas of interest and potential vulnerabilities. Triaging automated findings guides the manual investigation into those potential vulnerabilities. Manual reviews are also useful when reviewing the code for certain classes of flaws such as authentication and cryptography.

Six key steps of a secure code review 

1. Get proactive about security during the design process: Establish security standards early and identify a security lead for all projects.
2. Review code as you create it: Maintain secure coding standards, SASTas you type, and conduct peer reviews.
3. Include change management in the SDLC: Review change requests and communicate security impacts to developers.
4. Check-in code after remediating security bugs: Review code before check-in, perform a SAST scan of the code, and integrate SAST into the check-in process.
5. Audit the entire integrated code base: Review the entire code base periodically for security issues, run SAST against the entire code base, and set a release gateway that includes reviews.
6. Utilize lessons learned: Adjust coding standards based on review findings, share results with all developers, and plan training based on patterns and trends in the results.