In this post, we’re going to use a custom checker to enforce an internal coding standard that extends the default set of checkers in our source code analysis tool.

To do this, I’ve called upon Steve Howard, our head of Partner Support in Europe, to get us started with an AST checker to accomplish our goal.

Steve has coached many customers through the checker creation process. In his experience, the appeal of custom checkers lies in their ability to enforce naming conventions and code constructions across organizations.

The standard we want to enforce is the use of a compound statement block rather than single statements as the body of a for loop. An AST checker is the way to go because detection depends solely on the syntax of the code itself and not runtime behavior.

See the example below:

To flag this violation, we need to instruct the checker to find all instances of for loop nodes that contain a Statement node as an immediate descendant.

A tool that shows you a visual representation of the AST for the test case is quite helpful in the checker creation process. Here at Klocwork, we use Checker Studio to:

• browse the AST structure of test cases,
• identify nodes of interest, and
• test XPath-like expressions that identify node types, qualifiers, conditions and variables to traverse the AST and flag the defect.

Note: If we wanted to enforce the compound statement rule in all loops, then we’d need to have one pattern (created using the XPath-like expression) for each possible kind, such as while loops and do while loops.

Armed with the test case, Checker Studio, and a syntax guide, Steve identified the following expression that flags the infraction:

// ForStmt [not (Stmt::CompoundStmt)]

Here’s how the test case and expression appear in Checker Studio:

Golden rules

Based on his experience, Steve has a number of golden rules that get you from idea to defect detection faster:

• Start simple: Use a simple test case that contains the defect you want to detect and work with one simple pattern at a time. Add more complexity as you go along
• Start rough and refine later: Don’t worry about false positives at first. In some cases it may even be easier to search for  instances that are OK and then negate the rule at the end
• Divide and conquer: With a more complex checker, work separately on each aspect of the defect you want to detect and then bring it all together at the end for testing in Checker Studio
• Watch your levels: Make the highlighting as relevant as possible for the issue you’re trying to find. For example, “// ClassType [MemberDecls[*]::MemberDecl]” will highlight classes that match, whereas “// ClassType/MemberDecls[*]::MemberDecl”  will highlight class members that match. The rule is the same, but the focus is different
• Weed out false negatives: Add negative examples (good code) to check for false negatives

For more information about our custom AST checkers, watch our Checker Studio video.

Answer: Klocwork Insight 9.5 releases today and boy are we ever happy to see it go live — we’re “out there Jerry” and yes, of course we’re loving every minute of it.

This has been a long release, taking significant research and development to bring to fruition, all the while continuing to release more traditional shipments as we went, but finally culminating in a new, game-changing technology for source code analysis. On-the-fly, as-you-type, instant-like-for-reals, call it what you like… full-on, in-depth C/C++ analysis performed as the developer enters their code, using the “squiggly line” usability metaphor created by spell checkers. It’s one of those “why would you do it any other way” moments and we’re happy to be unique.

Not to be outdone, our web tools team has done amazing stuff with a complete redesign of our Review and Inspect tools, showcasing an awesome look and feel that leverages the toys that come with HTML5 and, amongst many other new capabilities, brings drag/drop pivot report design to the web for on-the-fly metrics and trending analysis that managers and development leads will just eat up.

To our customers, our partners and our friends in the industry, we’d like to say Welcome to Insight 9.5, hope you enjoy it.

You’ve been using source code analysis on your integration build or your desktop, or (ideally) both. And then there’s “a situation”.

The situation

Either you:

• Noticed a false negative you want detected, or
• Need a way to enforce a corporate coding standard, such as the requirement for the use of  a compound statement block rather than single statements as the body of a loop.

Now what?

Time to create a custom checker, that’s what. But what kind of checker?

Source code analysis involves two families of checkers, those that involve:

• Abstract Syntax Tree (AST) validation, and
• Code path analysis.

An AST provides a tree-based structural representation of the source code. An AST checker allows you to pinpoint problematic syntax using XPath or XPath-derived grammar to define the problem you’re looking for. AST checkers (our version is called Klockwork AST checkers, or KAST for short) don’t require program execution to run; they detect defects right away on source code.

Code path analysis, on the other hand, targets defects related to value tracking at program execution time. Instead of style violations, you’d use a path checker to answer questions such as:

• Is this newly-created object released before all aliases to it are removed from scope?
• Is this data object ever range-checked before being passed to an OS function?
• Is this string checked for special characters before being submitted as an SQL query?

