Difference between revisions of "How to Write an Application Code Review Finding"

From OWASP
Jump to: navigation, search
(Use a positive tone)
(Sample Report)
Line 38: Line 38:
 
==Sample Report==
 
==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.
  
 
<!--
 
<!--

Revision as of 05:47, 11 February 2009

OWASP Code Review Guide Table of Contents

Contents


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

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

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
  • Moderate
  • 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 OWASP Risk Rating Methodology is a comprehensive method that you can tailor for your organization's priorities.

Suggest Remediations

  • alternatives
  • include effort required
  • discuss residual risk

Include References

  • Important note: if you use OWASP materials for any reason, you must follow the terms of our license

Sample Report

Below is a sample format for a finding report resulting from a secure code review.




Review /Engagement reference:

Package/Component/Class Name

 

Finding description

Location(S)

Severity

Recommendation

 

No input validation of the HTTPRequest object.getID() function.

 

Lack of input validation may make the application vulnerable to many types of injection

 

com.inc.dostuff.java

Lines 20, 55,106

 

com.inc.main.java

Lines 34, 99

 

Critical

 

Required □

 

Recommended □

 

Informational □

 

 

It is critical that this be addressed prior to deployment to production