Static code analysis tools characteristics

All Information Technology projects produce at least one artifact – code. This fact moves code review to the number one touch-point “best practice” to be of focus. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Today, a handful of first-tier options are available in the static code analysis tools space. Each of the tools offers a comprehensive and growing rule set varying in both size and area of focus. As we investigate and evaluate which tool is most appropriate for our needs and environment, the coverage of the accompanying rule set should be one of our primary factors of comparison. In addition, to be useful and cost effective, a source code analysis tool must have these key characteristics:

Be designed for security: Exploiting software is not an exercise in standard-issue QA. An application defect uncovered during functionality testing might be addressed in such a way that the functional issue is resolved, but security defects may still remain and be reachable via surprising execution paths that are not even considered during functionality testing. The knowledge base built into a tool is an essential decision factor.

Supporting multiple-tiers: Our applications are rarely written in a single programming language or targeted to a single platform. Our most business-critical applications are highly distributed, with multiple tiers each written in a different programming language and executed in a different platform. Automated security analysis software must support each of these languages and platforms. A tool that can analyze only one or two languages can’t meet the needs of our modern applications.

Be extensible: Good tools need a modular architecture that supports multiple kinds of analysis techniques. That way, as new attack and defense techniques are developed, the tool can be expanded to encompass them. Likewise, users must be able to add their own security rules. Every department within IT has its own set of security needs, meaning that one size fits all approach to security is doomed to fail.

Be useful for security analysts and developers: Even the best analysis tools cannot automatically fix security problems. The best automated tools make it possible for analysts to focus their attention directly to the most important issues.

Supporting existing development process: Seamless integration with build processes and IDEs Plug-In is an essential characteristic of any software tool. For a source analysis tool to become accepted as part of an application development team’s toolset, the tool must properly inter-operate with existing compilers used on the various platforms and support current development tools. Good tools both integrate into existing development process and also coexist with and support analysis in familiar development tools.

Static analysis tool must avoid these characteristics:

Too many of False-Positives: One common problem with early approaches to static analysis was their excessive false positive rates. Application Security practitioners seem to feel that tools that provide a false positive rate under 40 % are okay. Modern approaches that include data flow analysis capability dramatically reduce false positives, making source code analysis much more effective.

Spotty integration with IDEs: Developers already have an IDE they like, and they should not have to switch to do a security analysis.

Bayan Alhaddad
October 2nd, 2004