Template: Secure Code Review Guidance and Code Priority Definitions

| Security Development Lifecycle

Criteria for prioritizing code for a security review and guidance on defining security priority

For the latest information, please see http://www.microsoft.com/sdl.

This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

Microsoft and Windows are trademarks of the Microsoft group of companies.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Code Priority Definitions

Use the information in this document during security code reviews to help determine which components are most at risk and set project priorities. High-risk items—Priority 1—should be reviewed the earliest and most in depth. For a minimal checklist of security issues to be aware of during code reviews, see Appendix D: A Developer’s Security Checklist in Writing Secure Code, Second Edition (p. 731).

Any code or component that has a high number of frequently-discovered security bugs is considered to be Priority 1 code, even if it otherwise maps to Priority 2 or Priority 3 per the definitions in the documents referenced above. While the definition of high rates of security bugs is subjective within the team, it is important to examine the portions of code that have experienced the highest rates of security issues with extra scrutiny.

Don't forget to include and prioritize all sample code shipped with the product. Consider how customers will be using the samples. Samples that are expected to be compiled and used with little modification in production environments should be considered Priority 1.

Code priority definitions are provided in the following sections.

Priority 1 Code

Priority 1 code is considered the most sensitive from a security standpoint. The following examples of Priority 1 code are not a definitive list, but are a starting point and provide a general overview of the types of code that should be given extra scrutiny:

· All Internet or network-facing code.

· Code in the Trusted Computing Base (TCB) (for example, kernel or SYSTEM code).

· Code running as Administrator or Local System.

· Code running as an elevated user (including LocalService and NetworkService).

· Features with a history of vulnerability, regardless of version.

· Any code that handles secret data, such as encryption keys and passwords.

· Any unverifiable managed code (any code that the standard PEVerify.exe tool reports as not verified).

· All code supporting functionality exposed on the maximum attack surface.

Priority 2 Code

Priority 2 code is optionally installed code that runs with user privilege, or code that is installed by default that does not meet the Priority 1 criteria.

Priority 3 Code

Priority 3 code is rarely used code and setup code.

NOTE: Setup code that handles secret data, such as encryption keys and passwords, is always considered Priority 1 code.