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 Sharma
Application Security Consultant
email: s.parmendra@gmail.com

Check SDL (Security Development Lifecycle) from Mike HowardÈ/Microsoft.
Sent via BlackBerry from Danux Network

-----Original Message-----
From: Parmendra Sharma s.parmendra@gmail.com
Sender: websecurity-bounces@lists.webappsec.org
Date: Sat, 7 May 2011 23:39:58
To: websecurity@webappsec.org
Subject: [WEB SECURITY] Static Source Code analysis Methodology

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Posted before  http://www.mail-archive.com/full-disclosure@lists.grok.org.uk/msg22112.html

From: websecurity-bounces@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Parmendra Sharma
Sent: 07 May 2011 23:40
To: websecurity@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 Sharma

Application Security Consultant

email: s.parmendra@gmail.com

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 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 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. Czarnowski

AVET Information and Network Security Sp. z o.o.

From: websecurity-bounces@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Parmendra Sharma
Sent: Saturday, May 07, 2011 8:10 PM
To: websecurity@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 Sharma

Application Security Consultant

email: s.parmendra@gmail.com

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.
~cktricky
http://cktricky.blogspot.com

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

From: Aleksander P. Czarnowski aleksander.czarnowski@avet.com.pl
Subject: Re: [WEB SECURITY] Static Source Code analysis Methodology
To: websecurity@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@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Parmendra Sharma
Sent: Saturday, May 07, 2011 8:10 PM
To: websecurity@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@gmail.com
-----Inline Attachment Follows-----

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

This is another important issue as it comes down not only to be able to filter out all false positives for example but to  actually being able to transfer knowledge from the review to architects, programmers, administrators etc. depending on chosen remediation solution and more global approach at the customer patch management process level.

Coming back to my previous post I believe there is only one working approach: fix all the bugs and errors disregarding if they are being ever triggered or not. Actually removing dead code is also one way of  making whole application more secure and source code is easier to manage than. My point was that to fully understand error/bug/vulnerability and associate proper risk level with it, one must take in account more than just single line of code. In this process the final execution environment has crucial impact on the assessment too.

Best Regards,

Aleksander P. Czarnowski

AVET Information and Network Security Sp. z o.o.

www.avet.com.pl

From: websecurity-bounces@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Rohit Pitke
Sent: Wednesday, May 18, 2011 7:59 AM
To: Rusty Johnson; websecurity@webappsec.org; Aleksander P. Czarnowski
Subject: Re: [WEB SECURITY] Static Source Code analysis Methodology

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,
Rohit

From: Rusty Johnson rusty_johnson2@yahoo.com
To: websecurity@webappsec.org; Aleksander P. Czarnowski aleksander.czarnowski@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.

~cktricky

http://cktricky.blogspot.com