To create a path checker, you don’t need to know how data is tracked by the checker. What you do need to know are the function types and values you want to track for the analysis starting point and the analysis end point where the defect (or event) is recognized and reported.

Which checker when?

Create an AST checker when the problem you want to detect:

• is a local defect
• does not involve program execution
• has to do with the way the program was written
• does not involve tracking a value
• does not involve a path

Create a path checker when the problem you want to detect:

• involves tracking a value
• has a starting point (where the analysis starts) and end point (where the defect is detected)
• involves program execution

Stay tuned for the next post in this series on best practices for AST checker creation.

For more information, see Writing custom checkers with Klocwork Extensibility or check out our member discussions in the C/C++ custom checkers forum.

–With files from CTO Gwyn Fisher

To add another twist to this story, the researcher in question has been ejected from participating in Apple’s developer programs. Read about that here.

Are we now getting to the point where hackers are going to start trying more aggressively to exploit Apple products? In a survey done in 2010, over 50% of respondents thought Windows was either “very” or “extremely” vulnerable compared to only 20% for Apple. I wonder if that has changed? More importantly, do I need to start worrying about my daughter downloading the Archie comic app from the App Store?

A number of years ago, one of the projects I was PM on decided to try out Scrum. I had attended some Product Owner training, and our soon-to-be Scrum Master had been on some training as well, but we were very green and decided to approach things with a “let’s see what works best for us” mentality. At the time, we thought the best way for us to get immersed and efficient with Scrum was lots of repetitions. We went with 1-week iterations, thinking that by having a rapid and regular cycle of sprint planning meetings, demo meetings, retrospective meetings, etc. we would learn more quickly the “proper” way of doing development with Scrum.

We certainly did learn a lot during our first 3 or 4 sprints, mainly that having this regular weekly cycle of meetings was just too much overhead, and the actual amount of value produced at the end of each sprint was too little. Next on our list, the 2-week sprint.

The 2-week sprints worked great for us, and we saw the differences from the 1-week sprints almost immediately. We were producing what we thought was a good amount of value from each sprint, but with a better and more balanced level of overhead. We hit our groove and established a good cadence with these 2-week sprints, and from the looks of the burn-down chart, we were becoming a more efficient team with every sprint.

The team definitely was cruising and enjoying the pace, but the holiday season snuck up on us and we thought that it might make sense to make some adjustments to deal with the vacation time various team members would be taking.

After collecting everyone’s vacation schedule, we were able to determine a start and finish date for our “holiday sprint” that would essentially start when everyone was still in the office, and finish when everyone returned from their vacation. Call it either luck or good management, but we had planned a 4-week sprint. I won’t go through all the gory details, but let’s just say that upon reflection, the 4-week iteration just felt wrong.

The initial planning session felt harder to estimate the amount of work we could do. The cadence we developed didn’t show itself, and it really felt like we never gained any momentum during the 4 weeks. Now I’m sure that the whole holiday season thing played a role in this, but it was our least effective iteration ever, and by a lot. We never tried the 4-week iteration again.

The bottom line is that all teams are different and need to go with the iteration length that feels right for them. For us, the 2-week one was best.

For the record, I have always wondered if the 7-year rule for chewing gum was true. Glad to hear it isn’t.

With all of the inherent challenges for agile in these organizations such as standards/regulatory compliance, hardware changes and integration, security issues, etc. I must say that I’m a little shocked that customers are moving away from their current processes towards something like agile. Add to this the fact that the Agile Manifesto specifically states “Working software over comprehensive documentation” and it doesn’t exactly sound like agile is a great fit for embedded systems in general, let alone medical device.

Now, don’t get me wrong, I am a huge proponent of agile, and I certainly realize that there are many pros for moving to agile, and these have been well documented, but I have to wonder just how agile are these specific industries going?  I would bet that most (all?) of these organizations are adopting some of the key fundamentals of agile, but to say they are going “all in” would be a bit of a stretch.

Even industries heavy on process (because of regulatory requirements) are taking the leap into agile. How agile are they?

Looking at the manifesto a little closer, some of the principles are fairly generic and feel more like common sense than anything revolutionary, so they probably apply to any industry. There are a few principles however that are fairly easy to imagine in these industries, such as:

