Programmers Learn to Check Code Earlier for Holes

Carl Bialik from WSJ writes "Many companies are teaching programmers to write safer code and test their security as software is built, not afterward, the Wall Street Journal reports. This stands in contrast to an earlier ethos to rush to beat rivals with new software, and, of course, brings tradeoffs: 'Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.' The WSJ focuses on RIM and Herb Little, its security director, who 'uses Coverity every night to scan the code turned in by engineers. The tool sends Mr. Little an email listing potential red flags. He figures out which problems are real and tracks down each offending programmer, who has to fix the flaw before moving on. Mr. Little has also ramped up security training and requires programmers to double-check each others' code more regularly.'"

Comments

This just in:

[r_jensen11]

Writers are encouraged to proofread.

Re:This just in:

[Anonymous Coward]

No point you proofreading you own code. You see what you think you've written, not what you've actually written, therefore don't spot any problems with it.
The trick is to get 2-3 other people to review it.

1. The earlier you spot a defect, the cheaper it is to fix.
2. Test results are only as good as the test code written.
3. Edge cases don't normally show up in test code. Test cases are typically designed to show that the code works, rather than finding the boundary where it fails.
4. You can suggest better ways of writing the code/learn new tricks during code reviews.

I hold any bet

[Opportunist]

After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.

After all, that's how the software market works. People buy anything. "LOOK! THE NEW (insert program/OS name here)! I MUST HAVE IT!"

Stable?
Secure?
Mem-leak free?
In one word: FINISHED?

Who cares? It's new, it's shiny, it's been all over all the mags and preview pages, the hype is on, WANNAHAVE!

And as long as we keep buying the unfinished crap, it won't change.

Yes, I'm sure everyone in the tech departments would see this as the right way to go. Test your software, preferably during development, not afterwards. Go through memleak tests, go through stability tests, have some experienced whitehats poke at it, and if it survives, let it go into beta.

If anyone gets that idea past marketing, I will bow down to him.

Catch-22

[kentyman]

Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.

That's not a Catch-22. That's just a tradeoff.

Ain't gonna last

[FiveDollarYoBet]

Those aren't security holes.... They're undocumented network transfer features!

It sounds good and all but there's a direct correlation between the deadline and how bullet proof the code is.

insert sig here

That's why...

[GillBates0]

I always make sure I use the highest quality bits when I program. You'll find none of those low-quality, flimsy and occasionally perforated bits in my code.

Agreed, periodic checking for holes has it's own value, but nothing beats using the best quality, industrial-strength (tm) bits to start with, moreso while developing reliable software in the post-911 world.

Thinly veiled ad?

[Mr Z]

Is it just me, or does the article just read like a thinly veiled advertisement for Coverity? It's reads like a generic commercial template: "Meet Bob. Bob thought everything was fine. But then he discovered he had Problem X. That's when Bob discovered Company Y with Solution Z." (etc. etc.).

Good at publicising themselves

[derek_farn]

Tools are a cost effective way of checking source for lots of different kinds of problems. I have no direct experience of the Coverity tool, but see that they are certainly good at getting lots of publicity. A List of static analysis tools is available on Wikipedia.

Re:static_analysis++

[Stellian]

Enough whith Coverity allready. It's like the 50th slashdot article that talks about this.
FYI, it costs about 50.000 $ for a medium sized project (500.000 lines), and is no more than a lint on steroids. Here is a somewhat cheaper competitor.
None of this tools is a mach for a manual audit performed by a professional.

Re:static_analysis++

[Coryoth]

Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works.

Unit tests don't prove your code works any more than drawing a few right angled triangles and measuring the sides proves Pythagoras' theorem. If you want to prove your ode works you use a theorem prover. To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function. That tends to be more work, though if you really need to know your code is going to work it can often save time in the long run (over ridculously long and exhaustive testing). There are things out there that provide toold support for theorem proving aout your code: SPARK Ada along with the SPARK tools provides a powerful theorem prover, and HasCASL with CASL tools (including the HOL theorem prover) provides string theorem proving for Haskell. Even ESC/Java2 utilises a theorem prover (called Simplify) to provide extended static checking of Java code. I'm sure there are more examples.

My point is not that Unit testing is bad (it's very good), but that you shouldn't overstate its effectiveness. Unit tests are a great way to provide a reasonable degree of assurance that your code will hopefully ork as intended. It isn't a substitute for actual assurance however. It really depends on exactly how sure you need to be - how much an error will cost, and whether that can be tolerated.

Jedidiah,