Static Analysis Tools

 

December 2004

 
 

Tips for Getting the Most Out of a Static Analysis Tool:


Dedicate a team member to learning the tool

To get the most out of the static analysis tool one team member should learn the tool as well as possible to understand how the tool works and how they can be used to their full potential. This person should know all the features of the static analysis tool and know how to apply them to the current application.

Use the tool throughout the product cycle.

Developers should use a lightweight version of the static analysis tool before check-in to flush out easy to fix coding errors and to enforce coding standards.

Build managers should run the tool periodically on the complete source tree and after each new code check-in. The build manager can then mark false positives and assign bugs to the owner of the code.

Testers should use the static analysis tool to find sections of the application that are high in complexity and where bugs may be hidden

Keep the tool updated

Some Static analysis tools use a database of known coding problems that are constantly being updated. This type of tool should be periodically updated to ensure it is as useful as possible.

Define project specific tools

Many static analysis tools allow you to define your own coding rules. This allows the tool to be custom fitted to your specific project, which can yield more bugs found before build time and fewer false positives.

Fix only the warnings that will help make a better product

Changing the source code of your application so that the static analysis tool does not produce false positives only results in unnecessary code churn and can introduce new bugs. Some security bugs are difficult to find and exploit quickly before a product is shipped. However, a hacker will take any time necessary to discover and exploit a vulnerability, therefore every important security bug must be fixed.

Use static analysis along side white box testing tools

Static analysis tools coupled with dynamic analysis tools provides an extremely solid white box testing solution. Code reviews are still very important and can catch certain errors that a static analysis tool cannot. Dynamic analysis solves many of the shortcomings of static analysis, however it introduces a number of problems that static analysis doesn't have. Using all testing tools available is an important step in finding as many bugs as possible before ship and keeping the overall cost of development as low as possible.

Dynamic analysis tools check the code at runtime to discover problems within the source that may be related to the environment. This can be very important since the static analysis tool can not predict system state or specific hardware configurations.

Code Reviews help discover bugs by having a new fresh set of eyes look at the code for bugs. Often a second developer can find bugs in foreign code because they do not make assumptions on how the code should work.

Code coverage tools watch the application as it executes to help ensure each line of code is executed and tested. These tools often run in conjunction with automated testing tools which attempt to execute the same features at each run.

Performance monitors count the amount of time the application spends in each function and the number of times the function is called. Sections of the application that are executed repeatedly may be the source of performance issues, or a place where a higher performance algorithm may result in a large increase in performance.

With Fault Injection simulated faults can be injected into the source code. Faults simulate problems the application may encounter within the system such as low memory, hard drive corruption, network problems, registry faults and many others.

Advanced debuggers employ many more features than the standard development kits, such as system wide views of variables and states, a stack view, and remote debugging. These tools allow developers to debug their applications more easily at runtime and take some of the guess work out of tracking down a bug.

Model based testing takes a different approach to testing. The system is defined by actions that change the state of the system. For example when working with the model of a car, pressing on the accelerator has a different result depending on whether the car is in Park or Drive.

Each of these techniques fulfills a different place in the testing and development cycle. While each of these tools are extremely helpful in finding bugs in the application none find the same bugs as the static analysis tool. Static analysis tools compliment the use of dynamic analysis tools by finding bugs that are difficult to find once the application has been built into an executable.

<<Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Next>>

Provided by: Security Innovation, The Application Security Company