• getting all stakeholders involved in defining requirements (Principle #4), or
• embracing more face-to-face conversations (Principle #6), and
• simplicity, or minimizing the amount of work not done (Principle #10).

But do people really think that Principles #1 (early and often delivery of software), and #2 (welcome changing requirements) really apply to the embedded or medical devices industries? Personally I don’t see it.

So what do you think? Are the embedded software or medical devices industries capable of going full out Agile?

Well, we agree. That’s why we’ve partnered with our friends at Security Innovation to make some of their developer eLearning courses available for free on the new, revamped Klocwork University. I encourage you to check out the Secure Coding for C/C++ course – it’s approx 60 minutes in length, features interactive material, and is a great introductory course into many of the key concepts required to build secure software. We also have a course on Microsoft’s Secure SDL and the OWASP Top 10. Check it out!

Klocwork University is your one stop for self-paced online learning and how-tos about:

• Setting up and using our static analysis tools on your desktop or integration build
• The latest trends in software security
• Agile coding practices and how they intersect with static analysis
• Klocwork product overviews

At Klocwork University you’ll see helpful descriptions of:

• In-house and partner-generated e-learning courses
• Video how-tos
• Webinars

After you browse our offerings on the Klocwork University page, click your selection and access your resource. If you’re not already logged in to the Klocwork Developer Network, you’ll be prompted to log in or register to use these free resources.

This change pulls the course content descriptions from behind the login wall to provide a searchable list for members and non-members alike.

At Klocwork University, you get the information up front and you can schedule your pub breaks when and where you want. Join today. There’s no free beer though.

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
14     stmt.setString(1, id);
15     ResultSet rs = stmt.executeQuery();
16     while (rs.next()) {
17       result.add(rs.getString("code"));
18     }
19   } catch (SQLException e) {
20      e.printStackTrace();
21   }
22   return result;
23 }

The problem with the code above is that it allocates SQL server resources but fails to properly release them. More specifically:

• Line 12: SQL connection ‘conn’ is not closed on exit.
• Line 13: SQL object ‘stmt’ is not closed on exit.
• Line 16: SQL object ‘rs’ is not closed on exit.

The next snippet illustrates how one can fix the defects listed above:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   Connection conn = null;
12   PreparedStatement stmt = null;
13   ResultSet rs = null;
14   try {
15     conn = DriverManager.getConnection(dbUrl);
16     stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
17     stmt.setString(1, id);
18     rs = stmt.executeQuery();
19     while (rs.next()) {
20       result.add(rs.getString("code"));
21     }
22   } catch (SQLException e) {
23     e.printStackTrace();
24   } finally {
25     if (rs != null) {
26       try {
27         rs.close();          // close() throws an exception...
28       } catch (SQLException e) {
29         e.printStackTrace(); // ...have to catch it to free 'stmt'
30       }
31     }
32     if (stmt != null) {
33       try {
34         stmt.close();        // again, close() throws an exception...
35       } catch (SQLException ignore) {
36         e.printStackTrace(); // ...have to catch it to free 'conn'
37       }
38     }
39     if (conn != null) {
30       try {
41         conn.close();
42       } catch (SQLException ignore) {
43         e.printStackTrace();
44       }
45     }
46   }
47   return result;
48 }

The code above is correct but extremely verbose. However, it can be improved without sacrifices in semantics…

Tip #1: It is better to allocate a resource before the ‘try/finally’ block, not inside it. Let’s start with the following code:

Connection conn = null;
try {
  conn = DriverManager.getConnection(dbUrl);
  // use conn
} finally {
  if (conn != null) {
    conn.close();
  }
}

can be rewritten as:

Connection conn = DriverManager.getConnection(dbUrl);
try {
  // use conn
} finally {
  conn.close();
}

Tip #2: Use nested ‘try/finally’ blocks if you allocate a sequence of resources. Let’s start with a snippet:

try {
  Connection conn = DriverManager.getConnection(dbUrl);
  PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
  try {
    // use conn
    // use stmt
  } finally {
    try {
      conn.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
    try {
       stmt.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
} catch (SQLException e) {
  e.printStackTrace();
}

How many problems have you noticed in the snippet above? I found three:

• Allocation of resource ‘stmt’ can throw an exception before we enter the outer ‘try/catch/finally’. If happens ‘conn’ will never be freed.
• We duplicate code for the SQLException handling. We were lucky to have only one line of code replicated, but it in general cases exception handling can be a bit more involved that we see here…
• The order of resource allocation does not match the order of deallocation: here the order of deallocation should be reversed to be correct.

The only robust way to handle resource allocation/deallocation and to address the issues listed above is to use nested try/finally blocks:

try {
  Connection conn = DriverManager.getConnection(dbUrl);
  try {
    // use conn
    PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
    try {
      // use stmt
    } finally {
      stmt.close();
    }
  } finally {
    conn.close();
  }
} catch (SQLException e) {
  e.printStackTrace();
}

Let’s apply tips #1 and #2 to our original method and fix the resource leaks on lines 12, 13, 16:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     try {
14       PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
15       try {
16         stmt.setString(1, id);
17         ResultSet rs = stmt.executeQuery();
18         try {
19           while (rs.next()) {
20             result.add(rs.getString("code"));
21           }
22         } finally {
23           rs.close();
24         }
25       } finally {
26          stmt.close();
27       }
28     } finally {
29       conn.close();
30     }
31   } catch (SQLException e) {
32     e.printStackTrace();
33   }
34   return result;
35 }

