This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Code Review and the SDLC"

From OWASP
Jump to: navigation, search
(Code review Operational Process)
m (Review - minor punctuation & typos)
Line 1: Line 1:
 
==Introduction==
 
==Introduction==
Integration of secure code review into the system development life cycle should yield dramatic results to the overall quality of the code developed. Secure code review is not a silver bullet but is part of a healthy application development diet. Consider it as one of they layers in a defence in depth approach to application security. Secure code review is also a cornerstone of the approach to developing secure software.  
+
Integration of secure code review into the System Development Life Cycle (SDLC) should yield dramatic results to the overall quality of the code developed. Secure code review is not a silver bullet but is part of a healthy application development diet. Consider it as one of the layers in a defence-in-depth approach to application security. Secure code review is also a cornerstone of the approach to developing secure software.  
The idea of integrating a phase into your SLDC may sound daunting, yet another layer of complexity or an additional cost but in the long term and in today’s cyber landscape it is cost effective, reputation building and in the best interest of any business to do so.
+
The idea of integrating a phase into your SLDC may sound daunting, yet another layer of complexity or an additional cost, but in the long term and in todays cyber landscape it is cost effective, reputation building and in the best interest of any business to do so.
  
 
===Where to start===
 
===Where to start===
To be honest, secure code review is not simply about reviewing code. If all that was required was to review code for correctness any automated grep tool could perform this. Code review is about establishing some context in the business sense around the code. At the end of the day we are not securing code for the codes sake but for what the code or application is protecting, the money, the business intelligence, the good stuff that gives business an edge or the data which equates to financial and capital assets.
+
To be honest, secure code review is not simply about reviewing code. If all that was required was to review code for correctness, any automated grep tool could perform this. Code review is about establishing some context in the business sense around the code. At the end of the day we are not securing code for the codes sake, but for what the code or application is protecting: the money, the business intelligence, the good stuff that gives business an edge or the data which equates to financial and capital assets.
  
 
So the context wherein an application is used is of key importance. An application is going to be attacked by professional criminals only if there is something within the application worth stealing.
 
So the context wherein an application is used is of key importance. An application is going to be attacked by professional criminals only if there is something within the application worth stealing.
  
In the case of code review prior to reviewing code we need to establish the risk profile of the application to be reviewed. The attack surface needs to be established and probability and impact of individual threat agent’s successfully executing an exploit.
+
In the case of code review prior to reviewing code we need to establish the risk profile of the application to be reviewed. The attack surface needs to be established which includes the probability and impact of individual threat agents successfully executing an exploit.
  
 
Internal corporate policies and standards would also dictate the requirements for various categories of web application be it internal, external public, external B2B etc.
 
Internal corporate policies and standards would also dictate the requirements for various categories of web application be it internal, external public, external B2B etc.
  
So on with the code review.
+
So on with the code review...
  
  
Line 23: Line 23:
  
 
*'''Design Risk Analysis'''
 
*'''Design Risk Analysis'''
Design risk analysis focuses on the design on the application from a high level. Examining the semantics relating to the business process. The logical relationships between components of the design. Perfroming a design risk analysis is an oppertunity to the review team to examine the baseline architecture from a risk perpective and challenge assumptions made by the business sponsor and development team.<br>
+
Design risk analysis focuses on the design of the application from a high level. This includes examining the semantics relating to the business process and also the logical relationships between components of the design. Performing a design risk analysis is an opportunity for the review team to examine the baseline architecture from a risk perpective and challenge assumptions made by the business sponsor and development team.<br>
''The Threat Modeling chapter goes into this in more detail.''
+
''The Threat Modelling chapter goes into this in more detail.''
  
 
*'''User Risk Analysis'''
 
*'''User Risk Analysis'''
The business context the proposed solution is what defines the types of user (be a user a human or other IT entity) of the application.<br>
+
The business context for the proposed solution is what defines the types of user (be a user a human or other IT entity) of the application.<br>
  
  
 
'''The user may be''':
 
'''The user may be''':
 
* a member of the public; the applicaiton is exposed to the public Internet.   
 
* a member of the public; the applicaiton is exposed to the public Internet.   
* a broker or agent,a trust relationship exists;the application is exposed to a defined audience.
+
* a broker or agent; a trust relationship exists, the application is exposed to a defined audience.
 
* an internal employee; the application has only internal exposure. <br>
 
* an internal employee; the application has only internal exposure. <br>
  
Line 40: Line 40:
  
 
===Identification of entry & exit points===
 
===Identification of entry & exit points===
See: Transactional Analysis chapter
+
''See the Transactional Analysis chapter''
  
  
 
===Identification of potential solutions===
 
===Identification of potential solutions===
 
*Leading practice
 
*Leading practice
See The OWASP Development Guide
+
''See The OWASP Development Guide''
  
 
===Execurity Summary & detailed report===
 
===Execurity Summary & detailed report===
 
*Technological risk Vs Business risk
 
*Technological risk Vs Business risk

Revision as of 11:14, 11 August 2008

Introduction

Integration of secure code review into the System Development Life Cycle (SDLC) should yield dramatic results to the overall quality of the code developed. Secure code review is not a silver bullet but is part of a healthy application development diet. Consider it as one of the layers in a defence-in-depth approach to application security. Secure code review is also a cornerstone of the approach to developing secure software. The idea of integrating a phase into your SLDC may sound daunting, yet another layer of complexity or an additional cost, but in the long term and in todays cyber landscape it is cost effective, reputation building and in the best interest of any business to do so.

Where to start

To be honest, secure code review is not simply about reviewing code. If all that was required was to review code for correctness, any automated grep tool could perform this. Code review is about establishing some context in the business sense around the code. At the end of the day we are not securing code for the codes sake, but for what the code or application is protecting: the money, the business intelligence, the good stuff that gives business an edge or the data which equates to financial and capital assets.

So the context wherein an application is used is of key importance. An application is going to be attacked by professional criminals only if there is something within the application worth stealing.

In the case of code review prior to reviewing code we need to establish the risk profile of the application to be reviewed. The attack surface needs to be established which includes the probability and impact of individual threat agents successfully executing an exploit.

Internal corporate policies and standards would also dictate the requirements for various categories of web application be it internal, external public, external B2B etc.

So on with the code review...


Code Review - SDLC1.jpg

Code review Operational Process

Business requirements & functional context

  • Design Risk Analysis

Design risk analysis focuses on the design of the application from a high level. This includes examining the semantics relating to the business process and also the logical relationships between components of the design. Performing a design risk analysis is an opportunity for the review team to examine the baseline architecture from a risk perpective and challenge assumptions made by the business sponsor and development team.
The Threat Modelling chapter goes into this in more detail.

  • User Risk Analysis

The business context for the proposed solution is what defines the types of user (be a user a human or other IT entity) of the application.


The user may be:

  • a member of the public; the applicaiton is exposed to the public Internet.
  • a broker or agent; a trust relationship exists, the application is exposed to a defined audience.
  • an internal employee; the application has only internal exposure.


  • Architecture Risk Analysis

The Threat Modeling chapter goes into this in more detail.

Identification of entry & exit points

See the Transactional Analysis chapter


Identification of potential solutions

  • Leading practice

See The OWASP Development Guide

Execurity Summary & detailed report

  • Technological risk Vs Business risk