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 "Security Code Review in the SDLC"

From OWASP
Jump to: navigation, search
m (Review - minor editing of typos / punctuation)
m (Added navigation to facilitate sequential reading online)
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
[[OWASP Code Review Guide Table of Contents]]__TOC__
+
{{LinkBar
 +
  | useprev=PrevLink | prev=Code Review Preparation | lblprev=Preparation
 +
  | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
 +
  | usenext=NextLink | next=Security Code Review Coverage | lblnext=
 +
}}
 +
__TOC__
  
−
==Preface==
+
Security code reviews vary widely in their level of formality. Reviews can be as informal as inviting a friend to help look for a hard-to-find vulnerability, and they can be as formal as a software inspection process with trained teams, assigned roles and responsibilities, and a formal metric and quality tracking program.  
−
 
 
−
Code reviews vary widely in their level of formality. Reviews can be as informal as inviting a friend to help look for a hard to find bug or they can be as formal as a software inspection process with trained teams, assigned roles and responsibilities, and a formal metric and quality tracking program.
 
  
 
In ''Peer Reviews in Software,'' Karl Wiegers lists seven review processes from least to most formal:
 
In ''Peer Reviews in Software,'' Karl Wiegers lists seven review processes from least to most formal:
Line 15: Line 18:
  
  
−
== Mature Secure Code Review (SCR) Model ==
+
Throughout the SDLC there are points at which an application security consultant should get involved. Performing security activities across the lifecycle has proven to be far more cost-effective than either a “big design up front” security effort or a single pre-production security review.  The reason for intervening at regular intervals is that potential issues can be detected early on in the development life cycle where they are less costly to address.
 +
 
 +
Integration of security code review into the System Development Life Cycle (SDLC) can yield dramatic results to the overall quality of the code developed. Security 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 defense-in-depth approach to application security. Security 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.
  
−
Throughout the SDLC there are points at which an application security consultant should get involved. These "touch points" can be used to investige the status of the code being developed from a security standpoint. The reason for interviening at regular intervals is that potential issues can be detected early on in the development life cycle and hence the total cost of ownership (TCO) is less in the long term.
+
'''Waterfall SDLC Example'''
  
−
'''Waterfall SDLC exmaple'''
+
# Requirements definition  
−
*Requirements definition
+
##Application Security Requirements
−
** Functional specification
+
# Architecture and Design  
−
*Design
+
##Application Security Architecture and/or Threat Model
−
** Detailed design specification
+
#Development  
−
*Development
+
##Secure Coding Practices
−
** Coding
+
##Security Testing
−
* Unit tests
+
##Security Code Review
−
* Test
+
#Test  
−
** Functional testing
+
##Penetration Testing
−
** System testing
+
#Deployment
−
** Integration testing
+
##Secure Configuration Management
−
** UAT (User acceptance testing)
+
##Secure Deployment
−
* Deployment
+
#Maintenance  
−
** Change control
 
−
* Maintenance
 
  
−
[[Category:OWASP Code Review Project]]
 
  
−
== Minimal Resource Available Code Review for Web Applications Model ==
+
[[Image:Code_Review_-_SDLC1.jpg]]
  
−
Very often, risk managers are tasked to manually code review large applications with minimal time and resources. This guide will focus on streamlining the manual code review process and outline the bare minimal essentials that are required for review.
+
'''Agile Security Methodology Example'''
 +
#Planning
 +
##Identify Security Stakeholder Stories
 +
##Identify Security Controls
 +
##Identify Security Test Cases
 +
#Sprints
 +
##Secure Coding
 +
##Security Test Cases
 +
##Peer Review with Security
 +
#Deployment
 +
##Security Verification (with Penetration Testing and Security Code Review)
  
−
'''Manual Code Review should at LEAST focus on:'''
+
{{LinkBar
−
#Authorization
+
  | useprev=PrevLink | prev=Code Review Preparation | lblprev=Preparation
−
#Access Control
+
  | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
−
#Input Validation
+
  | usenext=NextLink | next=Security Code Review Coverage | lblnext=
−
#Error Handling
+
}}
−
#Session Management
 
−
#Form Keys or Frequent Session Rotation (for CSRF defense)
 
−
#Proper Application Logging
 
  
 
[[Category:OWASP Code Review Project]]
 
[[Category:OWASP Code Review Project]]

Latest revision as of 15:13, 9 September 2010

««Preparation«« Main
(Table of Contents) 		»»»»


Security code reviews vary widely in their level of formality. Reviews can be as informal as inviting a friend to help look for a hard-to-find vulnerability, and they can be as formal as a software inspection process with trained teams, assigned roles and responsibilities, and a formal metric and quality tracking program.

In Peer Reviews in Software, Karl Wiegers lists seven review processes from least to most formal:

  1. Ad hoc review
  2. Passaround
  3. Pair programming
  4. Walkthrough
  5. Team review
  6. Inspection


Throughout the SDLC there are points at which an application security consultant should get involved. Performing security activities across the lifecycle has proven to be far more cost-effective than either a “big design up front” security effort or a single pre-production security review. The reason for intervening at regular intervals is that potential issues can be detected early on in the development life cycle where they are less costly to address.

Integration of security code review into the System Development Life Cycle (SDLC) can yield dramatic results to the overall quality of the code developed. Security 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 defense-in-depth approach to application security. Security 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.

Waterfall SDLC Example

  1. Requirements definition
    1. Application Security Requirements
  2. Architecture and Design
    1. Application Security Architecture and/or Threat Model
  3. Development
    1. Secure Coding Practices
    2. Security Testing
    3. Security Code Review
  4. Test
    1. Penetration Testing
  5. Deployment
    1. Secure Configuration Management
    2. Secure Deployment
  6. Maintenance


Code Review - SDLC1.jpg

Agile Security Methodology Example

  1. Planning
    1. Identify Security Stakeholder Stories
    2. Identify Security Controls
    3. Identify Security Test Cases
  2. Sprints
    1. Secure Coding
    2. Security Test Cases
    3. Peer Review with Security
  3. Deployment
    1. Security Verification (with Penetration Testing and Security Code Review)


««Preparation«« Main
(Table of Contents) 		»»»»
Retrieved from "https://wiki.owasp.org/index.php?title=Security_Code_Review_in_the_SDLC&oldid=88945"