This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 CanStaticAnalyzersDoAll

From OWASP
Revision as of 18:58, 4 August 2013 by Ashish Rao (talk | contribs)

Jump to: navigation, search

Secure code review is a process of enumerating the flaws in the application. The flaws may exist in the application due to insecure code, design or configuration. Out of which the flaws that arise due to insecure code can be enumerated to a great extent through automated analysis, as most of them are associated with insecure patterns.

Automated analysis can be carried out through any of the following three options:

  • Static Code analyzers or scanners
  • Custom scripts based on some pattern search
  • Open source tools

Though some scripts and some open source tools are efficient enough in finding some insecure code pattern but they often lack the capability of tracing the data flow. This limitation is fulfilled by the use of static code analyzers or the scanners, which identify the insecure code pattern along with source to the sink analysis.

      • With this we come to the next big question i.e. Can scanners i.e. static code analyzers do it all?

Static code analyzers or the scanners are the most comprehensive options to automate the process of review. There are many static and binary analysis tools that automate most of the secure code analysis. Some of the advantages of static code scanners are:

1. Reduction in manual efforts – Secure code review can be a tedious process of analyzing thousands of lines of code for host of vulnerabilities. Also as the type of patterns to be scanned almost remains common across application the task tends to get a bit repetitive. In such a scenario, scanners play a big role is automating the process of searching the vulnerabilities through big numbers of lines of code.


2. Time efficient – Scanners are must time efficient than manual reviews. In most cases the scanners have proved to be faster than manual process of reviewing the source code.


3.Finds all the instances of the vulnerabilities - Scanners are very effective in identifying all the instances of a particular vulnerability with exact location.

4. Source to sink analysis – Most scanners today trace the code and identify the vulnerabilities source to sink analysis. They identify the inputs to the application and trace them thoroughly throughout the code till they find them associated with some insecure code patterns. This helps the developers in understanding the flaws better, as they get a complete root cause analysis of the flaw.

5. Exhaustive coverage of vulnerability patterns – Most of the scanners have well-defined set of test cases covering all the well-known vulnerabilities. Thus through use of scanners we can ensure that the code gets thoroughly checked for all the pre-defined set of cases.

6. Elaborate reporting format – Scanners provide a detailed report on the observed vulnerabilities with exact code snippets, risk rating and completed description of the vulnerabilities. This helps the development teams to easily understand the flaws and implement necessary controls.

Limitations of static code analyzers:

1.Business Logic Flaws remain untouched – Scanners do not understand the application. The flaws that are related to application’s logic, transactions, and specific sensitive data remain untouched by the scanners. The security controls that need to be implemented specific to the application’s features and design are often not pointed by the scanners. This stands as a biggest limitation of the static code analysers.

2. Limited scope – Static code analyzers are often designed for specific frameworks or certain set of vulnerable patterns, they fail to address the issues not covered in their search pattern repository. So the scanners often fail in catching up the vulnerabilities of the new versions of the framework.

3. Custom validations - Most of the static analysers tool miss out the custom validations added in the application while identifying the flaws. These could include blacklist or whitelist validation present in the application before the input sources. It could also mean the customization added by the developers to the existing design frameworks and inbuilt framework based API, the scanners that go by pattern based search usually miss out in understanding such intricate details of the code.

4. Design flaws – Design flaws are lessen known issues and static code analysers focus more on the code than the design. Mainly if the application design is custom built it becomes challenging for the scanners to trace the code flow and in the event results in false negatives.


5. Application specific recommendations – Scanners usually provide a generic solution and do not point out application specific code changes. If the solutions are customized as per the design and the feasibility of the application it will be clearer to the developers and require less code change.

Parameters to be considered for commercial scanners: 1. Source to sink analysis Capabilities 2. Support for frameworks 3. Ability to understand customized code or validations 4. Coverage of Business logic cases specially the ones related to authorization 5. Option to customize the pattern search