Should static analysis be a part of the software development process?

When the cost of addressing security issues increases as the software design lifecycle proceeds, see why expert Michael Cobb says that using static analysis early on can benefit your bottom line.

Some developers mention the weaknesses and limitations of static analysis. Can developers get away with avoiding this part of the software development process? Are there better testing methods, and should they be used in place of static analysis?
A comprehensive approach to secure software development is needed to eradicate vulnerabilities. Network defenses alone will struggle to protect a system running a vulnerable application. To improve the quality of your software, you should adopt a "security development lifecycle (SDL)" approach, the aim of which is to reduce the number of security-related design and coding defects, as well as lessen the severity of any defects that make it through to the release version.

As development of your application gets underway, you'll need to initiate code reviews. Even if developers write code with security in mind, the code must still be tested for technical and logical vulnerabilities. In an effort to share best practices for developing more secure code, Microsoft has made public its security development lifecycle. Throughout its SDL, the software goes through both static and dynamic code analysis.

Neither static nor dynamic analysis can capture every type of error. As applications become more complex, it is getting increasingly harder to dynamically test all of the possible permutations that an application may face in the real world. This is why I recommend a combination of static and dynamic verification tools that continually check for technical and logical vulnerabilities during the development cycle. Microsoft has found that software that has undergone its SDL has experienced a significantly reduced rate of externally discovered security vulnerabilities.

Static analysis involves reviewing an application's source code without executing the application itself. While program compilers only identify language rule violations, such as type violations and syntax errors, static analysis aims to uncover and remove problems, such as semantic mistakes, that pass through compilers and result in buffer overruns, invalid pointer references, uninitialized variables and other vulnerabilities. There are tools that can analyze code to create diagrammatic representations, making it easier to follow and understand the effects when a branch of code is executed. It does take experienced developers to analyze the results and examine any suspect source code, however. Interestingly, having code reviewed by experts tends to make developers document their code more clearly so as not to be picked up by their peers.

Nonetheless, some problems are difficult to foresee during static analysis. The interaction of multiple functions can generate unanticipated errors, which only become apparent during component-level integration, system integration or deployment. Therefore, once the software is functionally complete, dynamic analysis should also be performed. Dynamic analysis reveals how the application behaves when executed, and how it interacts with other processes and the operating system itself. While static analysis can find errors early in the development cycle, dynamic analysis tests the code in real-life scenarios. To that end, many developers now use a technique called fuzzing that bombards a running program with random data to test the robustness of its code. If the fuzz data causes the program to fail, crash, lock up, consume memory or produce uncontrolled errors, the developer knows that there is a flaw somewhere within the code.

There are plenty of static code-analysis tools for developers, many of which are free. There's a fairly comprehensive list available, which includes metric and lint-like tools. (The term lint-like refers to the process of flagging suspicious language usage.) If you use any of the Microsoft development environments, then you should certainly look at its free code-analysis tools, such as PREfix, PREfast, and FxCop.

Finding and fixing programming errors can be time-consuming, but in the long run, the process will result in a more stable and secure application. When the cost of addressing security issues increases as the software design lifecycle proceeds, using static analysis early on not only helps create better products and increase customer confidence in your applications; it can also benefit the bottom line, too, most notably in the form of flaws discovered before an application is deployed.

More information:

  • Video: At Information Security Decisions 2008, security researchers discuss secure application coding and how to teach best practices to young developers.
  • This was first published in January 2009

    Dig deeper on Security Testing and Ethical Hacking



    Enjoy the benefits of Pro+ membership, learn more and join.

    Have a question for an expert?

    Please add a title for your question

    Get answers from a TechTarget expert on whatever's puzzling you.

    You will be able to add details on the next page.



    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to: