CRV2 ManualReviewProsCons - Revision history

Zyad MGHAZLI: /* Commerical static analysis tools */ Minor update to correct a typo.

2015-09-03T09:23:13Z

‎Commerical static analysis tools: Minor update to correct a typo.

Zyad MGHAZLI: /* Commerical static analysis tools */

2015-09-03T09:22:27Z

‎Commerical static analysis tools

Zyad MGHAZLI: /* Free static analysis tools */

2015-09-03T09:21:54Z

‎Free static analysis tools

EoinKeary: /* Manual Review - Pros and Cons */

2013-12-12T14:29:24Z

‎Manual Review - Pros and Cons

EoinKeary: /* Manual Review - Pros and Cons */

2013-10-03T15:59:26Z

‎Manual Review - Pros and Cons

MGHAZLI Zyad: Choosing a static analysis tool

2013-08-08T08:22:05Z

Choosing a static analysis tool

MGHAZLI Zyad at 08:03, 8 August 2013

2013-08-08T08:03:04Z

Gary David Robinson: Replaced content with "= Manual Review - Pros and Cons = Add content here ... == Benchmark of different Static Analysis Tools == Add content here .."

2013-08-05T15:06:57Z

Replaced content with "= Manual Review - Pros and Cons = Add content here ... == Benchmark of different Static Analysis Tools == Add content here .."

Gary David Robinson at 14:26, 5 August 2013

2013-08-05T14:26:35Z

Gary David Robinson at 13:58, 5 August 2013

2013-08-05T13:58:00Z

← Older revision		Revision as of 09:23, 3 September 2015
Line 40:		Line 40:
	[[File:legendstatic.png]]		[[File:legendstatic.png]]

−	[[File:~~Owasp_Benchmark_Static_analysis_tools~~.pptx]]	+	[[File:Owasp_Benchmark_Static_analysis_tools_1.1.pptx]]

@@ Line 38: / Line 38: @@
 [[File:Commercial_static_analysis_tools.png]]
-[[File:Legend Commercial static analysis tools.png]]
+[[File:legendstatic.png]]
 [[File:Owasp_Benchmark_Static_analysis_tools.pptx]]

@@ Line 33: / Line 33: @@
 [[File:Free_static_analysis_tools.png]]
-[[File:Legend_free_static_analysis_tools.png]]
+[[File:legendfree.png]]
 === '''Commerical static analysis tools''' ===

@@ Line 10: / Line 10: @@
 . Review of input validation and encoding methods.
 . Review of logging components.
 Manual review is good for :
@@ Line 25: / Line 22: @@
 Business Logic review*
 Level of coverage
 == Choosing a static analysis tool ==

← Older revision		Revision as of 15:59, 3 October 2013
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.
		+
		+
		+	<more description is required here>
		+
		+	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
		+
		+
		+
		+
		+
		+
		+

