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 Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY"
Deleted user (talk | contribs) |
Deleted user (talk | contribs) |
||
| 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 the management team will have provided the necessary funding AND MANDATE for the security team by allowing the SDLC to be opened up to the addition of a new activity | + | Doing the above will have meant that the management team will have provided the necessary funding AND MANDATE for the security team by allowing the SDLC to be opened up to the addition of a new activity. Doing the above will have meant that the development team will have taken the necessary actions to figure out the mechanics of same. |
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 15:11, 23 July 2009
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 the management team will have provided the necessary funding AND MANDATE for the security team by allowing the SDLC to be opened up to the addition of a new activity. Doing the above will have meant that the development team will have taken the necessary actions to figure out the mechanics of same.
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
