Static Source Code Analysis

Defining Static Source Code Analysis

Static source code analysis refers to the analysis of software that is performed without executing the application under test. This contrasts with run time or dynamic analysis where the analysis is performed on a executing application. In a static source code analysis the analysis is performed on the source code or object code used to build the application.

Static and run time analyses each have their respective merits. A run time analysis will allow you to isolate behaviour that can only be exhibited at runtime, for example where an application takes some form of real time feed or interrupt. However, to perform a run time analysis will require the execution of the application and invariably the creation and maintenance of a test data set to cover the use cases required.

It is well understood that the creation and management of test data can be a complex, costly and difficult task. Static analysis on the other hand will allow you to catch defects, across multiple compile time execution paths. This is typically performed as part of the software build process, without having to generate use cases and supporting data. This has the advantage of allowing developers to quickly isolate defects, while they are working on the code, so that they can be fixed at much lower cost than defects discovered later on in test or when released to customers.

Static analysis has for many years been used to give insight into metrics such a code complexity. More recently it has been used for deep analysis for finding bugs, security vulnerabilities, and analysis of software architecture.

Background on Static Analysis

Static-analysis techniques infer information about software behaviour based on a static representation of the software. This contrasts with dynamic analysis techniques, which gather information by observing software as it is running. Because code is analysed instead of executed, static analysis does not require test cases. Static analysis can be seen as a two-phase process. The first phase involves extracting semantic information from the software’s source code. The second phase involves using this information to discover defects or other properties of interest.

Until recently, static-analysis tools were impractical for most developers to deploy across the enterprise. At one end of the spectrum were tools, such as Lint, that could only check the surface structure of the code. These can be useful for enforcing coding standards, and for some superficial checks, but they are not powerful enough to detect many classes of serious problems. This class of tools also generate a large number of false positive warnings, making it difficult to review their output. At the other end of the tools spectrum were very sophisticated model checkers. These tools can verify sequencing properties of a system, but cannot be applied directly to source code, working instead on an abstract model of the system provided in an esoteric language. Furthermore, model-checking tools have historically suffered from scalability problems. Recently, new tools have appeared that overcome these obstacles and make it possible to apply sophisticated analyses to large programs.

Static-Analysis ROI

The benefits of static analysis are based on the following:

Static analysis is able to examine more execution paths than conventional testing

Conventional testing can only check code being executed, so it is only as good as the testcases. For real-world systems, the number of paths in the program far exceeds the number that can be exercised by testing. Test suites might achieve 100% statement coverage, but most paths go unexecuted. In contrast, static-analysis tools examine paths for which no testcases have been written. This explains why static-analysis tools find many bugs, even in software that has already undergone the most extensive testing. The best static-analysis tools improve software quality significantly and require little effort to employ. In addition, major improvements in software security are realised because the root of many vulnerabilities is a coding defect. Attackers often exploit corner-case program behaviour, exactly the type that a test suite is likely to miss. Static-analysis tools are more likely to catch such vulnerabilities

Static analysis can be applied early in the development cycle

Static analysis provides significant time and cost savings because it has the ability to identify bugs early in the development cycle, where they are easier to fix. According to a comprehensive study on software testing by the US National Institute of Standards and Technology in 2002, coding defects discovered in fielded products take 10 to 30 times more effort to fix than coding defects found during coding itself. Identifying bugs as early as possible—right after coding and before system testing—is critical because bugs become far more costly to fix the farther downstream they are detected. The savings are significant because debugging, testing, and verification activities can easily range from 50% to 75% of total software development cost. Another benefit of the time savings is faster time to market. Static analysis quickly identifies problems that take a long time to debug by hand. Developers avoid getting sucked into a manual debugging black hole and instead are able to focus on more important and enjoyable tasks. In addition, product development risk is reduced. According to the National Institute of Standards and Technology “Over 80 percent of errors are introduced in the coding/unit testing stage, but well over half of these errors are not found until downstream in the development process.”

Static Analysis for finding coding errors

Static analysis tools like CodeSonar work with a configurable compiler, which simulates the real compiler used to build the application software. The compiler output is then used as a basis of the analysis to find defects such as memory leaks, uninitialized variables, buffer overruns and null-pointer dereferences.

Static Analysis for software architecture analysis

Static Analysis such as Lattix create a representation of software applications, databases and systems. Architects and developers can analyse the most complex systems, edit the structure to create what-if scenarios, and specify design rules, allowing them to formalise and communicate the architecture to the entire organization. The result is higher quality, improved reliability, and much easier maintenance with an enforced and visible architecture.