This is way shorter than the original solution!

Tip #3: If after applying tip #2 you feel that all your code drifted way too close to the right page margin it means that you probably have too much nested ‘try/finally’ blocks and that is time to check if you actually want to have all the resources allocated at the same time. Chances are that you do not need them all; otherwise use the Extract Method refactoring pattern to move out some of the resource access logic.

Tip #4: Know specific behavior of resources you are dealing with. While tips #1 – #3 provide a robust and compact approach for dealing with resource allocation/deallocation in general, in certain cases you can make code even more compact. In our example: Statement.close() closes its current ResultSet object if one exists. Likewise Connections.close() releases JDBC resources. It means that if you deal specifically with JDBC it would be sufficient to close the ‘parent’ resource to be sure that all ‘subresources’ will be properly released:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     try {
14       PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
15       stmt.setString(1, id);
16       ResultSet rs = stmt.executeQuery();
17       while (rs.next()) {
18         result.add(rs.getString("code"));
19       }
20     } finally {
21       conn.close();
22     }
23   } catch (SQLException e) {
24     e.printStackTrace();
25   }
26   return result;
27 }

Michail the friendly, programming vampire.

Instead of fomenting dissent (that barely exists) in a brazen attempt to boost readership, I’m changing tactics to look at ways in which testing and development are complementary, beyond their common goal of releasing quality software products.

What can I say? After my previous post, How developers drive testers nuts–let’s count the ways, I’m clearly getting less edgy.

I approached our newest addition to the Klocwork development team, Michail Greshishchev. While he’s a new full-timer, Greshishchev is not a new face around here.

The recent Carleton University engineering graduate did two co-op terms here–one in professional services and the other in testing.

So I asked Greshishchev how his stint in testing affected his development. Here’s exactly what he said:

1. Writing short, efficient unit tests comes naturally after dealing with mammoth testing frameworks. Most of the code I write are tests – the techniques and skills I’ve learned in testing are fully applicable to development.
2. Developers have no idea how to execute a test in our automated test system (I don’t blame them–the test machine is a large, well-oiled beast distributed over dozens of operating environments). Having the knowledge to run test team tests on developer builds means I don’t need to wait for nightly build test results to address issues. More importantly, I can add my own tests to the test team’s automated test system.
3. It’s common for a developer to request more information about a tester’s problem report. My experience with the test team allows me to access the information on test machines myself, saving time for everyone.
4. The test report pages actually make sense. This allows me to investigate test failures in the nightly build before a tester comes to my desk to tell me I broke something.

His experience as part of the test team has been win-win for him and his colleagues. Testing and development sound like allies, don’t they? Well, as much as werewolves and vampires can be allies, I suppose. And he was such a nice guy too, but the change is upon him.

