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 "CRV2 ManualReviewProsCons"

From OWASP
Jump to: navigation, search
(Created page with "= Manual Review - Pros and Cons = Add content here ... == Benchmark of different Static Analysis Tools == Add content here .. == Advantages of Code Review to Development...")
 
(→‎Commerical static analysis tools: Minor update to correct a typo.)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= Manual Review - Pros and Cons =
 
= Manual Review - Pros and Cons =
  
−
Add content here ...
+
Manual review is sited when a risk based approach to the code review is required.
 +
Risk based code review works by.
  
 +
1. Identification of the trust boundaries in the code.
 +
2. Identification of data paths and storage classes.
 +
3. Identification of authorisation components.
 +
4. Identification of authentication components.
 +
5. Review of input validation and encoding methods.
 +
6. Review of logging components.
  
−
== Benchmark of different Static Analysis Tools ==
+
Manual review is good for :
  
−
Add content here ..
+
Data leakage detection
 +
Resource usage/exhaustion detection
 +
Business Logic review*
 +
Denial of service
 +
Deep Dive review
  
 +
'''Not so good for:'''
 +
Business Logic review*
 +
Level of coverage
  
−
== Advantages of Code Review to Development Practices ==
+
== Choosing a static analysis tool ==
  
−
Expand upon the following points, stress that some depend upon the code review procedure/tool used
+
Choosing a static analysis tool is a difficult task since there are a lot of choices. The comparison charts below should help you decide which tool is right for you. This list is not exhaustive.
 +
The first thing to do is to look to for a tool that supports the programming language of your choice. You also have to decide whether you want a commercial tool or a free one. Usually the commercial tools have more features and are more reliable than the free ones. The major commercial tools are equally effective but their usability might differ. Next, there is the type of analysis you are looking for: Security or Quality, Static or Dynamic analysis. You should also check the compatibility of the tool with your programming environment.
 +
This was the easy part to narrow the choice down to a few tools. The next step requires you to do some work since it is quite subjective. The best thing to do is to test a few tools to see if you are satisfied with different aspects such as the user experience, the reporting of vulnerabilities, the level of false positives, the customization, the customer support… The choice should not be based on the number of features, but on the features that you need and how they could be integrated in your SDLC. Also, before choosing the tool, the security expertise of the targeted users should be clearly evaluated in order to choose an appropriate tool.
  
−
# Can provide developers (especially code maintainers) with an historical record of code changes
+
 
−
## As well as code review containing the code, it should also have the Functional Specs, Design Specs, etc included/linked so the reviewers know the context of the change.
+
=== '''Free static analysis tools''' ===
−
## After code review is done, and code submitted, the code review procedure/tool should store these details for future reference.  If/When years later some different developer wants to work in the same area (and the original developer has moved on) they have a record of the change made, along with review comments & decisions.
+
 
−
# Code review should also describe the testing (unit, component, manual, etc) that was done to verify the change, allows reviewers to be confident the developer tested the change in the right way.
+
[[File:Free_static_analysis_tools.png]]
−
# Junior developers can learn from senior developers during code review.  After you learn the basics of a language and read a few of the best practices book, how can you get good on-the-job skills to learn more... well code review can provide that.  Apart from buddy coding (which rarely happens) code review is the best place for junior developers to see how the experienced guys do it.
+
[[File:legendfree.png]]
−
# Developers can become more familiar with the code base.  Two examples of this, 1) someone (or team) creates a new functional area, then code review allows others who may use that code in the future to become familiar with it, or 2) some cross pollination for silo'ed teams, where they reach out to other teams to review their code, everyone then learns a bit more about the company's code.
+
 
−
# This happens less frequently, but does happen, people can spot potential clashes.  Person 1 and 2 are working in and around the same area of code, person 1 is going to put their change in 1st, so includes person 2 on the review so person 2 can know if it's going to clash with the code they're about to submit next week.
+
=== '''Commerical static analysis tools''' ===
−
# Code can be reviewed against guidelines. If the company creates guidelines for coding, security, performance, logging, etc, the code review is the place to ensure those guidelines are followed. I.e. a piece of code that may do the job fine, could be rejected because it does not adhere to the coding guidelines.  Maybe doesn't matter much for standard code, but for code associated with secure interfaces, this is where the OWASP top 10 could be enforced.
+
 
 +
[[File:Commercial_static_analysis_tools.png]]
 +
[[File:legendstatic.png]]
 +
 
 +
[[File:Owasp_Benchmark_Static_analysis_tools_1.1.pptx]]

Latest revision as of 09:23, 3 September 2015

Manual Review - Pros and Cons

Manual review is sited when a risk based approach to the code review is required. Risk based code review works by.

1. Identification of the trust boundaries in the code. 2. Identification of data paths and storage classes. 3. Identification of authorisation components. 4. Identification of authentication components. 5. Review of input validation and encoding methods. 6. Review of logging components.

Manual review is good for :

Data leakage detection Resource usage/exhaustion detection Business Logic review* Denial of service Deep Dive review

Not so good for: Business Logic review* Level of coverage

Choosing a static analysis tool

Choosing a static analysis tool is a difficult task since there are a lot of choices. The comparison charts below should help you decide which tool is right for you. This list is not exhaustive. The first thing to do is to look to for a tool that supports the programming language of your choice. You also have to decide whether you want a commercial tool or a free one. Usually the commercial tools have more features and are more reliable than the free ones. The major commercial tools are equally effective but their usability might differ. Next, there is the type of analysis you are looking for: Security or Quality, Static or Dynamic analysis. You should also check the compatibility of the tool with your programming environment. This was the easy part to narrow the choice down to a few tools. The next step requires you to do some work since it is quite subjective. The best thing to do is to test a few tools to see if you are satisfied with different aspects such as the user experience, the reporting of vulnerabilities, the level of false positives, the customization, the customer support… The choice should not be based on the number of features, but on the features that you need and how they could be integrated in your SDLC. Also, before choosing the tool, the security expertise of the targeted users should be clearly evaluated in order to choose an appropriate tool.


Free static analysis tools

Free static analysis tools.png Legendfree.png

Commerical static analysis tools

Commercial static analysis tools.png Legendstatic.png

File:Owasp Benchmark Static analysis tools 1.1.pptx

Retrieved from "https://wiki.owasp.org/index.php?title=CRV2_ManualReviewProsCons&oldid=199939"