Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Static vs dynamic analysis for code devt (Part 1)

Posted: 04 Sep 2013 ?? ?Print Version ?Bookmark and Share

Keywords:static analysis? software? code analysers? coding standard? AES?

The use of static analysis should be a mandatory part of every security-conscious software organisation's development process. Which static analyser should an organisation use? The best answer to this question is that a development organisation should use multiple tools from different vendors.

Empirical use within government software safety and security evaluation teams has demonstrated that a surprising majority of software flaws caught by one static analyser will not be caught by an other tool, and vice versa. Many forms of full-program static analysis are inherently intractable, requiring carefully tuned heuristic algorithms to provide high-quality results.

The best coverage for software flaw detection via static analysis requires multiple tools from multiple vendors to be used in concert. In addition to accuracy, there are large differences in the execution time of static analysers.

Static source code analysis basics
Static source code analysers attempt to find code sequences that, when executed, could result in buffer overflows, resource leaks, or many other security and reliability problems. Source code analysers are effective at locating a significant class of flaws that are not detected by compilers during standard builds and often go undetected during runtime testing as well.

Most static source code analysers use the same type of compiler front end that is used to compile code. In fact, ideally, a static source code analyser should be integrated with the everyday compiler to maximise use and reduce complexity of the tool chain. In addition, integrated checking enables source code parsing to be performed only once instead of twice. The use of a compiler front end is only natural because the analyser takes advantage of preexisting compiler dataflow algorithms to perform its bug-finding mission.

A typical compiler will issue warnings and errors for some basic potential code problems, such as violations of the language standard or use of implementation-defined constructs. In contrast, a static source code analyser performs a full program analysis,finding bugs caused by complex interactions between pieces of code that may not even be in the same source file (figure).

Figure: Inter-module static analysis.

The analyser determines potential execution paths through code, including paths into and across subroutine calls, and how the values of program objects (such as stand-alone variables or fields within aggregates) could change across these paths. The objects could reside in memory or in machine registers.

The analyser looks for many types of flaws. It looks for bugs that would normally compile without error or warning. The following is a list of some of the more common errors that a modern static source code analyser will detect the following:
???Potential NULL pointer dereferences
???Access beyond an allocated area , otherwise known as a buffer overflow
???Writes to potentially read-only memory
???Reads of potentially uninitialized objects
???Resource leaks (e.g., memory leaks and file descriptor leaks)
???Use of memory that has already been deallocated
???Out-of-scope memory usage (e.g., returning the address of an automatic variable from a subroutine)
???Failure to set a return value from a subroutine
???Buffer and array underflows

The static analyser also has knowledge about how many standard runtime library functions behave. For example, the analyser knows that subroutines such as free should be passed pointers to memory allocated by subroutines such as malloc. The analyser uses this information to detect errors in code that calls or uses the result of a call to these functions. The analyser can also be taught about properties of user-defined subroutines.

For example, if a custom memory allocation system is used, the analyser can be taught to look for misuses of this system. By teaching the analyser about properties of subroutines, users can reduce the number of false positives. A false positive is a potential flaw identified by the analyser that could not actually occur during program execution. Of course, one of the major design goals of a static source code analyser is to minimise the number of false positives so that developers can minimise time looking at them.

If an analyser generates too many false positives, it will become irrelevant because engineers will ignore the output. A modern static source code analyser is much better at limiting false positives than traditional UNIX analysers such as lint. However, since a static analyser is not able to understand complete program semantics,I t is not possible to totally eliminate false positives. In some cases, a flaw found by the analyser may not result in a fatal program fault, but could point to a questionable construct that should be fixed to improve code clarity. A good example of this is a write to a variable that is never subsequently read.

Using static techniques for secure code
A recommended approach is to employ at least one runtime efficient analysis pass during everyday software builds executed by individual developers and relegate the remainder of the available tools to offline execution that can asynchronously notify the development team of discovered flaws.

1???2?Next Page?Last Page

Article Comments - Static vs dynamic analysis for code ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top