In addition to CWRAF and CWSS the 2011 CWE/SANS Top 25 list has been updated.  There has been a number of position changes and a few that have been knocked out and replaced by CWE-250, CWE-676, CWE-134, and CWE-759.  Not too many surprises but I never really noticed CWE-134 not in the list before.  That certainly makes sense.  However it does shock me that CWE-129 (Improper Validation of Array Index) didn’t make the list this year.  Certainly a problem that I’ve seen a ton, although it was close (#27).  To see Klocwork’s coverage of 2011 CWE/SANS Top 25 go here.

In the final post in this series, I’m going to introduce you to the present day Static Code Analysis technology and how it is impacting developers.

The Present Day

I’m a huge fan of Reece’s Peanut Butter Cups. I love them. I keep active so I don’t feel guilty eating them. In a strange, convoluted way, the 3^rd generation of static code analysis tools are like this delicious combination of chocolate and peanut butter. Let me explain.

Eureka! Now developers are able to perform an analysis locally, using their development environment of choice, while still getting the high accuracy and consistency that was previously only possible by checking in their code and waiting for the integration build to take place.

Think about the ramifications of this:

• cleaner code is being checked in
• the ‘rinse-repeat’ vicious cycle of rework is drastically reduced
• quality teams are now able to focus on testing the product’s functionality rather than spending cycles uncovering something that could easily and quickly be found by automated tools.

Mmmm-mmmm good. Sounds like a win-win-win to me!

I think the best thing about these 3rd generation tools is simply the fact that developers are now able to resume ownership of the quality and security of the code they are producing.

Well, I hope you enjoyed this walk down memory lane. I sure did. Now I’m looking for spare change because I see a trip to the vending machine in my immediate future.

If you want to know more about the 3rd Generation tools, feel free to drop me a line.

The Early 21^st Century

Not long after we first viewed hairy-footed Hobbits on the silver screen, and the sham that was affectionately known as Y2K, a new generation of source code analysis tools emerged to cure the errors of the first-generation tools.

These new tools looked beyond the syntactical analysis of previous tools, and instead provided inter-procedural and data-flow analysis. Low hanging fruit was definitely not the target for these tools.

These new techniques were serious–finding complex defects that could impact code quality and security, and they did that while ensuring that the “noise” (i.e. false positive rate) was greatly reduced compared to the first-generation tools. In addition to local defects, they were now identifying resource management issues, security vulnerabilities, concurrency issues, and so on. These were serious defects that,  if left undetected and unfixed, had the potential for massive problems to the code stream.

In order to perform this much deeper analysis, a fundamental change in the analysis techniques had to occur. These engines needed an unfiltered view of the entire code stream, and so they became tightly integrated with the integration build process.

Umm, Houston, we have a problem. If the analysis takes place at integration build time, then that means the analysis is no longer being initiated by the developers. Source code analysis tools became centralized and moved into a more downstream process such as part of a code audit function.

Developers were now being told they created bugs well after they actually checked in the code. They had already moved onto something entirely different, so now bringing them these day-old, or week-old defects was certainly not the most productive use of their time. It is well documented that the earlier you find defects in your code, the more cost effective it is to fix them, so you can clearly see the problems with these second-generation tools.

If only there was a way to bring these second-generation analysis capabilities to the developer desktop. More about that in my next entry.

I’m happy to say that SCA knowledge has definitely increased over the years, but it is still not up to levels enjoyed by unit testing or integration testing.

What I plan to do over the next three weeks is to provide you with a history lesson on how Static Code Analysis has evolved over the past few decades (yes, it has been around that long!). The three different eras I will be addressing are The Early Years, The Early 21^st Century, and  The Present Day.

The Early Years

As I mentioned earlier, Static Code Analysis has actually been around since the time of bell bottoms, disco music, and Space Invaders (check out the Space Invaders link)–yes, the good ole 1970s. Who out there has heard of Lint (and no, I’m not talking about the fluff coming from your old bell bottoms pockets)?

Lint was one of these first-generation SCA tools introduced in the late 70s. These tools targeted low hanging fruit in C code, such as missing or extra semi-colons, missing curlicues, potentially dangerous implicit casts, and so on.

These tools were closely integrated with the compile and link process, and so this seemed like the best time to show its errors and warnings, while the developer was actually “in process” and fixing problems found by the compiler. Since these tools delivered its warnings at compile time, it quickly became a tool that was adopted and owned by the developers themselves.

Life was good. Well, until the bugs that were being found were deemed to be relatively trivial or completely erroneous (the dreaded false positive). The problem was that these tools were only able to see one file at a time, but for accurate static analysis there is a strong need to know everything that’s going on within the entire stream.

Without that vision of the entire stream, no matter how sophisticated the analysis tools are, they will make incorrect assumptions most of the time. Because of these inaccuracies, these first-generation tools never gained the widespread acceptance of software developers.

Next up will be a look at static analysis tools during a time when “Whassssuuuupp” became a household term.

Glad to see people are thinking about IDEs, but what really intrigues me about this conversation of one IDE versus another is that someone always has to add their two cents about the ancient text editors of the world.   Something like “real programmers use vi”.  Hold the phone.  Are we talking about the same text editor that requires you to memorize a gazillion key bindings?

I don’t get this.  I understand legacy use, as vi was the only available built-in text editor at the time and still is the only choice of hackers today.  But times have changed.  Anyone I’ve talked to who is using vi (or other known text editors like emacs) always seems very proud of it.  Maybe knowing how to use such a complex tool provides some self-worth.  I just don’t know.  Seems like it would be the same as me bragging about my portable Walkman or the 8-track player in my car.

Don’t the features of Visual Studio or Eclipse make you faster?  With a click of a button you can refactor your code.  With simple auto-completion the IDE eliminates simple typing (or even mistakes).  Plus with built-in tools for static analysis, test generation, etc., what are you waiting for?

So you vi/vim/emacs coders out there — tell me why on earth you are sticking with it. What makes you a better programmer using vi/vim or emacs?

Why not toughen up your code by implementing software security best practices that prevent or mitigate the risks?

That’s why you should head on over to the Klocwork Developer Network and check out the free eLearning courses provided by Security Innovation, an industry leader in software security and cryptography. To view learning resources, just log in or register.

Here’s a brief description of each course:

• OWASP Top 10 – Threats and Mitigations

Learn strategies and best practices for understanding, identifying and mitigating the risk of vulnerabilities and attacks within the OWASP Top 10.

• Intro to the Microsoft Security Development Lifecycle (SDL)

The Security Development Lifecycle (SDL), a key security engineering process that was spawned from Microsoft’s Trustworthy Computing Initiative. Learn the necessary steps to meet SDL requirements, and identify the appropriate tools required by the SDL.

• Intro to XSS – Asp.Net examples

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

• Intro to XSS – Java

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

Have fun, code safely and put that Kleenex away (unless it’s allergy season).

I’m not here to talk about the visionaries — they already get it. They know that SCA techniques help find critical issues early in the development cycle. Sometimes SCA finds great stuff, sometimes it doesn’t. But it’s always worth the time, because it makes developers better at what they do. In fact, it’s the visionaries who demand SCA from the outset.

Nor am I here to talk about the fence posts; they won’t last long at what they’re doing anyway.

I’m mostly concerned with the majority, the ones that fall in between. Do they find value in SCA? Will it change the way they develop code?  These developers are quite valued and extremely important to the organization — so much so that they have a full workload and tons of commitments. It’s because of this workload that you typically won’t see a shift in their work culture. When they’re asked to run SCA as part of their development process, they’ll probably accept this and give their honest opinion. They will wait to see whether it finds the so-called “silver bullet” to decide whether they are getting value out of it. In other words, if SCA finds a super-juicy bug that would have been catastrophic, it’s a winner. If not, then you’re probably not going to convince them that SCA is right for them. On top of that, they have a pretty big workload, and SCA is throwing false positives, making them spend more time.

The reality is that with SCA you may never find the silver bullet. The reality is that SCA tools throw false positives. The reality is that it will take some time up front to be proficient with the tools. Yes, these realities suck. But don’t lose focus on the prize. SCA will always pay off in the end. The value of SCA is quite clear these days (see here, here and here).

Okay, so there’s some value despite the realities, but there’s also a hidden value: training. Even though SCA may show you a defect you don’t care about, it gives you food for thought. Coding best practices are a good example. A memory-constrained shop will tell you they always need to check for NULL with memory allocation:

void *blah = malloc(10);
if (blah != NULL){
   /* Do something here with blah */
}else{
/* Do something here if it fails */
}

Surprisingly, others will tell you that the likelihood of running out of memory is very low. So why place the unnecessary checks? This and many other arguments will go on forever. But these type of questions make you think twice: should I be checking for NULL, or should I rewrite my code? So in the end, SCA gets you thinking.

• Summary of various secure coding standards, including links to specific checkers supported by Klocwork
• Free secure coding e-learning courses, including an intro to Microsoft’s secure development lifecycle
• A ‘buyer’s guide’ to selecting a static analysis tool as part of a secure coding program authored by a major payment software company

To build on this, next month our CTO Gwyn Fisher and the CTO of Security Innovation, Jason Taylor will be hosting a talk that expands the discussion beyond secure coding strategies alone. Jason will be talking at length on how to build a threat model for software, in particular embedded software. Gwyn will then walk through how customers should be building their software with this threat model in mind – everything from code reviews to static analysis and testing strategies. I urge you to register for the webinar and check it out – there will be lots of good information being discussed.

Yes, except it is probably not what you’re thinking, it’s not the same as a memory leak;  a memory overflow is quite different.  A memory overflow is really just a form of a buffer overflow.  The impact of memory overflow is unexpected behavior or program failure.   Take this example:

#include <stdio.h>
typedef struct s1_ {
   int i;
   int j;
   char arr[10];
}s1;

typedef struct s2_ {
   char b[20];
   char c[40];
}s2;

main()
{
   s1 block1;
   memset(&block1, 0, sizeof(s2));
   block1.i =1;
}

Here we have the case of incorrectly using ‘memset’ at line 16 where ‘sizeof(s2)’ is bigger than ‘block1′.  In fact, going back to this customer revealed that the issue was due to memset clearing much more area than intended.  If you’re using static analysis or source code analysis tools then you are probably covered by this.  You will find this type of issue usually in the “buffer overflow” category.

So, are you free of your memory overflows?

The answer: Klocwork Developer Network–a new online portal designed for learning, sharing and discussing all things source code analysis. We have had a lot of fun and a few sleepless nights as we assembled industry knowledge, online forums, computer-based training, best practices from industry experts, and lots of reference and learning resources.

A significant portion of the content on the Developer Network is open for public consumption. By registering and logging in, you get additional videos, demos, CBT and more.

We have a lot of fresh content to add to the site in the upcoming weeks and months, and we want to hear from you about what you would like to see. Why not register now at developer.klocwork.com? Then tell other Klocwork users about the portal too.

Visit Klocwork’s Developer Network at developer.klocwork.com.

Already a my.klocwork.com user? Access the Klocwork Developer Network using your existing my.klocwork.com login. (But note that my.klocwork.com remains the place to go for support tickets and for FTP access to the latest software releases.)

This article makes ridiculous claims. About the only thing Mark got right was that static analysis has been around for a long time. However it’s ludicrous to think that they’re the same as they were in the past. That’s like saying computers from decades ago are the same as today. The advancement has been huge for static analysis tools, especially in the last couple of years.

The author is really selling the merits of dynamic testing, which is great. Everyone should have the proper testing procedures in place. But static analysis is complementary–it’s another tool that will help you go through ALL the paths of your code to help you find bugs you’d otherwise miss.

One of the biggest reasons static analysis tools have taken off, in my opinion, is the level of integration. It’s quite simple to get results with static analysis tools with little effort. Especially compared with dynamic analysis tools.

Paul Anderson, a fellow competitor, sums it up very nicely in the comments. Check it out.

Static Analysis Tools Not Created Equal

Yes, it’s true (!) and as anyone in this space knows there is a huge difference between static analysis tools, their level of sophistication, and their approach to developer adoption. Gary McGraw & John Steven from Cigital describe their views on this topic including ‘5 pitfalls’ that customers should avoid when evaluating tools. These pitfalls mostly amount to the fact that analysis results across different tools, code bases, and tool operators can make results vary significantly, so be aware of this fact when conducting your benchmarking. Their overall recommendation:

“The upshot? Use your own code instead of a pre-fab evaluation suite. You probably have the makings of a good set of tests within your own organization’s application base….”

I agree with this and can honestly say we rarely, if ever, run into evaluations where customers exclusively use pre-fab test suites instead of their own code for many of the reasons outlined in their article. So, I’d say the market is (and has been for some time) embracing this recommendation wholeheartedly. So, beyond this recommendation, what else should customers consider when evaluating these tools? Here are a couple other significant areas to consider where you’ll find that, yes, all tools aren’t created equal.

• Environment support. In particular in the embedded software space, considerations such as integration with your build environments, compiler support, ability to work with multiple software branches, are all crucial considerations for a successful deployment. Not all tools have good support in these areas, but these capabilities can often make or break a deployment.
• Developer adoption. This is everything frankly, and a big part of achieving developer adoption is the quality of the analysis issues raised in the article. Obviously, a tool that generates accurate, useful results will get you well on your way to strong developer adoption, but that’s not everything. How are the defects described to developers, including the trace info? Do developers want to run their own desktop static analysis rather than fetching results periodically from the integration build? If so, how smart is the vendor’s desktop analysis?

So basically, picking a tool boils down to assessing: quality & flexibility of the analysis, support for your dev environment (not just the one you’re using in the eval!), and thinking ahead to developer adoption issues. Assess these three areas thoroughly and you’ll end-up picking the tool that’s right for your needs.

The two sides of testing team lead Jonathan Patchell.

At daily standup meetings, they eye each other from opposite sides of the room. Sitting on the same side of the cubicle wall is unthinkable.

They’re united only by their desire to produce quality software products and their appreciation for coffee and energy drinks. What’s good to one side can be anathema to the other when it comes to code.

I’m talking, of course, about testing and development teams. In the interests of generating more comments improving dialogue between two very important functions in a software organization, our marketing director asked me to interview our testing team lead, Jonathan Patchell, about the ways in which developers drive his team nuts.

Patchell, a computer systems engineer, has been with Klocwork for five years and a team lead for two. He struck a fairly conciliatory tone for this interview, which sorta ruins the adversarial approach, but don’t let his diplomacy fool you. I’ve seen him suffering as the release date approaches and his demeanour changes completely.

Here are Patchell’s top dev peeves:

A static analysis backlog is created when you run a static analysis product on your code base for the very first time. Chances are pretty good that the first analysis is going to list a large number of defects, some that are without question real, and some that perhaps are not. Do not freak out! This is the first time that analysis engine has ‘laid eyes’ upon your code and it is going to flex its muscles and show you any weaknesses it believes exist. So how does one deal with this? Here are a few strategies to help you:

1) Don’t boil the ocean. Before you even run that first analysis, don’t have a “wouldn’t it be cool” moment, where you decide to turn on every single rule the analysis engine has. There is a reason why static analysis tools haven’t turned on everything.  They are showing the most accurate and critical issues first.  So unless you have unlimited time and resources, your best bet is to start with a core set of rules and run the analysis based on that set. This core set of rules should include things such as memory/resource leaks, buffer overruns, null pointer dereferences, uninitialized variables, and so on. Add other rules once you have this core set under control.