← Older revision		Revision as of 08:22, 8 August 2013
Line 9:		Line 9:
	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.		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.		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''' ===
		+
		+	[[File:Free_static_analysis_tools.png]]
		+	[[File:Legend_free_static_analysis_tools.png]]
		+
		+	=== '''Commerical static analysis tools''' ===
		+
		+	[[File:Commercial_static_analysis_tools.png]]
		+	[[File:Legend Commercial static analysis tools.png]]
		+
		+	[[File:Owasp_Benchmark_Static_analysis_tools.pptx]]

← Older revision		Revision as of 08:03, 8 August 2013
Line 4:		Line 4:


−	== ~~Benchmark of different Static Analysis Tools~~ ==	+	== Choosing a static analysis tool ==

−	~~Add content here~~ ..	+	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.

← Older revision		Revision as of 15:06, 5 August 2013
Line 7:		Line 7:

	Add content here ..		Add content here ..
−
−
−	~~== Advantages of Code Review to Development Practices ==~~
−
−	Integrating code review into your companies development processes can have many benefits that will be explored below. Some of these benefits depend upon the tools you use to perform code reviews, how well that data is backed up, and how well those tools are used. The days of bringing developers into a room and displaying code on a projector, whilst recording the review results on a printed copy and behind us, many tools exist to make code review more efficient and to track the review records/decisions. When the code review process is structured correctly, the act of reviewing code can provide educational, auditable and historical benefits to any organization.
−
−	~~The following provides a list of benefits that a code review procedure can add to development team.~~
−
−	~~=== Provides an Historical Record ===~~
−
−	If any developer has joined a company, or moved teams within a company, and had to maintain or enhance a piece of code written years ago, one of the biggest frustrations can be the lack of context the new developer has on the code. Various schools of opinion exist on code documentation, both within the code (comments) and external to the code (design/functional docs, wikis, etc), opinions ranging from zero-documentation tollerance through to near-NASA level documentation where the size of the documentation far exceeds the size of the code module.
−
−	If you think about the discussions that occur during a code review, many of these discussions, if recorded, would provide valuable information (context) to module maintainers and new programmers. From the writer describing the module along with some of their design decisions, to each reviewers comments, stating why they think one SQL query should be restructured, or an algorithm changed, there is a development story unfolding in front of the reviewers eyes which can (and should) be used by future coders on the module, who are probably not involved in the review meetings.
−
−	Capturing those review discussions in a review tool automatically, and storing them for future reference, will provide the development organization with a history of the changes on the module which can be queried at a later time by new developers. These discussions can also contain links to any architectural/functional/design/test specifications, bug or enhancement numbers, etc.
−
−	~~=== Verification Change has been Tested ===~~
−
−	When a developer is about to submit code into the repository, how do you know they have sufficiently tested it? Adding a description of the tests they have run (manually or automated) against the changed code can give reviewers (and managment) confidence that the change will work and not cause any regressions. Also by declaring the tests the writer has ran against their change, the author is allowing reviewers to suggest further testing that may have been missed by the author.
−
−	In a development scenario where automated unit or component testing exists, the coding guidelines can require the developer include those unit/component tests in the code review. This again allows reviewers within this type of automated environment to ensure the correct unit/component tests are going to be included in the environment, keeping the quality of the continious intergration.
−
−	~~=== Coding Education for Junior Developers ===~~
−
−	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? Besides buddy coding (which rarely happens and is never cost effective) and training sessions (brown bag sessions on coding, tech talks, etc) the design and code decisions discussed during a code review can be a learning experiance for junior developers. Many experianced developers may admit to this being a two way street, where new developers can come in with new ideas or tricks that the older developers can learn from. Altogether this cross polination of experiance and ideas can only be beneficial to a development organization.
−
−	~~=== Familiarization with Code Base ===~~
−
−	When a new feature is developed, it is often integrated with the main code base, and here code review can be a conduit for the wider team to learn about the new feature and how it's code will impact the wider product. This helps prevent functional duplication where separate teams end up coding the same small piece of functionality.
−
−	This also applies for development environments with silo'ed teams. Here the code review author can reach out to other teams to gain their insight, and allow those other teams to review their code, and everyone then learns a bit more about the company's code.
−
−	~~=== Pre-warning of Integration Clashes ===~~
−
−	In a busy code base there will be times (especially on core code) where multiple developers can be writing code affecting the same module. Many people have had the experiance of cutting the code and running the tests, only to discover upon submission that some other change has modified the functionality, requiring the author to recode and retest some aspects of their change. Spreading the word on upcoming changes via code reviews gives a greater chance of a developer learning that a change is about to impact their upcoming commit, and development timelines, etc, can be updated accordingly.
−
−	~~=== Coding Guidelines Touchpoint ===~~
−
−	Many development environments have coding guidelines which new code must adhere to. Coding guidelines can take many forms, but it's worth pointing out that security guidelines can be a particularly relevant touchpoint within a code review as unfortunately, though typically, the security issues are understood by a subset of the development team. Therefore it can be possible to include teams with various technical expertise into the code reviews, i.e. someone from the security team (or that person in the corner who knows all the security stuff) can be invited as a technical subject expert to the review to check the code from their particular angle. This is where the OWASP top 10 could be enforced.

@@ Line 29: / Line 29: @@
 In a development scenario where automated unit or component testing exists, the coding guidelines can require the developer include those unit/component tests in the code review.  This again allows reviewers within this type of automated environment to ensure the correct unit/component tests are going to be included in the environment, keeping the quality of the continious intergration.
-# 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.
+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?  Besides buddy coding (which rarely happens and is never cost effective) and training sessions (brown bag sessions on coding, tech talks, etc) the design and code decisions discussed during a code review can be a learning experiance for junior developers.  Many experianced developers may admit to this being a two way street, where new developers can come in with new ideas or tricks that the older developers can learn from.  Altogether this cross polination of experiance and ideas can only be beneficial to a development organization.
-# 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.
+=== Familiarization with Code Base ===
-# 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.