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 Review Metrics"

From OWASP
Jump to: navigation, search
Line 4: Line 4:
  
 
There are two distinct classes of software metrics:
 
There are two distinct classes of software metrics:
Relative and Absolute. Absolute metrics are numerical values that describe a trait of the code such as the number of references to a particular variable in an application, or the number of lines of code (LOC).  
+
Relative and Absolute.  
 +
*Absolute metrics are numerical values that describe a trait of the code such as the number of references to a particular variable in an application, or the number of lines of code (LOC).  
 
Absolute metrics, such as the number of lines of code, do not involve subjective context but are material fact.  
 
Absolute metrics, such as the number of lines of code, do not involve subjective context but are material fact.  
Relative metrics are a representation of an attribute that cannot be directly measured and are subjective and reliant on context of where the metric was derived. There is no definitive way to measure such an attribute. Multiple variables are factored into an estimation of the degree of testing difficulty, and any numeric representation or rating is only an approximation and is subjective.
+
*Relative metrics are a representation of an attribute that cannot be directly measured and are subjective and reliant on context of where the metric was derived. There is no definitive way to measure such an attribute. Multiple variables are factored into an estimation of the degree of testing difficulty, and any numeric representation or rating is only an approximation and is subjective.
  
Some Metric benefits:
+
===Some Metric benefits===
 
The objective of code review is to detect development errors which may cause vulnerabilities and hence give rise to an exploit.
 
The objective of code review is to detect development errors which may cause vulnerabilities and hence give rise to an exploit.
 
Code review can also be used to measure the progress of a development team in their practice of secure application development. It can pinpoint areas where the development practice is weak, areas where secure development practice is strong and give a security practitioner the ability to address the root cause of the weaknesses within a developed solution. It may give rise to investigation into software development policies and guidelines and the interpretation of them by the users, communcation is the key.
 
Code review can also be used to measure the progress of a development team in their practice of secure application development. It can pinpoint areas where the development practice is weak, areas where secure development practice is strong and give a security practitioner the ability to address the root cause of the weaknesses within a developed solution. It may give rise to investigation into software development policies and guidelines and the interpretation of them by the users, communcation is the key.
Line 21: Line 22:
  
 
* Fault Density:
 
* Fault Density:
** per Lines of code (LOC)
+
The average occurance of programming faults per Lines of code (LOC). This gives a high level view of the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric. Fault density would cover minor issues as well as major security flaws in the code, all are treated the same way. Security of code can not be judged accuratley using fault density alone.
:The count of executable lines of code. Commented-out code or spaces don't count.
+
 
 +
*Lines of code(LOC): The count of executable lines of code. Commented-out code or spaces don't count.
 +
Another metric in an attempt to quantify the size of the code. This gives a rough estimate but is not particularly scientific.
 +
 
  
 
** per Function Point:  
 
** per Function Point:  
:The combination of a number of statememts which e perform a specific task.
+
:The combination of a number of statememts which perform a specific task.
  
 
* Risk Density
 
* Risk Density

Revision as of 13:37, 2 July 2008

OWASP Code Review Guide Table of Contents

Introduction

There are two distinct classes of software metrics: Relative and Absolute.

  • Absolute metrics are numerical values that describe a trait of the code such as the number of references to a particular variable in an application, or the number of lines of code (LOC).

Absolute metrics, such as the number of lines of code, do not involve subjective context but are material fact.

  • Relative metrics are a representation of an attribute that cannot be directly measured and are subjective and reliant on context of where the metric was derived. There is no definitive way to measure such an attribute. Multiple variables are factored into an estimation of the degree of testing difficulty, and any numeric representation or rating is only an approximation and is subjective.

Some Metric benefits

The objective of code review is to detect development errors which may cause vulnerabilities and hence give rise to an exploit. Code review can also be used to measure the progress of a development team in their practice of secure application development. It can pinpoint areas where the development practice is weak, areas where secure development practice is strong and give a security practitioner the ability to address the root cause of the weaknesses within a developed solution. It may give rise to investigation into software development policies and guidelines and the interpretation of them by the users, communcation is the key.

Metrics can also be recorded relating to the performance of the code reviewers and the accuracy of the review process. The performance of the code review function and the efficiency & effectiveness of the code review function.

SCR Process.jpg


Secure Development Metrics

  • Fault Density:

The average occurance of programming faults per Lines of code (LOC). This gives a high level view of the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric. Fault density would cover minor issues as well as major security flaws in the code, all are treated the same way. Security of code can not be judged accuratley using fault density alone.

  • Lines of code(LOC): The count of executable lines of code. Commented-out code or spaces don't count.

Another metric in an attempt to quantify the size of the code. This gives a rough estimate but is not particularly scientific.


    • per Function Point:
The combination of a number of statememts which perform a specific task.
  • Risk Density
  • Defect correction rate
  • Path complexity/complexity-to-defect/cyclomatic complexity



Review Process Metrics

  1. Inspection Rate
  2. Defect detection Rate
  3. Code Coverage