Difference between revisions of "Security Code Review in the SDLC"

From OWASP
Jump to: navigation, search
m (Minimal Resource Available Code Review for Web Applications Model)
(capitalization, extra spaces, paren)
Line 20: Line 20:
  
 
'''Waterfall SDLC exmaple'''
 
'''Waterfall SDLC exmaple'''
#Requirements definition                
+
# Requirements definition
 
## Functional specification
 
## Functional specification
#Design
+
# Design
## Detailed design specification        
+
## Detailed design specification
#Development
+
# Development
##Coding                                
+
## Coding
## Unit test                           
+
## Unit tests
#Test
+
# Test
##functional Testing                     
+
## Functional testing
 
## System testing
 
## System testing
##integration testing                    
+
## Integration testing
##UAT (User acceptance testing
+
## UAT (User acceptance testing)
#Deployment
+
# Deployment
 
## Change control
 
## Change control
 
# Maintenance
 
# Maintenance

Revision as of 12:59, 19 November 2007

OWASP Code Review Guide Table of Contents

Contents


Preface

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, 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


Mature Secure Code Review (SCR) Model

Throughout the SDLC there are points at which an application security consultant should get involved. These points, "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 total cost of ownership (TCO) is less in the long term.

Waterfall SDLC exmaple

  1. Requirements definition
    1. Functional specification
  2. Design
    1. Detailed design specification
  3. Development
    1. Coding
    2. Unit tests
  4. Test
    1. Functional testing
    2. System testing
    3. Integration testing
    4. UAT (User acceptance testing)
  5. Deployment
    1. Change control
  6. Maintenance


Minimal Resource Available Code Review for Web Applications Model

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.

Manual Code Review should at LEAST focus on:

  1. Authorization
  2. Access Control
  3. Input Validation
  4. Error Handling
  5. Session Management
  6. Form Keys or Frequent Session Rotation (for CSRF defense)
  7. Proper Application Logging