At a Glance: Security Code Review

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley

Microsoft Corporation

September 2005

Summary: This provides a summary view of the main input, output, and steps for performing a security code review. For detailed step-by-step instructions, see "How To: Perform a Security Code Review for Managed Code (Baseline Activity)".

Contents

Activity Overview
Activity Summary Table

Activity: Security Code Review

Purpose: Identify security issues before testing and deployment begin.

Input: Code

Output: A set of identified security issues ready to be prioritized for repair.

Activity Overview

The four major code review steps are shown in Figure 1. Review your code each time there is a meaningful change instead of reviewing it all at once at the end of the project. This allows you to focus on what has changed, rather than trying to find all of the bugs at one time.

Figure 1. Security code review steps

The security code review activity involves the following steps:

• Step 1. Identify security code review objectives. Establish goals and constraints for the review.
• Step 2. Perform a preliminary scan. Use static analysis to find an initial set of bugs and improve your understanding of where the security issues are most likely to be discovered during further review.
• Step 3. Review the code for security issues. Review the code thoroughly to find security issues that are common to many applications. You can use the results of Step 2 to focus your analysis.
• Step 4. Review for security issues unique to the architecture. Complete a final analysis that focuses on security issues that relate to the unique architecture of your application. This step is most important if you have implemented a custom security mechanism or any feature designed specifically to mitigate a known security threat.

Activity Summary Table

Table 1 summarizes the security code review activity and shows the input and output for each step.

Table 1: Activity Summary with Input and Output

Additionally, the following input is helpful:

• Application security requirements
• Architecture or component diagram
• Data flows
• Data schemas
• Threat model
• Usage scenarios

Threat modeling can be useful input for Step 1 of the code review activity because it provides a starting point for identifying code review objectives. For more information about threat modeling, see "Threat Modeling Web Applications" at http://msdn.microsoft.com/en-us/library/ms978516.aspx or "Threat Modeling Web Applications" at http://msdn.microsoft.com/ThreatModeling.