The name of the associated research field is static code analysis. This is differentiated from more traditional dynamic analysis techniques such as unit or penetration test by the fact that the work is performed at build time using only the source code of the program or module in question. The results reported are therefore generated from a complete view of every possible execution path, rather than some aspect of a necessarily limited observed runtime behavior.



Perhaps the most obvious question confronting any new developer-facing technology is: why?

�Why should developers use a new tool when they already have so many to choose from?

�What makes this technology compelling enough to make me want to add it to my already bloated build chain?

�And what does it do, anyway?

This paper will answer these questions, and more. But for the moment just consider the fact that at time of writing, 80% of the Fortune 500 have already deployed, or are currently engaged in deploying, some kind of automated source code analysis. The reasons for doing so can be stated in as many ways as there are people answering the question, but the basic principle can be found in all of these deployments:

� Tell me what�s wrong with my code before I ship it � don�t let me be the guy responsible for shipping a killer vulnerability or bug into the wild.

There are other compelling reasons, such as:

� Make my existing processes for code review more effective through automation

� Enhance my existing QA resource with 100% coverage of all boundary conditions

� Help me protect my brand as we go to market with new products

But the bottom line remains the capability of this technology to afford developers the ability to scrub their code of obvious and not-so-obvious weaknesses as they work, before they submit their code for check-in and more formal down-stream validation procedures.

Introduction to the technology:

The process of automated source code analysis involves building a rich representation or model of the provided code (akin to a compilation phase), and then simulating all possible execution paths through that model, mapping out the flow of logic on those paths coupled with how and where data objects are created, used and destroyed.

Once the projection of code paths and the mapping of data objects are available, we can look for anomalous conditions that either will or might potentially cause exploitable vulnerabilities, execution failure, or data corruption at runtime.

There are two major families of checking capability typical to this type of analysis: abstract syntax tree (AST) validation and code path analysis. The former case is most frequently applied to validation of the basic syntax and structure of code, whereas the latter is used for more complete types of analysis that depend on understanding the state of a program�s data objects at any particular point on a code execution path.