[WEB SECURITY] Static Source Code analysis Methodology

Rusty Johnson rusty_johnson2 at yahoo.com
Wed May 11 19:37:41 EDT 2011

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

Hi,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 Methodology”.   Basically the process depends on 3 things:1.       Assignment scope, objectives and requirements2.       Your experience3.       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 behavior.   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 vulnerabilities…  So my advice would be to first make sure you have a well define project scope in first place.Best Regards,    Aleksander P. CzarnowskiAVET 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 process.

-- Thanks and Regards:Pam Parmendra SharmaApplication Security Consultantemail: 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/20110511/fb8875e6/attachment-0003.html>

More information about the websecurity mailing list