Code Blue!

How do you rank the severity of application defects? Some test teams assign severity/priority scores, but that’s arbitrary, and doesn’t reflect the real-world impact of bugs. How can you really assess the importance of something that’s rated “medium” for severity but “low” for priority?

More practical dev teams use expressions to communicate, through the defect database, change-management system, email or sticky notes, how important a defect is to the team. “This one’s a show stopper,” you might say. Or “If you can fix this before the next release, that would be great,” you might comment. Or “Who cares about a teeny-weeny typo?” you might write. Or “Sheesh, this one’s definitely gonna get us sued,” you might opine. Isn’t that better than “high,” “medium” and “low”?

However creative that approach is, the expression-based defect ranking system does leave things to interpretation. One person’s “it’s a teeny-weeny typo” is someone else’s “clean out your desk and be out of here before the cops come,” especially if that typo was in your CEO’s name, or in one of the digits in your upcoming Securities and Exchange Commission filing.

Similarly: While your CFO might issue a scathing four-letter expletive in both cases, which is worse: a bug that applies the wrong algorithms to stock-options pricing, or a bug that applies the wrong algorithms to a credit-scoring system? Selecting the “we’re totally screwed” button in the issue-defect system’s severity/priority may not accurately communicate the CFO’s displeasure.

The right solution, as I’m sure you will agree, is to hand these sorts of things to the U.S. Government. No, not the actually grading of your software’s bugs, you silly person: that’s your job, and you can’t get out of it. No, we should take a leaf from how our benevolent authorities have responded to airport security. You don’t hear the public address system at the airport say, “We’re at terror level we’re-going-to-die.” That would cause panic. Worse, it is ambiguous, since it doesn’t communicate who is going to die, when this will take place, and if you have time to buy a $5 Bloody Mary from a flight attendant beforehand.

Instead, as I’m sure you know, the monotone announcement on the P.A. system says something like, “Attention: We are at Homeland Security Threat Condition Orange.” This is more practical, and more useful, because it’s from the government and they know best.

That, my friends, is the model that software test/QA professionals should use when communicating with end users and other stakeholders about bugs, when assessing the bugs for ourselves, and when classifying said bugs in the defect database.

“Hey, Bob, looks like we’ve got a nice, juicy Yellow here,” you might hear shouted over a cubicle. “Are you sure it’s not Orange? We’re only fixing Oranges before the next beta,” you might shout back. And so-on and so-on.

The U.S. Government’s colorful Homeland Security Advisory System (HSAS) was enacted in March 2002. Forget about those silly “low,” “medium” and “high” scales that you see so often in defect-management systems: the HSAS goes much farther with five levels:

Red = Severe: Severe Risk of Terrorist Attacks
Orange = High: High Risk of Terrorist Attacks
Yellow = Elevated: Significant Risk of Terrorist Attacks
Blue = Guarded: General Risk of Terrorist Attacks
Green = Low: Low Risk of Terrorist Attacks

Brilliant, brilliant, I can hear you saying. Go ahead, say it again. Brilliant. Thank you. You can see instantly why this is appropriate for software development and test/QA. I would humbly propose the following scale for categorizing software threats. Actually, I would like to propose two scales, which I call the Software Defect Advisory System (SDAS). The first SDAS scale is the one that you tell your end users, managers and other stakeholders about, and which they use for reporting bugs to your test team:

Red = Severe: This Must Be Fixed Immediately
Orange = High: This Should Be Fixed Soon
Yellow = Elevated: Fix This When You Can
Blue = Guarded: Fix This Sometime, Maybe
Green = Low: Just Thought You Should Know

The other SDAS scale, of course, is more important, because it’s the one you use to categorize actionable issues in the defect database:

Red = Severe: This Will Get You Fired
Orange = High: This Probably Will Get You Fired
Yellow = Elevated: This Might Get You Fired
Blue = Guarded: This Probably Won’t Get You Fired
Green = Low: This Is Just Stupid

Follow this system, my friend, and you’ll never get scolded for misspelling the CEO’s name, or miscalculating stock option prices, ever ever again.

Bite Vulnerabilities Before They Bite You

April 1, 2007 — Firewalls are great if you’re worried about barbarians attacking your front gate. Intrusion detection systems are fine, if your goal is to see if unauthorized traffic is on your LAN; intrusion prevention systems work in conjunction with your firewall to block that unauthorized traffic.

Bah. Firewalls, IDS and IPS systems, as well as anti-virus solutions, spam filters, worm detectors — they’re all worthless, absolutely worthless, when it comes to attacking the real causes of software security failures. So, too, are checks against buffer overflows, cross-site scripting and SQL injection. While those vulnerabilities can trip up an unwary programmer, they’re easy to catch. Just about any static or dynamic code analyzer can find those problems. The real challenge is how to handle the most significant software security challenge of our time.

Puppies.

Yes, my fellow software architects, developers and test/QA professionals, the biggest threat to our software infrastructure, and the integrity of our data, is puppies. They look so cute, don’t they, with their lolling pink tongues, soft waggly ears and short little legs. They roll and play and want to be cuddled. But don’t be fooled. Puppies, those innocent little puppies, are placing your enterprise software in deadly peril… and your CEO, if the puppies start messing with your Sarbanes-Oxley systems. He’ll be going down the river… and you’ll be down there with him, if you don’t take action now.

Where did this insidious threat come from? It’s hard to know. Perhaps the first puppies merely wanted some fun; they wanted to show off in front of their litter mates. Nobody picks on the runt, you see, if he can erase breeding records with the click of a mouse. But then things got worse. Government agencies and their espionage programs. The military. Commercial interests. Terrorists and rogue states. They learned how to use puppies to bypass virtual private networks, routers, firewalls. How in the face of a determined puppy, even 256-bit AES encryption is about as effective as an old, battered squeaky toy. Buffer overflow exploits? Ha. Puppies sneer at your pathetic algorithms; you might as well not bother.

The puppy threat is years ahead of our technology. Check your Tivoli, your OpenView, your Unicenter TNG, even Microsoft’s MOM. Do any of them detect puppies? Not the latest versions, and not the current betas. Do they have any facilities for neutralizing the puppy threat, once detected? Not a chance. Microsoft Research, the T.J. Watson Laboratories — they’re hopeless. The experts at the Carnegie Mellon Computer Emergency Response Team are asleep at the switch. The Computer Security Institute doesn’t have a clue. Even the U.S. National Security Agency and Department of Homeland Security lack contingency plans to protect our vital enterprise software from the puppy scourge.

You should pool your resources with the rest of the IT team. Gather up your LAN and WAN managers, end-user support teams, data center managers, test teams. Heck, even bring the code librarian. Get the CIO or CTO to bring the team together — there’s no time to lose! Check out the RSA Conference or the Software Security Summit, neither of which (surprise) have classes or tutorials on puppy threat management. Ask, no, demand that they address this issue immediately We need classes. We need patches. We need an action plan!

Puppies. This time, the rolled-up newspaper is not going to be enough. Let’s get to work, people, before it’s too late.