SSDL Touchpoints: Code Review (CR)
The overall goal of the Code Review practice is quality control. Those performing code review must ensure the detection and correction of security bugs. The SSG must enforce adherence to standards and the reuse of approved security features.
CR Level 1: SSG does code review. The SSG must make itself available to others to raise awareness of and demand for code review. The SSG must perform code reviews on high-risk applications whenever it can get involved in the process and must use the knowledge gained to inform the organization of the types of bugs being discovered.
CR1.1
Create a top N bugs list (real data preferred). The SSG maintains a list of the most important kinds of bugs that need to be eliminated from the organization's code. The list helps focus the organization's attention on the bugs that matter most. A generic list could be culled from public sources, but a list is much more valuable if it is specific to the organization and built from real data gathered from code review, testing, and actual incidents. The SSG can periodically update the list and publish a "most wanted" report. (For another way to use the list, see [T2.2] Create/use material specific to company history.)
CR1.2
Have SSG perform ad hoc review. The SSG performs an ad hoc code review for high-risk applications in an opportunistic fashion. For example, the SSG might follow up the design review for high-risk applications with a code review. Replace ad hoc targeting with a systematic approach at higher maturity levels.
CR1.3
Establish coding labs or office hours focused on review. SSG coding labs or office hours are sometimes used for code review. Software security improves without a rigid process. (See also [T1.3] Establish SSG office hours.)
CR Level 2: Enforce standards through mandatory automated code review and centralized reporting. Management must make code review mandatory for all software projects. The SSG must guide developer behavior through coding standards enforcement with automated tools and tool mentors. The SSG must enforce use of centralized tools reporting to capture knowledge on recurring bugs and push that information into strategy and training.
CR2.1
Use automated tools along with manual review. Incorporate static analysis into the code review process in order to make code review more efficient and more consistent. The automation does not replace human judgment, but it does bring definition to the review process and security expertise to reviewers who are not security experts.
CR2.2
Enforce coding standards. A violation of the organization's coding standard is sufficient grounds for rejecting a piece of code. Code review is objective; it does not devolve into a debate about whether or not bad code is exploitable. The enforced portion of the standard could be as simple as a list of banned functions.
CR2.3
Make code review mandatory for all projects. Code review is a mandatory release gate for all projects. Lack of code review or unacceptable results will stop the release train. While all projects must undergo code review, the review process might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation, and the review for high-risk projects might have no upper bound on the amount of time spent by reviewers.
CR2.4
Use centralized reporting (close the knowledge loop, drive training). The bugs found during code review are tracked in a centralized repository. This repository makes it possible to do summary reporting and trend reporting for the organization. The SSG can use the reports to demonstrate progress and drive the training curriculum. (See [SM1.5] Identify metrics and drive initiative budgets with them.) Individual bugs make excellent training examples.
CR2.5
Assign tool mentors. Mentors are available to show developers how to get the most out of code review tools. If the SSG is most skilled with the tools, it could use office hours to help developers establish the right configuration or get started interpreting results. Alternatively, someone from the SSG might work with a development team for the duration of the first review they perform.
CR Level 3: Build an automated code review factory with tailored rules. The SSG must combine automated assessment techniques with tailored rules to find problems efficiently. The SSG must build a capability to find and eradicate specific bugs from the entire codebase.
CR3.1
Use automated tools with tailored rules. Customize static analysis to improve efficiency and reduce false positives. Use custom rules to find errors specific to the organization's coding standards or custom middleware. Turn off checks that are not relevant. The same group that provides tool mentoring will likely spearhead the customization.
CR3.2
Build a factory. Combine assessment techniques so that multiple analysis sources feed into one reporting and remediation process. The SSG might write scripts to automatically invoke multiple detection techniques and combine the results into a format that can be consumed by a single downstream review and reporting solution. Analysis engines may combine static and dynamic analysis.
CR3.3
Build capability for eradicating specific bugs from entire codebase. When a new kind of bug is found, the SSG can write rules to find it, then go through the entire codebase to identify all occurrences. It is possible to entirely eradicate the bug type without waiting for every project to reach the code review portion of its lifecycle.