Secure Code Review

Definition: A secure code review is a specialized task involving manual and/or automated review of an application's source code in an attempt to identify security-related weaknesses (flaws) in the code. A secure code review does not attempt to identify every issue in the code, but instead looks to provide insight into what types of problems exist and to help the developers of the application understand what classes of issues are present. The goal is to arm the developers with information to help them make the application's source code more sound and secure.

Keywords: code review, evaluation, secure code, secure code review, secure development, security, test, vulnerable software

MITRE SE Roles & Expectations: MITRE system engineers (SEs) often help our sponsors and customers formulate plans and policies for developing applications through all stages of the software development life cycle. Security has become a major point of emphasis and a key component within the larger area of mission assurance. Writing source code that is sound and secure is key in creating applications that withstand attack and function as intended in the face of a malicious adversary. As a consequence, MITRE SEs are expected to understand the rationale behind a secure code review and when such a review is appropriate. They are expected to understand where a secure code review fits into the software development life cycle and how it can be used most effectively to identify potential issues within the code. Finally, MITRE SEs are expected to understand how a secure code review is performed and what its strengths and limitations are.


Application-level security is increasingly coming under fire. The Stuxnet worm [1] in 2010 was a high-profile example of how a malicious user can leverage an application vulnerability to subvert protection mechanisms and damage an end system. Verifying that applications correctly implement security mechanisms and do not contain vulnerabilities is critical to achieving mission assurance goals.

Compounding the problem are the facts that applications are becoming more interconnected and that flaws in one application often lead to exploitation of other applications. There is no unimportant application from the security point of view. Malicious users are eager to take advantage of any flaw in any application that enables them to achieve their goal.

Almost all software development life cycles include testing and validation, which is often accomplished as a code review by either a peer or an external entity. The review verifies that the application functions as expected and that required features have been implemented correctly. Code reviews are important and should still occur. However, an additional review with a focus solely on security should also be conducted.

A secure code review is a specialized task involving manual and/or automated review of an application's source code in an attempt to identify security-related weaknesses (flaws) in the code. It does not attempt to identify every issue in the code, but instead looks to provide insight into what types of security-related problems exist and help the application developer understand what classes of issues are present. A secure code review will not necessarily find every security flaw in an application, but it should arm developers with information to help make the application's source code more sound and secure.

The goal of a secure code review is to find and identify specific security-related flaws within the code that a malicious user could leverage to compromise confidentiality, integrity, and availability of the application. For example, an unchecked input to a buffer may enable a write past the end of the buffer and allow a malicious user to execute arbitrary code with escalated privileges. A secure code review looks to find these types of issues, notify development teams of them, and eventually result in fewer vulnerabilities in the application.

A secure code review is not a silver bullet, but it is a strong part of an overall risk mitigation program to protect an application.

Government Interest and Use

On October 29, 2010, The Defense Information Systems Agency (DISA) issued Version 3, Release 2, of the Application Security and Development Security Technical Implementation Guide (STIG) [2]. This document "provides the guidance needed to promote the development, integration, and updating of secure applications" throughout their life cycles.

Department of Defense (DoD) Directive (DoDD) 8500.01E requires that all information assurance (IA) and IA-enabled information technology (IT) products incorporated into DoD information systems be configured in accordance with DoD-approved security configuration guidelines, and it tasks DISA to develop and provide security configuration guidance for IA and IA-enabled IT products in coordination with the Director, National Security Agency. The Application Security and Development STIG is provided under the authority of DoDD 8500.01E.

APP5080 within the Application Security and Development STIG mandates a secure code review before an application is released.

Focus of a Secure Code Review

A secure code review focuses on seven security mechanisms, or areas.  An application that is weak in any area makes itself a target for a malicious user and increases the likelihood that the application will be used in an attack. A secure code review should inform the developers of the soundness of the source code in each of these areas:

  • Authentication
  • Authorization
  • Session management
  • Data validation
  • Error handling
  • Logging
  • Encryption

Several weaknesses (flaws) can affect each of the preceding security mechanisms. Flaws in the handling of passwords often affect authentication. Flaws related to the type of information included in a message often affect error handling. Flaws in regular expressions often affect data validation.

