OWASP - User contributions [en]

Steps and Roles

2006-06-29T11:50:12Z

Jwalden:

[[OWASP Code Review Guide Table of Contents]]__TOC__

==Roles==

Code reviews are carried out by personnel in four roles: author, moderator, reader, and scribe. There are typically reviewers who are simply inspectors, focused on finding defects in the code, who do not fit in any of the four roles. Depending on the size of your inspection team and the formality of your inspection process, some people may serve in multiple roles at the same time. However, if you have a large enough team, it is useful to assign each role to a different person so each person can focus on their duties.

#'''Moderator''': The Moderator is the key role in a code review. The moderator is responsible for selecting a team of reviewers, scheduling the code review meeting, conducting the meeting, and working with the author to ensure that necessary corrections are made to the reviewed document.
#'''Author''': The Author wrote the code that is being reviewed. The author is responsible for starting the code review process by finding a Moderator. The role of Author must be separated from that of Moderator, Reader, or Recorder to ensure the objectivity and effectiveness of the code review. However, the Author serves an essential role in answering questions and making clarifications during the review and making corrections after the review.
#'''Reader''': The Reader presents the code during the meeting by paraphrasing it in his own words. It's important to separate the role of Reader from Author, because it's too easy for an author to explain what he meant the code to do instead of explaining what it actually does. The reader's interpretation of the code can reveal ambiguities, hidden assumptions, poor documentation and style, and other errors that the Author would not be likely to catch on his own.
#'''Scribe''': The Scribe records all issues raised during the code review. Separating the role of Scribe from the other roles allows the other reviewers to focus their entire attention on the code.

==Steps==

Code reviews consist of the following four steps:

#'''Initialization''': The Author informs a Moderator that a deliverable will be ready for inspection in the near future. The Moderator selects a team of inspectors and assigns roles to them. The Author and the Moderator together prepare a review package consisting fo the code to be reviewed, documentation, review checklists, coding rules, and other materials such as the output of static analysis tools. The Moderator will announce the time, place, and duration for the code review meeting.
#'''Preparation''': After receiving the review package, the inspectors study the code individually to search for defects. Preparation should take about as long as the duration of the meeting. Some less formal code review techniques skip the preparation phase.
#'''Meeting''': The Moderator initiates the meeting, then the Reader describes the code to the participants. After each segment of code is presented, reviewers will bring up any issues they found during Preparation or discovered during the meeting. The interaction between reviewers during the meeting will usually bring up issues that were not discovered during the Preparation step. The Scribe notes each defect with enough detail for the Author to address it afterwards. It is the responsibility of the Moderator to keep the meting focused on defects, ensuring that the participants do not attempt to produce solutions during the meeting instead. Some less formal code review steps skip the meeting phase, choosing instead to e-mail the code to one or more reviewers who return comments without ever meeting as a group.
#'''Corrections''': The Author addresses the defects recorded during the meeting, and the Moderator checks the corrections to ensure that all problems are resolved. If the number of defects raised was large, the Moderator may decide to schedule a review of the revised code.

Steps and Roles

2006-06-29T11:37:02Z

Jwalden:

[[OWASP Code Review Guide Table of Contents]]__TOC__

==Steps==

Code reviews consist of the following four steps:

#Initialization
#Preparation
#Meeting
#Corrections

==Roles==

Code reviews are carried out by personnel in four roles: author, moderator, reader, and recorder. Depending on the size of your inspection team and the formality of your inspection process, some people may serve in multiple roles at the same time. However, if you have a large enough team, it is useful to assign each role to a different person so each person can focus on their duties.