Is your issue backlog making you cross eyed? Try these coping strategies.

2) Baseline your defects. Consider that first analysis your baseline and choose to ‘park’ them for the time being. Chances are the product that the analysis was run on is one that has already been released to the public, and in good working order. Zero out these defects for now, and start to triage them, which leads into strategy #3.

3) This is going to sound pretty obvious, but when it comes to managing your issue backlog start looking at the most critical issues first. These are the ones that are most likely to cause a failure of some sort, so determine if these issues are real, and if so, fix them immediately. Once you’re done with the most critical issues, move to the next level of severity, and continue on that way.

4) Finally, tune your analysis. Any good vendor will allow you to tune your analysis. The benefits of tuning are twofold; 1) you can find code issues that would otherwise go undetected and, 2) reduce the number of issues that the engine reports incorrectly in the context of your source code. You should think of ways to give the tool more context about your code base to increase accuracy.

If you follow these suggestions, you’ll definitely have a better grasp of your bug backlog, and you’ll be able to execute on reducing that backlog quickly and efficiently. If you don’t, then at some point, you may feel a little like the critter pictured here.

If there are any other strategies you’ve tried to deal with your bug backlog, leave a comment or two. I’d love to hear about them.

Let me tell you about an experience I had. I used to own a smartphone running Windows Mobile 6.1. I loved the phone when I only used it as a phone, but simply hated it when it came to applications. There were thousands of issues I could have pointed out. The end result is that I am not going to purchase another Windows smartphone. Do you see where I am going with this?

