I came to the practice of procrastination late in life. I was always one of those annoying people who arrived for appointments early, handed in assignments early, went to bed early.

Becoming a full-time working parent drove me to the dark side.

Now I’m routinely late — late for exercise classes, late going to bed, late getting the kids to daycare.

My forgetfulness factor has increased about 26-fold too. I’ve always been a list-maker, but now I have a few sayings that my husband is sick of: If it’s not in my calendar, it’s not getting done. If it’s not on the grocery list, it’s not going to show up in the fridge.

My work equivalent: If it’s not in XPlanner, it’s not getting done.

However, I’ve also discovered that adding tasks to XPlanner is a necessary but not sufficient condition for something getting done. Ever so occasionally, I’ll realize that a task in my slightly overlong list of tasks for the iteration should have been done… yesterday.

In my pre-kid years (which incidentally and unfortunately coincided with the days of larger doc teams), that just didn’t happen. I had sufficient brain space to accommodate what needed to be done.

My colleague Patti and I decided to elevate this practice of procrastination in agile documentation by giving it a name:

DOCRAGINATION.

Fortunately, in my latest slip into docragination, I got away with it: I wasn’t the only reason for another software build.

As I get older, I’m growing more certain that procrastination in general is not always a bad thing. There’s something to be said for waiting, listening, processing — even sleeping on it — instead of rushing in and finishing.

Patti just reminded me of another of my annoying sayings: What doesn’t get documented today won’t have to be revised later.

Our marketing people here at Klocwork like to see me racking up frequent flyer miles and expending CO2 at roadshows, conferences and tradeshows. Whenever I’m out speaking, I always like to gauge audience familiarity with Static Code Analysis.

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.

I’m sure this topic has been discussed a million times, but hey, here we go again.  A recent question came up on whether people liked their experience of Eclipse vs. Visual Studio.  Of course this brought up the advantages of one versus the other.  But is that really a fair comparison? It really depends.  What type of application are you building — a native Windows application?  Surely going with Visual Studio makes sense. But if the goal is cross-platform, then you might look at Eclipse.

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?

A while ago I talked about memory overflows.  Now in this latest instalment, as we look at more interesting bugs, I’ve come across a new example.  Here is a situation described by a customer as “stack smashing”, which occurs when you copy a string of unknown length into a fixed buffer size.

#include <stdio.h>;

void foo(char * v) {
    char buffer[10];
    if(v != NULL)
   {
            memcpy(buffer, v,strlen(v));
    }
}

int main (int argc, char ** argv)
{
    foo(argv[1]);
    foo("the longest string you can find");
    return 0;
}

Just like the memory overflow post this is another form of a buffer overflow.  So there you have it, just more terminology to describe bad things in your code.  Gwyn promises to give a follow up to these posts with some details on how this general area (stack corruption, tainted sources, etc.) can be exploited.  Can’t wait to see that.

Crying into your wadded Kleenex about how your vulnerabilities were exploited may make for compelling TV, but when it comes to software security, they’ll cost you a lot more than your personal dignity. Or maybe they’ll cost you millions of dollars in lost business and your personal dignity.

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).

Will source code analysis (SCA) or static analysis change developer culture? The answer really depends on the developer’s skill set. In my experience, there are developers who are excellent at what they do (visionaries), and then there are some that just don’t get it (fence posts).

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.

We’ve talked at length before regarding software security assurance and the role static analysis can play in ensuring code is written securely. We’ve got a bunch of great resources for anyone looking to dive into this particular aspect of software security:

• 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.

A few years back a customer said they had all kinds of trouble with bugs corrupting their stack.  Even though they asked if source code analysis tools could help find stack corruption, once we got an example, we found that they were really looking for was memory overflows.  So what on earth is a memory overflow?  Does that even exist?

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?

Last week I toured the West coast with our friends from VersionOne, Perforce, and Electric Cloud on our Agile roadshow hitting the cities of Seattle, Santa Clara, and San Diego. In one of the after meeting discussions, one of the attendees asked me what the differences were between Agile and Lean. Having only been involved with Lean from an outside perspective, I didn’t really think there were huge differences and that they shared many of the same beliefs.

Luckily, it looks like others believe this to be the case too. So rather than me trying to explain this, this timely blog does a great job of explaining Agile and Lean, and why there is a lack of understanding and acceptance of Agile practices in many companies that practice Lean.

Also, as part of this Agile roadshow, we had a bit of a celebrity in our midst--our illustrious keynote speaker David Hussman of DevJam consulting has a past that most of us weekend musicians dream about. He was part of a big-hair metal band! Not only can he play a mean guitar, the dude knows his stuff about Agile and gave one of the best keynotes I’ve ever seen. Check out his website when you get a chance, and see if you can find him in this video.

Our dilemma: How do we remove the barriers to knowledge about Klocwork’s toolset and developer best practices for creating high-quality code?

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.)