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?

Since some compilers include built-in full program static analysis, development teams should consider enabling this feature as a compile option for all builds.

The U.S.Food and Drug Administration's Centre for Device and Radiological Health (CDRH) uses static source code analysers as a forensics tool to help locate causes of medical device failures.

In some cases, several different static analysers are used in concert. Similarly, the U.S. National Security Agency (NSA) uses multiple static analysers to help perform security vulnerability assessments on software.

Development organisations should consider evaluating numerous products for both execution efficiency as well as quality of output on the same code base. Pick a combination of tools that provide excellent flaw detection coverage while offering sufficient execution time efficiency to enable developers to use at least one of them on every compile.

It is important to automate as much as possible the implementation of a coding standard; if the developers' everyday tool chain is always enforcing the coding standard, then the software security techniques will become assimilated into the minds of all engineers and managers.

In the same way that a professional golfer relies on muscle memory to create a repeatable swing, embedded software developers must think software security everyday to ensure that lapses do not occur.

Unfortunately, the task of writing a coding standard that requires all these great ideas and turning on these software analysers in the tool chain is not as simple or straightforward as it may sound.

For example, enabling a static source code analyser for the first time in a large code base is almost certain to identify hundreds, if not thousands, of problematic code sequences. Some of these will undoubtedly be false positives that must be worked around by modifying the code to mollify the analyser.

Numerous real flaws will be discovered, and the organisation will be encouraged by their eradication, even though the review and correction of the identified flaws may require significant resource investment.

Nevertheless, experience has shown that once the code base has been made "coding standard clean," keeping it that way will become routine. Developers must take extreme care when modifying software that has been around a long time(and possibly fielded for a long time).

Some studies have shown that static analysers and checkers have the potential to harm software security by introducing new flaws when correcting identified problems.

This risk is especially high when retrofitting a new coding standard or new analyser tool to a code base. In some cases, it may be prudent to disable a check for a particular piece of software rather Than take the risk of modifying it.

For example, let's suppose management decides to retrofit a new rule limiting all functions to a maximum McCabe complexity value of 20. A large code base may include dozens or even hundreds of functions that initially fail to meet this metric.

Some of the offending subroutines may be straightforward to refactor. Others may be difficult and risky. In fact, some of the worst offenders that are begging for a rewrite may be the exact wrong ones to change, especially if they are providing a security-critical function.

If the software includes a hand-coded AES cryptographic algorithm that has been painstakingly developed to be side-channel attack-resistant and has been through FIPS certification, perhaps the best approach is to leave this function alone as a documented exception to the coding standard.

About the author
David Kleidermacher, Chief Technology Officer of Green Hills Software, joined the company in 1991 and is responsible for technology strategy, platform planning, and solutions design. He is an authority in systems software and security, including secure operating systems, virtualisation technology, and the application of high robustness security engineering principles to solve computing infrastructure problems. Mr. Kleidermacher earned his bachelor of science in computer science from Cornell University.

This article is excerpted from Embedded Systems Security by David and Mike Kleidermacher, used with permission from Newnes, a division of Elsevier. Copyright 2012. All rights reserved.

To download the PDF version of this article, click here.

?First Page?Previous Page 1???2

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