[WEB SECURITY] Static Source Code analysis Methodology

Rohit Pitke rohirp92 at yahoo.com
Wed May 18 01:58:44 EDT 2011

Apart from tool configuration and various ideas detailed here, I have seen 
static code analysis tool creates too many false positives. So pre-configuration 
of scans by considering your options (security, code-quality, exploitability) 
are must. After scan is complete, I would strongly recommend to double check 
most of issues for their false-positive attribute.

I have seen pain in some recent work we did where one of the tool resulted in 
more than 20000 issues :)

Best Regards,

From: Rusty Johnson <rusty_johnson2 at yahoo.com>
To: websecurity at webappsec.org; Aleksander P. Czarnowski 
<aleksander.czarnowski at avet.com.pl>
Sent: Thu, May 12, 2011 5:07:41 AM
Subject: Re: [WEB SECURITY] Static Source Code analysis Methodology

I can agree with you that experience and expertise matter greatly when 
performing a code review.

The following statements, although in regards to PHP hold true, at least in my 
experience, for most major frameworks:

Although settings as configured in something like php.ini can greatly affect PHP 
code behavior, anyone with enough experience doesn't preclude a finding based on 
these settings. For whatever the reason, these settings can be overwritten. If, 
as part of the overall report, an analyst would prefer to include the mitigating 
factor (settings) then I would understand. However, if this completely nullifies 
a finding.......I disagree wholeheartedly with the approach taken.



--- On Wed, 5/11/11, Aleksander P.  Czarnowski 
<aleksander.czarnowski at avet.com.pl> wrote:

>From: Aleksander P. Czarnowski <aleksander.czarnowski at avet.com.pl>
>Subject: Re: [WEB SECURITY] Static Source Code analysis Methodology
>To: websecurity at webappsec.org
>Date: Wednesday, May 11, 2011, 6:13 PM
>First of all I believe that if you have a problem with „Standard Methodology” 
>you shouldn’t take the assignment in the first place, unless this is part of 
>your education process. Not that I don’t want to be helpful but source code 
>review requires both deep expertise and experience in order to provide really 
>useful data one can trust as opposed to providing report with few millions 
>similar “bugs” found. Otherwise running grep on source tree can be the “Standard 
>Basically the process depends on 3 things:
>1.       Assignment scope, objectives and requirements
>2.       Your experience
>3.       Your toolbase
>For example: I don’t consider any PHP code review to be complete without also 
>reviewing at least PHP settings since those options can heavily influence code 
>The taxonomy you use and the review process are influenced both by your toolset 
>as well as the assignment type i.e.: you can just review single checkout from 
>repository or you can review new commits to the repository.  Secondly you have 
>to decide how to deal with findings you choose to ignore and how to handle this 
>process correctly. Everybody probably knows the great story of RealPlayer code 
>“fixed” with ignore comments for Flawfinder which ended in new set of 
>So my advice would be to first make sure you have a well define project scope in 
>first place.
>Best Regards,
>Aleksander P. Czarnowski
>AVET Information and Network Security Sp. z  o.o.
>From:websecurity-bounces at lists.webappsec.org  
>[mailto:websecurity-bounces at lists.webappsec.org] On Behalf Of Parmendra Sharma
>Sent: Saturday, May 07, 2011 8:10 PM
>To: websecurity at webappsec.org
>Subject: [WEB SECURITY] Static Source Code analysis Methodology
>Hi All,
>In one of my upcoming assignment, i need to perform Static Source Code analysis 
>(SSCA) and prior to this i need to explain about the 'Standard Methodology' 
>which will be followed for performing SSCA. 
>I need to know which standard methodology is generally followed for SSCA 
>Thanks and Regards:
>Parmendra Sharma
>Application Security Consultant
>email: s.parmendra at gmail.com
>-----Inline Attachment Follows-----
>The Web Security Mailing List
>WebSecurity RSS Feed
>Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>WASC on Twitter
>websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110517/11a3d2d6/attachment-0003.html>

More information about the websecurity mailing list