#'''Moderator''': The Moderator is the key role in a code review. The moderator is responsible for selecting a team of reviewers, scheduling the code review meeting, conducting the meeting, and working with the author to ensure that necessary corrections are made to the reviewed document.
#'''Author''': The Author wrote the code that is being reviewed. The author is responsible for starting the code review process by finding a Moderator. The role of Author must be separated from that of Moderator, Reader, or Recorder to ensure the objectivity and effectiveness of the code review. However, the Author serves an essential role in answering questions and making clarifications during the review and making corrections after the review.
#'''Reader''': The Reader presents the code during the meeting by paraphrasing it in his own words. It's important to separate the role of Reader from Author, because it's too easy for an author to explain what he meant the code to do instead of explaining what it actually does. The reader's interpretation of the code can reveal ambiguities, hidden assumptions, poor documentation and style, and other errors that the Author would not be likely to catch on his own.
#'''Scribe''': The Scribe records all issues raised during the code review. Separating the role of Scribe from the other roles allows the other reviewers to focus their entire attention on the code.

References

2006-06-28T12:45:20Z

Jwalden: /* References */

[[OWASP Code Review Guide Table of Contents]]__TOC__

==References==

# Brian Chess and Gary McGraw. "Static Analysis for Security," ''IEEE Security & Privacy'' 2(6), 2004, pp. 76-79.
# M. E. Fagan. "Design and Code Inspections to Reduce Errors in Program Development," ''IBM Systems J.'' 15(3), 1976, pp. 182-211.
# Tom Gilb and Dorothy Graham. ''Software Inspection''. Addison-Wesley, Wokingham, England, 1993.
# Michael Howard and David LeBlanc. ''Writing Secure Code, 2nd edition''. Microsoft Press, Redmond, WA, 2003.
# Gary McGraw. ''Software Security''. Addison-Wesley, Boston, MA, 2006.
# Diomidis Spinellis. ''Code Reading: The Open Source Perspective''. Addison-Wesley, Boston, MA, 2003.
# John Viega and Gary McGraw. ''Building Secure Software: How to Avoid Security Problems the Right Way.'' Addison-Wesley, Boston, MA, 2001.
# Karl E. Wiegers. ''Peer Reviews in Software''. Addison-Wesley, Boston, MA, 2002.

[[Category:OWASP Code Review Project]]

Steps and Roles

2006-06-28T12:42:38Z

Jwalden:

OWASP Code Review Guide Table of Contents

2006-06-28T12:35:46Z

Jwalden:

==[[Code Review Introduction|Introduction]] ==
==[[Steps and Roles]]==
==[[Code Review Processes]]==
==Checklists==
#[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]]
#[[OS Injection]]
#[[SQL Injection]]
#[[Data Validation (Code Review)|Data Validation]]
#[[Error Handling]]
#[[The Secure Code Environment]]
#[[Transaction Analysis]]
==[[Automating Code Reviews]] ==
==[[References]]==

[[Category:OWASP Code Review Project]]

References

2006-06-28T12:34:19Z

Jwalden:

[[OWASP Code Review Guide Table of Contents]]__TOC__

==References==

# Brian Chess and Gary McGraw. "Static Analysis for Security," ''IEEE Security & Privacy'' 2(6), 2004, pp. 76-79.
# M. E. Fagan. "Design and Code Inspections to Reduce Errors in Program Development," ''IBM Systems J.'' 15(3), 1976, pp. 182-211.
# Tom Gilb and Dorothy Graham. ''Software Inspection''. Addison-Wesley, Wokingham, England, 1993.
# Michael Howard and David LeBlanc. ''Writing Secure Code, 2nd edition''. Microsoft Press, Redmond, WA, 2003.
# Gary McGraw. ''Software Security''. Addison-Wesley, Boston, MA, 2006.
# John Viega and Gary McGraw. ''Building Secure Software: How to Avoid Security Problems the Right Way.'' Addison-Wesley, Boston, MA, 2001.
# Karl E. Wiegers. ''Peer Reviews in Software''. Addison-Wesley, Boston, MA, 2002.

[[Category:OWASP Code Review Project]]

Security Code Review in the SDLC

2006-06-28T12:32:42Z

Jwalden:

[[OWASP Code Review Guide Table of Contents]]__TOC__

==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:

# Ad hoc review
# Passaround
# Pair programming
# Walkthrough
# Team review
# Inspection