The Common Weakness Enumeration [3] is a listing of the specific types of flaws that a secure code review looks for. "It serves as a common language for describing software security weaknesses, as a standard measuring stick for software security tools targeting these vulnerabilities, and as a baseline standard for weakness identification, mitigation, and prevention efforts."

Manual vs. Automated Review

A secure code review can be a manual or automated review, each with advantages and disadvantages. In a manual review, an analyst reviews the code line by line, looking for defects and security related flaws. An automated review uses a tool to scan the code and report potential flaws.

Manual review is time consuming and requires significant domain expertise to be done correctly. Often it takes years of experience to become efficient at manual code review. Even with experienced human analysis, errors in the review (missed and incorrect findings) are unavoidable. A proficient reviewer can get through about 3,000 lines of code a day, based on the experiences of the MITRE Secure Code Review Practice [4].

Automated review helps solve the problems associated with manual review. However, good automated review tools are expensive. Additionally, the technology behind automated tools is only effective at finding certain types of flaws. A single automated tool may be good at finding some issues but unable to detect others. Employing multiple automated tools can mitigate this problem but will still not uncover every issue. Automated tools also tend to produce false positives (reported findings that are not actually issues). Adjudicating false positives requires human intervention and takes time away from the development team.

The best approach for a secure code review is to understand the advantages and disadvantages of each method and to incorporate both as appropriate.

When to Perform a Secure Code Review

Security should be a focus throughout the entire development life cycle. Creating threat models during the design phase, educating developers on secure coding practices, and performing frequent peer reviews of code with security personnel involved will all help increase the overall quality of the code and reduce the number of issues reported (and hence that need to be fixed) by the secure code review.

However, a secure code review is best used toward the end of the source code development, when most or all functionality has been implemented. The reason for waiting until late in the development phase is that a secure code review is expensive and time consuming. Performing it once toward the end of the development process helps mitigate cost.

Best Practices and Lessons Learned

Understand the developers' approach. Before starting a secure code review, talk to the developers and understand their approaches to mechanisms like authentication and data validation. Information gathered during this discussion can help jump-start the review and significantly decrease the time a reviewer spends trying to understand the code.

Use multiple techniques. If possible, use both manual and automated techniques for the review because each method will find things that the other doesn't. In addition, try to use more than one automated tool because the strengths of each differ and complement the others.

Do not assess level of risk. A secure code review should not attempt to make judgments about what is acceptable risk. The review team should report what it finds. The customer uses the program's approved risk assessment plan to assess risk and decide whether to accept it or not.

Focus on the big picture. When performing a manual review, resist trying to understand the details of every line of code. Instead, gain an understanding of what the code as a whole is doing and then focus the review on important areas, such as   functions that handle login or interactions with a database. Leverage automated tools to get details on specific flaws.

Follow up on review points. After a review, hold a follow-up discussion with the development team to help them understand what the findings mean and how to address them.

Stick to the intent of the review. Secure code review is not penetration testing. Review teams should not be allowed to "pen-test" a running version of the code because it can bias the results by giving a false sense of completeness.

Limitations of a Secure Code Review

A secure code review is not a silver bullet and performing such a review does not mean that every instance of a security flaw will be discovered. Rather it is one of many different types of activities that can help increase the quality of an application and reduce the number vulnerabilities in software, making it more difficult for a malicious user to exploit.

References & Resources

  1. Wikipedia contibutors, Wikipedia, The Free Encyclopedia, "Stuxnet," accessed February 14, 2011.
  2. Application Security and Development Security Technical Implementation Guide, Defense Information Systems Agency, Version 3, Release 3.
  3. The MITRE Corporation, Common Weakness Enumeration.
  4. The MITRE Corporation, Secure Code Review Practice.

Additional References & Resources

  • Viega, J., and G. McGraw, 2002, Building Secure Software: How to Avoid Security Problems the Right Way, Addison-Wesley, ISBN 0-201-72152-X.
  • Dowd, M., J. McDonald, and J. Schuh, 2007, The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities, Addison-Wesley, ISBN 0-321-44442-6.
  • Department of Homeland Security, 2010, Software Assurance Pocket Guide Series: Software Security Testing.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team