Secure Programming Matters

An editorial in an IT magazine suggested that secure programming is a waste of time and money. I strongly disagree. Of course, I work for Cigital, a company that specializes in software quality. So, I have a particular axe to grind here.

Andrew Briney wrote an article entitled Secure Programming: BAH!. To some degree, this is just a publicity stunt to stir the pot a bit. On the other hand, I worry that people will buy into his arguments, and not take them tongue-in-cheek.

He says:

Yes, it’s faster and cheaper to design security into software than bolt it on afterward. But it’s even fasterer and cheaperer to build crappy software to get the project rolled out immediately, please your boss and help the company make its quarterly number. Guess which path most organizations will always take.

I would argue that there is a fixed amount of cost take-out you can achieve by building the crappiest software that could possibly work. That is, there is a minimum amount of real work that must be done that will satisfy the customer. If the minimum cost is $X, then there’s a cost $X + $Y which is the cost of doing it with secure design up front and so forth. The most you can take out is $Y. His argument is that $Y is so large, a manager will always want to take it out so he looks good.

On the other hand, there is no real limit to the amount of damage that can be done by a sufficiently badly done flaw or bug. A sufficiently bad implementation can cost an arbitrary amount of money. Consider this blackmail that was the result of quickie implementation.

A virus cost a company $75K/day plus expenses. The virus exploited badly designed software.

I think his argument about forgetting secure programming is like charging all you want to credit cards, but only ever making that “minimum payment.” on it. It is not a sustainable way to live, but it can give you a few years of living like a king. You’ll never clear the debt and eventually you go bankrupt. You lose tons of assets and you start over at a terrible financial position. If you totally neglect secure programming, then you are acruing “security debt” and never paying it off. Eventually it will bankrupt you.

What frightens me most about his argument is that it can appear true from the individual project manager’s point of view. People’s careers are so fluid that they can jump from job to job, successful project to successful project, leaving a wake of excellent references, but horribly insecure software at each site. Their resume looks awesome, their pay ratchets ever skyward, but the quality of software is completely unaddressed. Eeek.