My Love/Hate Relationship With Static Code Analysis Tools

I have a love/hate relationship with static code analysis tools. On the one hand, they’re great at helping teams eliminate substandard code practices, especially those that may potentially result in security problems. On the other hand, they’re widely misunderstood and misused, as well, and most often often by management.

On the face of it, static code analysis tools like Fortify (a commercial tool — probably the one with the most name recognition) and Brakeman (the best tool for Ruby/Rails code) seem like an awesome idea. Rather than relying on diverse software development teams throughout the organization to properly and regularly follow best practices for coding and handling application security, let’s encode the best practices into a tool that will parse and analyze the team’s code and point out deficiencies.

Let’s parse that last sentence above a bit more closely. There are two phrases that are potentially problematic: “best practices” and “deficiencies.”

Who decides on the best practices that need to be followed? And who says that code is deficient if it doesn’t meet a best practice that the tool checks for?

The reality is that it requires judgement to assess whether a “deficiency” pointed out by a static code analysis tool is actually a problem that needs to be addressed. The only people with the technical understanding to exercise this judgement are typically the members of the development team.

It could be that the tool is overzealous in pointing out a particular type of flaw. This is true, for example, with Brakeman, which essentially attempts to stamp out any instances of metaprogramming. Brakeman flags every instance of dynamic code generation using eval( ).

Using eval( ) is not evil. It’s part of the Ruby language for a reason. It is potentially problematic if the code being executed by eval( ) is derived from user input, since a nefarious user could try to compromise the system. But determining whether the use of eval actually is a problem requires judgement, which in turn requires an understanding of the technical context of the code.

As a developer, I want to write the best code possible. I love static code analysis tools because they help me identify potential problems in my code. I’m capable of exercising the judgement to determine what does, and does not, need to be changed.

However, that determination is often not in my hands, and that’s when I start hating this type of tool. You see, management loves static code analysis tools.

Fundamentally, management doesn’t understand what software developers are doing, which is uncomfortable for management. Ultimately, management is responsible for what software development teams create, but typically doesn’t have a deep understanding of the end result.

Accordingly, management clutches on to static code analysis tools like a drowning man will latch onto a life preserver. It’s a way for them to verify that good software is being produced. It’s like the ultimate checkbox for them.

This is how using Fortify becomes an mandated best practice for government projects. Even for Ruby products, and even when the Fortify module for analyzing Ruby code is just simply awful.

Even worse, once the use of static code analysis tools become mandated, then other rules get added on. “You must submit a copy of your Fortify results with each software release.” And my favorite, “You must provide a detailed, written justification for each deficiency that is not corrected.”

This is where I start to hate static code analysis tools. Because now I have to waste valuable time to write a justification for a non-technical person who generally really doesn’t understand the issues on why I didn’t fix a “deficiency” in the code. Management often doesn’t understand that “false positives” happen or that dynamic coding (in the case of Ruby) is useful.

This is why I have a love/hate relationship with tools like Fortify and Brakeman. I love them because they help me, and my teams, to write better, more secure code. But I hate being bludgeoned by their results when the capacity to properly evaluate their output is taken away by management.

About the Target Attack

For those who might be interested in what really happened during the recent Target retail attack, where information about 40 million credit cards was stolen (including mine), here’s a really interesting article from Security Week:

http://www.securityweek.com/target-confirms-point-sale-malware-was-used-attack

In a nutshell, the attackers used a RAM scraper to pull credit card information that was stored “in the clear” within memory.

And yes, I was issued a new card because of this whole fiasco.

Domain Names for Non-Techies

One of my non-technical friends, a writer and motivational speaker, bought a new domain name recently, then asked me how to get it pointed to her soon-to-be-rebranded website. The ensuing discussion revealed that she, like most non-techies, knew next to nothing about domain names, other than that “she needed one.”

Since I suspect there are many other people around just like her, I thought it might be a good idea to demystify domain names. So, let’s go on a tour through the wild, wild badlands of the Internet.

A Registrar is a company that has been authorized to register (and accept payments for) domain names.

A Hosting Company provides computers on the Internet that can host web sites. For small sites, which pretty much defines the kinds of sites that writers and motivational speakers have, they’ll usually host multiple web sites on one computer. Sometimes Registrars also function as Hosting Companies to secure additional income, but the two roles are distinct.

Every computer on the Internet has an ugly, non-intuitive address that looks something like this: 123.10.234.56. That’s known as an IP Address. They’re not very easy for people to remember. So some bright people invented Domain Names, which are like relatively easy-to-remember names that can “point” to an IP Address.

Except that it’s not quite that simple. How do you find out what IP Address a Domain Name points to? You could query every computer on the Intenet: “Hey buddy, do you answer to keenertech.com?” But that might take a while.

So somebody really devious came up with the idea of the DNS Name Server, which is basically a computer that 1) holds information about a whole bunch of domain names and where they point to, and 2) can respond with the correct IP Address if you politely ask it about a domain name. But, sometimes computers crash, so most people who run DNS Name Servers also run a backup server just in case the first one fails.

Now we come to the fun part. Your Hosting Company has DNS Name Servers associated with your hosting account. You can usually look up what they are using some via sort of “Dashboard” or “Control Panel” that they provide to their customers. When you find their DNS Name Servers (sometimes they’ll be listed as just “name servers”), record that information.

Next, you need to login to the Registrar, who generally has their own Dashboard or Control Panel, and tell them what DNS Name Servers will be associated with your domain name. By default, they’ll list their own name servers — you want to change the name servers to the ones from your Hosting Company.

Back at your Hosting Company, you need to create a web site, generally something that can be done via their Dashboard. Next, you need to tell them, via the Dashboard, which Domain Name will point to your web site. They’ll make sure their DNS Name Server properly directs Internet users to your web site.

If your Registrar and Hosting Company are the same, then they’ll already have them handled by a DNS Name Server. All you’ll have to do is configure your web site so that the Hosting Company knows what Domain Name you’re using.

Once you set up your Domain Name to point to your web site, you may have to wait a few hours for this to propagate outward so the rest of the Internet knows where to find your web site. You should double-check to make sure that both your Domain Name and your Domain Name preceded by “www” point to your web site.

Awesome! Now you’re using a real Domain Name, and look look so much more professional than all those other folks using derivative and unprofessional addresses like great-speaker.blogspot.com. If you have any problems, check the documentation on your Hosting Company’s web site — setting up Domain Names is a common problem that they deal with all the time. If all else fails, don’t be afraid to send an email to Customer Support — they will help you out.

I hope this tour of IP Addresses, Domain Names, Hosting Companies and Registrars has been useful to some of you.

Rails 3.1 Released

In case you haven’t heard the news, Rails 3.1 was released today. Lots of incremental improvements, including built-in SASS support, JQuery as the default JavaScript library, the “asset pipeline,” etc.

Git Giggle

Many thanks to Jonathan Quigg for pointing me towards Git Giggle, a UI tool that allows you to visually explore how a file in your Git repository has changed over time. Forget “git blame,” this tool is much more informative.

Reading “Eloquent Ruby”

I’m currently reading Russ Olsen’s new technical book, “Eloquent Ruby.” It’s an excellent book. I particularly like its focus on what it takes to be a truly good Ruby developer, rather than just teaching Ruby syntax. It’s a great “next book” for the developer that has learned Ruby, and now wants to learn how to use it properly and effectively.

WordPress and Zombies

This is a an excellent WordPress presentation from Brad Williams, the author of “Professional WordPress Design and Development.” The presentation provides detailed examples for creating custom post types and custom taxonomies in WordPress 3+, but with a distinct and humorous zombie flavor.