Difference between revisions of "Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY"

From OWASP
Jump to: navigation, search
Line 11: Line 11:
 
* TRACK and TRIAGE findings from these activities with the same urgency as failed baseline builds and user-reported bugs.  
 
* TRACK and TRIAGE findings from these activities with the same urgency as failed baseline builds and user-reported bugs.  
  
Doing the above will have meant that both management and development teams will have have made a commitment to the security of their applications. The management team will have provided the necessary FUNDING and MANDATE for the security team. The development team will have figured out (1)WHEN to most effectively perform code reviews and verification activities, and (2)HOW to triage security-related findings.
+
Doing the above will have meant that both management and development teams will have have made a commitment to the security of their applications. The management team will have provided the necessary FUNDING and MANDATE for the security team based on how it is decided that reviews will be added into the SDLC. The development team will have figured out the mechanics of (1)WHEN to most effectively perform code reviews and verification activities, and (2)HOW to triage security-related findings.
  
 
For an example of how to add code reviews and other types of verification activities to an SDLC, see: http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories
 
For an example of how to add code reviews and other types of verification activities to an SDLC, see: http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories

Revision as of 09:59, 23 July 2009

Fix-now.gif

Performing code reviews and other types of verification activities such as security testing is USELESS unless findings from these activities are acted upon IMMEDIATELY by the development team. Failure to act in a timely manner makes attempting fixes much more difficult than they otherwise would have been if action had been taken immediately, or simply not possible.

How can fixing what development teams may at first glance see as mere "bugs" become so much harder or not possible? As time goes on and as development actively continues, code where findings were originally found becomes unrecognizable as it is branched and refactored, and as new (unexamined) code (with potential new findings) is added to branches and the baseline.

In these cases, a new code review or verification becomes necessary. As one might expect however, performing a new code review or verification activity out of necessity in these cases further sets back budgets and timelines. Worse, in the meanwhile, your application AND the data AND systems that it relies on and that it talks to REMAIN VULNERBLE TO ATTACK.

How can one guard against reports from security teams going stale? There are two specific actions that management and development teams can take:

  • ADD code reviews and other types of verification activities as a REGULAR activity during YOUR development life cycle, and
  • TRACK and TRIAGE findings from these activities with the same urgency as failed baseline builds and user-reported bugs.

Doing the above will have meant that both management and development teams will have have made a commitment to the security of their applications. The management team will have provided the necessary FUNDING and MANDATE for the security team based on how it is decided that reviews will be added into the SDLC. The development team will have figured out the mechanics of (1)WHEN to most effectively perform code reviews and verification activities, and (2)HOW to triage security-related findings.

For an example of how to add code reviews and other types of verification activities to an SDLC, see: http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories

For more information about code reviews and other types of verification activities, see: http://www.owasp.org/index.php/ASVS