[ OWASP - Montreal ] Subject: Crucible - Team Code Review Tool

[Hugo.Fortier]

My question was sort of  managerial and technical. It was about
techniques to optimize the Management of a Source Code review.
 
While there is many tools to analyze code, there is very few tools that
keep track of what you are doing. I work on source code review projects
containing sometime over a million lines of code. So far I have found no
good tools that would help me easily keep track of what I am doing, so I
have my own internal tools to do it but I am looking into what other
people are doing to solve theses problems and also what are the problem
they are facing so that I can find solution for them and integrate them
in my tools.

If I record everything I am doing in a Excel sheet, it 'double' the time
it take me and it's still very hard to make sense of the excel sheet
anyway(been there done that). Many Source Code reviewer work with Excel
sheet, but it just make no sense for me.

What I want to know:
Which modules I have looked at and how long I looked at them, at which
dates and times I looked at them.
Which modules I found issue in.
Mark the type of functionality in the different part of the code so that
I can link those part of code into the Threat Model easily and
prioritize code to be audited based on Call Graph and Risk.

And I want to do that in a transparent way so that I don't have to get
my focus out of the code to update a huge Excel sheet.

So basically I want a Audit Trail of what I am doing while looking at
the code, analyze the patterns, generate statistic and detect which part
of the code I neglected to take better decision on which part of the
code I should priorize next. If you realised that at this date I did't
find anything in any of the code,  You can push those part of the code
to be  reviewed again later or you cross reviewed the code at a other
date and find stuff, you can establish that you where not at your prime
when reviewing some part of the code and that this code need to be
looked at again by you or by a other auditor.

A other key issue is I need my coworker to be able to monitor what I am
doing so that we don't duplicate work and that if I find a module more
fragile they also double check that module.

Most tools are geared toward Automated Code Review, while those tools
are very good at finding some type of bugs, they have epic fail finding
bug in some other category. There is very few tools that will help the
reviewer to manage his manual code review, and if you have a millions
line of code to look at, you need all the help you can.

Finding 1 needle in a hay stack  is easy, when there is a unknown random
number of needles and you have to attempt to catch them all it become
very difficult. Most company don't invest as much as Microsoft to audit
their source code, so as a code reviewer you need to manage your time
very well so that it's optimized into finding as much critical bugs as
possible and have a great ROI.

I will actually be presenting in a few month on Web Application Review
at RSI in Montreal( http://www.colloque-rsi.com/detail_conf.php?id=402).

Hugo

Dan Friedman wrote:
> Hi All,
>
> From my understanding the main issue pointed by this guy about tool
> for code review was managerial and not technical.
> MM (man-months) calculation spent for specific project review is not
> covered by "standard" code review tools and this is what he's working
> on it right now. You still need use another tool for PM in addition to
> code review tools to cover it.
>
>
> Sincerely,
> Dan
>
> ---------- Forwarded message ----------
> From: "Sebastien Guimont" <sebastieng at sympatico.ca
> <mailto:sebastieng at sympatico.ca>>
> To: <owasp-montreal at lists.owasp.org
> <mailto:owasp-montreal at lists.owasp.org>>
> Date: Wed, 25 Feb 2009 11:50:00 -0500
> Subject: [ OWASP - Montreal ] Crucible - Team Code Review Tool
>
> Hi,
>
>  
>
> At the yesterday meeting, someone has asked about a tool for code
> review management.
>
>  
>
> Here’s the link : http://www.atlassian.com/software/crucible/
>
>  
>
> Is not a free tool but Its look very promising... I didn’t try myself,
> so I cannot told you more about this tool.
>
>  
>
> A+
>
>  
>
> Sébastien Guimont.
>
>
>
> -- 
> Sincerely,
> Dan