How to Write an Application Code Review Finding - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:55:22Z

Added navigation to facilitate sequential reading online

KirstenS: /* Sample Report */

2009-02-11T10:47:34Z

‎Sample Report

KirstenS: /* Use a positive tone */

2009-01-15T21:38:13Z

‎Use a positive tone

Show changes

KirstenS at 21:36, 15 January 2009

2009-01-15T21:36:34Z

KirstenS: How to write an application security finding moved to How to Write an Application Code Review Finding

2009-01-15T21:31:05Z

How to write an application security finding moved to How to Write an Application Code Review Finding

KirstenS: /* Choose a great title */

2008-09-18T12:26:49Z

‎Choose a great title

KirstenS: /* Choose a great title */

2008-09-06T15:16:30Z

‎Choose a great title

Jeff Williams at 15:10, 23 November 2007

2007-11-23T15:10:16Z

EoinKeary at 16:12, 2 August 2007

2007-08-02T16:12:41Z

Mmeucci at 15:10, 3 January 2007

2007-01-03T15:10:16Z

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
 An application security "finding" is how an application security team communicates information to a software development organization. Findings may be vulnerabilities, architectural problems, organization problems, failure to follow best practices or standards, or "good" practices that deserve recognition.
@@ Line 163: / Line 168: @@
 [[Category:How To]]
 [[Category:OWASP Code Review Project]]

@@ Line 38: / Line 38: @@
 ==Sample Report==
-Below is a sample format for a finding report resulting from a secure code review
+Below is a sample format for a finding report resulting from a secure code review.
 <!--

@@ Line 1: / Line 1: @@
-'''How to write an application security finding'''
+[[OWASP Code Review Guide Table of Contents]]__TOC__
 An application security "finding" is how an application security team communicates information to a software development organization. Findings may be vulnerabilities, architectural problems, organization problems, failure to follow best practices or standards, or "good" practices that deserve recognition.
-==Choose a great title==
+==Choose a Great Title==
-When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as "Add access control to business logic" or "Encode output to prevent [[Cross-site Scripting (XSS)]].
+==Identify the Location of the Vulnerability==
 The finding should be as specific as possible about the location in both the code and as a URL. If the finding represents a pervasive problem, then the location should provide many examples of actual instances of the problem.
 ==Detail the vulnerability==
 The finding should provide enough detail about the problem that anyone can:
 * understand the vulnerability
 * understand possible attack scenarios
 * know the key factors driving likelihood and impact
-==Discuss the risk==
+==Discuss the Risk==
 There is value in both assigning a qualitative value to each finding and further discussing why this value was assigned. Some possible risk ratings are:
 * Critical
 * High
@@ Line 26: / Line 22: @@
 * Low
 Justifying the assigned risk ratings is very important. This will allow stakeholders (especially non-technical ones) to gain more of an understanding of the issue at hand. Two key points to identify are:
 * Likelihood (ease of discovery and execution)
 * Business/Technical impact
-You should have a standard methodology for rating risks in your organization. The [[How to value the real risk|OWASP Risk Rating Methodology]] is a comprehensive method that you can tailor for your organization's priorities.
+You should have a standard methodology for rating risks in your organization. The  [[How to value the real risk|OWASP Risk Rating Methodology]] is a comprehensive method that you can tailor for your organization's priorities.
-==Suggest remediations==
+==Suggest Remediations==
 * alternatives
 * include effort required
 * discuss residual risk
-==Include references==
+==Include References==
 * Important note: if you use OWASP materials for any reason, you must follow the terms of our license

@@ Line 5: / Line 5: @@
 ==Choose a great title==
-When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as "Add access control to business logic" or "Encode output to prevent [[Cross-site scripting]].
+When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as "Add access control to business logic" or "Encode output to prevent [[Cross-site Scripting (XSS)]].
 ==Identify the location of the vulnerability==

@@ Line 5: / Line 5: @@
 ==Choose a great title==
-When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as "Add access control to business logic" or "Encode output to prevent [[XSS]].
+When writing an application security finding, you should choose a title that captures the issue clearly, succinctly, and convincingly for the intended audience. In general, it's best to phrase the title in a positive way, such as "Add access control to business logic" or "Encode output to prevent [[Cross-site scripting]].
 ==Identify the location of the vulnerability==

← Older revision	Revision as of 21:31, 15 January 2009
(No difference)

← Older revision		Revision as of 15:10, 3 January 2007
Line 65:		Line 65:

	[[Category:How To]]		[[Category:How To]]
−	~~[[Category:OWASP Testing Project]]~~
	[[Category:OWASP Code Review Project]]		[[Category:OWASP Code Review Project]]