Consumers always rely on their memory associations, whether conscious or unconscious, when it comes to purchasing new products. I would say almost everyone would not go back to using a product they’ve had a bad experience with when there are so many other options around. This goes the same for mobile application developers and development firms. I have uninstalled so many applications from my Nexus One within the first few minutes of their lives. It wasn’t because of the features they didn’t have or how horrid the GUI was. The main reason was they weren’t working the way they were expected to. Some users even kiss applications goodbye altogether according to this survey based on such experiences. Let me put it this way:

“If your code is not flawless, you will lose your market share and never be able to recover it.”

Application developers strive to develop new features giving them the competitive advantage or as my friend and mentor, Bruce Firestone, calls it “Pixie Dust”. This is completely the right thing to do; however, they should focus more on their apps’ perfect functional execution. Having a limited number of features that work exactly as the user expects is better than having more numerous, but buggy features. I know it sounds like a no brainer, but the success of a small number of apps as opposed to the thousand other ones doing the same thing should serve as sufficient evidence that it is easier said than done.

Buggy code hurts the application and the developing company’s brand. Making sure your code is near perfect would be a strategy I would like to call the Pre-Branding Protection Plan. With the abundance of competitors in the mobile gold rush, bad apps will almost permanently prevent market recovery and destroy sales.

One method I use to make sure my brand would be protected is using J2ME static analysis tools. There are various paid and free tools, but I am very happy with the Klocwork Solo, which is geared for J2ME developers. I had never used such tools and only started using them when I joined the company. I don’t know what I would do without them now. In my next posts, I will discuss some of the issues the tool caught that improved my productivity and the efficiency of my code.