OWASP Code Review Guide Table of Contents

2006-06-28T12:27:07Z

Jwalden:

==[[Code Review Introduction|Introduction]] ==
==[[Code Review Processes]]==
==Checklists==
#[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]]
#[[OS Injection]]
#[[SQL Injection]]
#[[Data Validation (Code Review)|Data Validation]]
#[[Error Handling]]
#[[The Secure Code Environment]]
#[[Transaction Analysis]]
==[[Automating Code Reviews]] ==
==[[References]]==

[[Category:OWASP Code Review Project]]

References

2006-06-28T12:10:52Z

Jwalden:

# Brian Chess and Gary McGraw. "Static Analysis for Security," ''IEEE Security & Privacy'' 2(6), 2004, pp. 76-79.
# M. E. Fagan. "Design and Code Inspections to Reduce Errors in Program Development," ''IBM Systems J.'' 15(3), 1976, pp. 182-211.
# Tom Gilb and Dorothy Graham. ''Software Inspection''. Addison-Wesley, Wokingham, England, 1993.
# Michael Howard and David LeBlanc. ''Writing Secure Code, 2nd edition''. Microsoft Press, Redmond, WA, 2003.
# Gary McGraw. ''Software Security''. Addison-Wesley, Boston, MA, 2006.
# John Viega and Gary McGraw. ''Building Secure Software: How to Avoid Security Problems the Right Way.'' Addison-Wesley, Boston, MA, 2001.
# Karl E. Wiegers. ''Peer Reviews in Software''. Addison-Wesley, Boston, MA, 2002.

[[Category:OWASP Code Review Project]]

OWASP Code Review Guide Table of Contents

2006-06-28T12:10:39Z

Jwalden:

OWASP Code Review Guide Table of Contents

2006-06-28T12:09:58Z

Jwalden: /* References */

==[[Code Review Introduction|Introduction]] ==

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

==[[OS Injection]] ==

==[[SQL Injection]] ==

==[[Data Validation (Code Review)|Data Validation]] ==
==[[Error Handling]]==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[Automating Code Reviews]] ==
==[[References]]==
# Brian Chess and Gary McGraw. "Static Analysis for Security," ''IEEE Security & Privacy'' 2(6), 2004, pp. 76-79.
# M. E. Fagan. "Design and Code Inspections to Reduce Errors in Program Development," ''IBM Systems J.'' 15(3), 1976, pp. 182-211.
# Tom Gilb and Dorothy Graham. ''Software Inspection''. Addison-Wesley, Wokingham, England, 1993.
# Michael Howard and David LeBlanc. ''Writing Secure Code, 2nd edition''. Microsoft Press, Redmond, WA, 2003.
# Gary McGraw. ''Software Security''. Addison-Wesley, Boston, MA, 2006.
# John Viega and Gary McGraw. ''Building Secure Software: How to Avoid Security Problems the Right Way.'' Addison-Wesley, Boston, MA, 2001.
# Karl E. Wiegers. ''Peer Reviews in Software''. Addison-Wesley, Boston, MA, 2002.

[[Category:OWASP Code Review Project]]

OWASP Code Review Guide Table of Contents

2006-06-28T11:52:01Z

Jwalden:

Automated Code Review

2006-06-28T11:50:25Z

Jwalden:

[[OWASP Code Review Guide Table of Contents]]__TOC__

==Preface==

While manual code reviews can find security flaws in code, they suffer from two problems. Manual code reviews are slow, covering 100-200 lines per hour on average. Also, there are hundreds of security flaws to look for in code, while humans can only keep about seven items in memory at once. Source code analysis tools can search a program for hundreds of different security flaws at once at a rate far greater than any human can review code. However, these tools don't eliminate the need for a human reviewer, as they produce both false positive and false negative results.

[[Category:OWASP Code Review Project]]

OWASP Code Review Guide Table of Contents

2006-06-28T11:42:40Z

Jwalden: