Code Review and the SDLC - Revision history

Dre at 09:13, 3 September 2008

2008-09-03T09:13:30Z

KirstenS at 12:42, 31 August 2008

2008-08-31T12:42:40Z

KirstenS: /* Identification of potential solutions */

2008-08-31T12:41:29Z

‎Identification of potential solutions

KirstenS: /* Identification of entry & exit points */

2008-08-31T12:40:44Z

‎Identification of entry & exit points

KirstenS: /* Business requirements & functional context */

2008-08-31T12:40:03Z

‎Business requirements & functional context

KirstenS: /* Business requirements & functional context */

2008-08-31T12:36:40Z

‎Business requirements & functional context

KirstenS: /* Business requirements & functional context */

2008-08-31T12:36:21Z

‎Business requirements & functional context

KirstenS: /* Where to start */

2008-08-31T12:34:45Z

‎Where to start

KirstenS: /* Where to start */

2008-08-31T12:34:17Z

‎Where to start

KirstenS: /* Introduction */

2008-08-31T12:33:54Z

‎Introduction

@@ Line 25: / Line 25: @@
 *'''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.<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 perspective and challenge assumptions made by the business sponsor and development team.<br>
 ''The [[Application_Threat_Modeling|Threat Modeling]] chapter goes into this in more detail.''
@@ Line 33: / Line 33: @@
 '''The user may be''':
-* a member of the public; the applicaiton is exposed to the public Internet.
+* a member of the public; the application 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. <br>

← Older revision		Revision as of 12:42, 31 August 2008
Line 1:		Line 1:
		+	[[OWASP Code Review Guide Table of Contents]]__TOC__
		+
	==Introduction==		==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.		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.

@@ Line 44: / Line 44: @@
 ===Identification of potential solutions===
 *Leading practice
-''See The OWASP Development Guide''
+''See [[OWASP_Guide_Project|The OWASP Development Guide]]''
 ===Execurity Summary & detailed report===
 *Technological risk Vs Business risk

@@ Line 40: / Line 40: @@
 ===Identification of entry & exit points===
-''See the Transactional Analysis chapter''
+''See the [[Transaction Analysis]] chapter''
 ===Identification of potential solutions===

@@ Line 37: / Line 37: @@
 *'''Architecture Risk Analysis'''<br>
-''The Threat Modeling chapter goes into this in more detail.''
+''The [[Application_Threat_Modeling|Threat Modeling]] chapter goes into this in more detail.''
 ===Identification of entry & exit points===

@@ Line 24: / Line 24: @@
 *'''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.<br>
-''The Threat Modelling chapter goes into this in more detail.''
+''The [[Application_Threat_Modeling|Threat Modelling]] chapter goes into this in more detail.''
 *'''User Risk Analysis'''

@@ Line 8: / Line 8: @@
 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.
+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.

@@ Line 4: / Line 4: @@
 ===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 code's 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.

@@ Line 1: / Line 1: @@
 ==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.
+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.
 ===Where to start===