Static analysis tip: How to resolve statically detected defects - Embedded.com

Static analysis tip: How to resolve statically detected defects

Because statically detected defects rarely have an external advocate(like a customer) demanding that they be fixed, the management of adevelopment organization needs to make the adoption of a static tool apriority in order to reap the benefits.

Even in organizations where management has taken the bull by thehorns and made time for static analysis, they can be thwarted by theunique challenges of resolving statically detected defects.

Let me offer an illustration. One static analysis tool, CoverityPrevent, enforces the following rule: “TheBAD_COMPARE checker finds many cases where a function is implicitlyconverted to its address and then compared with 0. Because functionaddresses are never 0, such comparisons always have a fixed result.

Here is a line of code that was flagged by this checker in acommonly used open source application:

if (getuid() == 0 || geteuid != 0)

Please take a moment to determine the severity of this defect on ascale from “minor” to “worst case scenario,” in terms of security. Now,of course this is something of a trick question: no one could possiblyanswer that question without access to the surrounding code context andan understanding of the design intent of the code in question.

However, this particular defect caused a very serious securityvulnerability in the package in question (long since fixed). WhileCoverity Prevent gets the credit for detecting the defect, the creditfor correctly identifying the severity and resolving it goes to an opensource developer.

An appropriate defect resolution process for a statically detecteddefect is:

1. Consider the designintent of the code in question
2. Consider the behavior of thecode in question in the case identified by static analysis
3. Change the code to make itmatch the design intent

This is substantially different from the defect resolution approachfor a customer reported defect, which would be something like:

1. Determine what piece ofcode is causing the user reported misbehavior
2. Change the code to stopmisbehaving

The primary difference is in the impossibility of correctlyassessing the severity of statically reported defects, or to proposinga resolution, without understanding the design intent of the code inquestion. This means knowledgeable, well-trained developers are muchmore likely to succeed at resolving static analysis issues.

Changing code to match the design intent is critical and makingchanges that silence the static tool may actually be harmful to productquality. Most static analysis tools will flag an issue in the codebelow; but let's consider how a developer, presented with this issue bystatic analysis, might proceed.

1 int chop(char * in) { 2 int idx; 3 if (in) { 4 idx = strlen(in); 5 if (idx) idx–; 6 } 7 // Bug! What if in is 8 // NULL! 9 in[idx]=''; 10 return idx; 11}

There are a few reasonable changes — either moving code within theconditional, or adding some error handling code, but no matter what,the only way to fix the defect is to determine what should happen whenthe in variable is null, and alter the source code to behave in thatmanner. Only a developer familiar with the application can make suchdecisions correctly.

Matthew Hayward is Director ofProfessional Services for Coverity Inc. Since he joined the company in 2005, he'sworked with hundreds of development organizations to define andimplement strategies for effectively applying static analysis toimprove software quality and security. He holds a M.S. in ComputerScience, and B.S. degrees in Mathematics and Physics from theUniversity of Illinois.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.