Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programmers Learn to Check Code Earlier for Holes

Zonk posted more than 8 years ago | from the good-practice dept.


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.'"

cancel ×


Sorry! There are no comments related to the filter you selected.

This just in: (5, Funny)

r_jensen11 (598210) | more than 8 years ago | (#15264310)

Writers are encouraged to proofread.


SirJaxalot (715418) | more than 8 years ago | (#15264445)

Seriously, slashvertisment/in bed with Bailik crap.

Re:This just in: (3, Informative)

AcidTag (528338) | more than 8 years ago | (#15264636)

The difference is that writing a paper that can stand a proof-read means it has one execution path, you read the article top to bottom and are done.

A program has any number of execution combinations, and without a decent test-harness some paths may not be checked. If ever piece of software written was tested in every concievable scenario we wouldnt have any bugs, when that day comes I'll be a happy coder. The more 'features' one adds to a program, the problems of detecting bugs increases. Simply creating a piece of code once that doesnt break, doesnt mean the addition of more code that does something else wont break the older code.

So for every new line of code, you have to go back and verify that all the previous lines of code have no negative outcome to the new line. So we developers use our experience and foresight to hopefully avoid this problem, but the problem can still occur... How many rev's of the Linux kernel we upto now?

But what is a Bug? Is it simply that a new piece of code was written poorly?
Is the bug the new code you wrote, or the interaction with the old code? I can write solid bug free code all day long, as long as it doesnt have to interact with anything.

Re:This just in: (2, Funny)

orielbean (936271) | more than 8 years ago | (#15264700)

This just in after that : Business models sacrifice quality for speedy delivery of product. :-)

Re:This just in: (1)

Andrzej Sawicki (921100) | more than 8 years ago | (#15264803)

You have no idea how insightful you sound to a translator...

Re:This just in: (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15264823)

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.

Re:This just in: (1, Informative)

Anonymous Coward | more than 8 years ago | (#15264943)

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

Not if management alots the proper amount of time to the project instead of ignoring the proper testing and extra time that unexpected problems always eat up.

Re:This just in: (0)

Anonymous Coward | more than 8 years ago | (#15265112)

Not only that, but this isn't a catch 22. It's called a tradeoff, of course being more careful requires more up-front time and a bigger budget. And management would rather see late shipping than going overbudget, as customers are probably already sold on the product, or in the case of custom work the software is already paid for. The loss of respect your company recieves is something that can be passed off to someone else. Going over budget is something a manager is held accounted for immediately.

What's the saying: Quick, Cheap or good: pick two. (And actually, you can sacrifice two of those to excell in one area. Low quality and you get it whenever, and it can be extremely cheap: picture bargain stores, dollar stores, overstock stores etc and the merchandise they carry. Very high craftsmanship merchandise takes time to make and the materials can be quite costly. A microwave burrito takes very little time to get ready to eat, but costs more and is not as good healh or tastewise as a home-cooked meal.

static_analysis++ (4, Interesting)

tcopeland (32225) | more than 8 years ago | (#15264311)

Static analysis is great stuff. I've worked on an open source Java static analysis tool, PMD [] , for the past few years and I've gotten lots of feedback from folks who have used it to find all sorts of things in their code. Just a quick scan for unused variables can yield some excellent results, and the copy/paste detector works quite nicely too. And there's a book, too! []

Coverity's doing a nice job with their tech marketing, too - l think a couple of open source projects are using the stuff they found to clean things up. At least, there's been a fair amount of traffic on the Ruby [] core list about some things Coverity's scan found. Good times...

Re:static_analysis++ (2, Insightful)

Jonboy X (319895) | more than 8 years ago | (#15264534)

Umm, about your comment: The link goes to a blog entry of yours about the inefficiency of using StringBuffer.append(String) to append a single-character string instead of just using StringBuffer.append(char). Sure, it's a good idea, but there's another kinda-orthogonal piece of advice that will likely improve runtime performance a good bit more:

The vast majority of the code that uses StringBuffer could save a bunch of time by using the new-ish(JDK 1.5) StringBuilder class [] , which has the same API but is not internally synchronized. This translates to a runtime savings of approximately a KAJILLION percent by avoiding the horrendous synchronization overhead hit when the StringB*ef in question is only being used by one thread. It's very similar to using an old-skool Vector when an ArrayList will do just as well and not slow down your code.

Like I say every thime this kind of thing comes up, Java isn't slow (any more), but we're certainly not helping matters with this kind of sloppy coding.

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. That way, when a million-dollar bank wire doesn't go through, you can prove that it's not your head that should be on the chopping block. It's actually kind of refreshing knowing that any code you touch is pre-vetted so you don't have to worry about trusting it enough to build on it.

Re:static_analysis++ (5, Insightful)

Coryoth (254751) | more than 8 years ago | (#15264844)

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.


Re:static_analysis++ (1)

Jonboy X (319895) | more than 8 years ago | (#15264984)

Let me guess: you've never worked in industry, have you?

By "prove", I mean to present evidence to someone that will cause them to believe whatever it is that you're proving. This of course depends both on what you're proving and whom you're trying to convince. The unit test may not convince you that my code is "correct", but it will convince my boss not to fire me.

It's not all about satisfying your theorems, buddy...

Re:static_analysis++ (3, Insightful)

Coryoth (254751) | more than 8 years ago | (#15265027)

I've worked in industry as a mathematician. When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration. Given that a piece of software is, at its heart, just a lot of mathematics, and the fact that it really is possible to prove things about code in the real sense of the word, I would be very careful about saying you "prove" your software works.


Re:static_analysis++ (1)

tcopeland (32225) | more than 8 years ago | (#15265053)

> using the new-ish(JDK 1.5) StringBuilder class

Sounds like a good rule for the migrating [] ruleset!

Re:static_analysis++ (5, Informative)

Stellian (673475) | more than 8 years ago | (#15264591)

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++ (1)

mattwarden (699984) | more than 8 years ago | (#15264901)

None of this tools is a mach for a manual audit performed by a professional.

At $1/line, not everyone can do this.

Re:static_analysis++ (1)

nogginthenog (582552) | more than 8 years ago | (#15264680)

Copy/paste detector? I don't like the sound of that. I could be out of a job :)

Re:static_analysis++ (1)

Coryoth (254751) | more than 8 years ago | (#15264742)

If you want a truly powerful Java static analysis tool consider ESC/Java2 [] which includes not just the usual extra static checking you would expect, but also includes a theorem prover which can provide warnings for all kinds of deep and subtle errors. Read through this presentation (warning PDF) [] to get an idea of exactly how many things ESC/Java2 can catch, including warnings about race conditions and deadlocks. If you want powerful statsic analysis of Java code ESC/Java2 is definitely the way to go.


Re:static_analysis++ (0)

Anonymous Coward | more than 8 years ago | (#15264868)

You fucking scum. Stop advertising your book in every post you make.

Re:static_analysis++ (1)

blandarfleck (964615) | more than 8 years ago | (#15264869)

PMD's an amazing tool - In v3.6 there's the ability to scan JSP's, I've written an entire suite around secure coding guidelines using both the Java and JSP engines.

Re:static_analysis++ (1)

Herkum01 (592704) | more than 8 years ago | (#15264998)

A dirty little secret for Perl has been Test::Devel. As you write your tests in Perl collects stats on what has been called in your tests, and has what not. An excellent book for learning about Perl testing can be found here Perl Perl Testing: A Developer's Notebook []

Plug (1)

locu (935130) | more than 8 years ago | (#15264334)

Time to buy Coverity stock? =)

I hold any bet (5, Insightful)

Opportunist (166417) | more than 8 years ago | (#15264352)

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!"

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.

Re:I hold any bet (3, Interesting)

NineNine (235196) | more than 8 years ago | (#15264513)

You're right... The problem is that software consumers already have a mindset that makes broken programs OK, and the way to fix them is by buying the new version. One of the worst offenders that I've seen in Intuit. Intuit is famous for releasing new programs every single year, regardless of whether or not anything has actually changed. They're also notorious for simply not fixing old code after the new version is released, with the official response of "Your problem is fixed in the new version. Buy that one." This is grossly fraudulent, in my opinion.

The problem is that we all, as consumers, already accept this kind of shit as acceptable. I wish I knew a way to reverse this, but realistically, I don't see this mindset changing any time soon.

Re:I hold any bet (2, Insightful)

Gnavpot (708731) | more than 8 years ago | (#15264550)

After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.
Is it a fact that early testing will delay a project?

I must admit that I don't know much about large software development projects. But I do know a lot about large development projects in my own profession. It seems that any problem which was unresolved/ignored/insignificant during early development will turn into huge problems a few days before a deadline.

Are software projects different? I would think that early warnings about bad coding practices at least would make a programmer change his coding habits so he doesn't make the same error again and again and finally has to correct it in 200 different parts of the code after the final quality check.

Re:I hold any bet (1)

bladesjester (774793) | more than 8 years ago | (#15264658)

Unfortunately a lot of (bad) managers don't judge on quality. They judge on lines of code or features that someone produces. The mentality is "get it out the door and worry about the nitpicking later" (and later never comes).

While you will never fix every single bug and not all bugs make sense to fix, this practice leaves a lot of bugs that should be fixed.

Slow and steady... (1)

rumblin'rabbit (711865) | more than 8 years ago | (#15264766)

You are absolutely correct. In general, the more patient and methodical you are, the faster the project gets done. It definitely saves money over the life time of the project. This is particularly true for large projects.

It's when you rush and abandon good practises that the project is in danger of becoming seriously late.

It's something everyone knows, and everyone occasionally forgets.

Re:I hold any bet (1)

Opportunist (166417) | more than 8 years ago | (#15264847)

If the alternative is early testing or no testing, then yes, early testing delays a project.

Re:I hold any bet (0)

Anonymous Coward | more than 8 years ago | (#15264592)

"I will bow down to him"

You won't have to. If your software company did all that, it'd be bankrupt before you'd have time to.

Re:I hold any bet (1)

Fordiman (689627) | more than 8 years ago | (#15264688)

Hold on... you BUY software? Do you work as IT for a company or something?

Seriously, I haven't bought a piece of software in years... Not that I have any commercail software, or anything. I'm all OSS at home, and at work, there is no non OSS user (read: me) installed software either.

Meanwhile, I just bought a sweet used small-form 933MHz Dell to replace my old 500MHz Dell. Not much of a step up, but lets face it: I don't use this thing for gaming.

Re:I hold any bet (1)

YOUR SIG SUCKS! (712500) | more than 8 years ago | (#15264731)

I play NES games on my GBA. Ask me how.


Why you ask? Because it PROVES YOU ARE A LIAR. You game, you buy commercial software. Your sig directly contradicts your post and there for it sucks and YOU ARE AN ASSHOLE.


Re:I hold any bet (1, Troll)

Fordiman (689627) | more than 8 years ago | (#15264852)

Acutally, I haven't bought any in years.

Playing NES games on my GBA requires no recently purchased software. I have an old NES with games I bought in the late 80's/early 90's. I download the corresponding ROMs to those games, place them in PogoShell (an OSS project) and upload them to my GBA's X-ROM cart (a commercial product, but hardware) using a non-open freeware driver for it.

Now, what were you saying, Troll?

Catch 22? (3, Insightful)

Tourney3p0 (772619) | more than 8 years ago | (#15264354)

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

Alright, so writing better code means you might miss a deadline. But not writing better code means.. things are exactly as they've always been, or the software development cycle will be revamped appropriately?

Not much of a catch 22.

Or, ... (3, Funny)

UbuntuDupe (970646) | more than 8 years ago | (#15264542)

to paraphrase Oscar Wilde: Anyone who doesn't have enough time to do it right, has enough time to do it again.

Re:Catch 22? (1)

supra (888583) | more than 8 years ago | (#15264555)

The catch 22 is quite the opposite from what the article proposes.
Being careful almost always means improved schedules, not the opposite. It's better to spend 10 min reviewing code before committing it each day than have a lump of crap after 12 months which can't float for more than 5 min w/out a problem.
Debugging problems takes orders of magnitude longer than small incremental reviews. Some things that attribute to this are awareness (the code is fresh in your mind after being written; it's half forgotten when problems surface), scope (the problem will likely surface after the system grows making it harder--and thus consuming more time--to find the problem), and complexity (even after the problem is found, a solution is easier to apply when the code is fresh because the interfaces are new; if a bug entails an interface change or worse--a design change--then the time will really grow).
The catch 22 is really an old-school mentality forced into this generation.

Re:Catch 22? (2, Insightful)

Kapsar (585863) | more than 8 years ago | (#15264952)

A Catch 22 is a "damned if you do, damned if you don't" circumstance. In this case if you miss your deadline because you created a better product, or you make your deadline but end up with crap and then miss it later. catch 22 is not an old school mentality, it's a realistic way of looking at situations, read the book you'll understand then.

Re:Catch 22? (1)

IpalindromeI (515070) | more than 8 years ago | (#15265141)

A Catch 22 is a "damned if you do, damned if you don't" circumstance.

No, it isn't. []

Re:Catch 22? (1)

Fordiman (689627) | more than 8 years ago | (#15264727)

A good revamping would be for management to learn what the word 'rediculous' means in the context of the word 'deadline'.

Re:Catch 22? (0)

Anonymous Coward | more than 8 years ago | (#15264910)

learn what the word 'rediculous' means

Apparently it doesn't mean anything. []

Re:Catch 22? (1)

CCFreak2K (930973) | more than 8 years ago | (#15264894)

The problem is, if you miss a deadline, whatever was submitted prior to the deadline -becomes- the product. Such tight schedules don't allow for things like quality control.

Think about, for example, Windows Server 2003. In the days prior to the betas (I think), there was what was called a War Room. Every day, the heads of each design part of Windows Server 2003 met in the War Room to discuss the current status of each part. If a department had a bug and their team leader didn't show up, their [potential] fixes to the next build of Windows NT wouldn't make it into the build process.

Security First.... (1)

HumanisticJones (972339) | more than 8 years ago | (#15264368)

...might just make the software more appealing to customers. Recouping the lost market time with a slightly more solid base, combined with less strain on call centers when bugs do fly up. Catch 22 be damned, I'd rather have working, secure software a month later than a buggy, glaring security risk today.

QA is..... (3, Funny)

Wisp (1763) | more than 8 years ago | (#15264376)

The new Black!

Re:QA is..... (0)

Anonymous Coward | more than 8 years ago | (#15264438)

What does hiring quotas have to do with Quality Assurance?

I do this personally. (3, Insightful)

cableshaft (708700) | more than 8 years ago | (#15264400)

I usually do some quick general design and planning beforehand, then go in and write the software one element at a time, testing to make certain it works properly before moving on to the next. The benefits seem to far outweight doing it the other way, for me, as it reveals problems I wouldn't have noticed in the planning stages in the design or implementation early, and it also helps isolate where any bugs would be located at, so I'm not checking all over the place.

I'm not sure if it really saves me any time in the long run, but I'm much more comfortable coding this way, which is probably more important.

Also, so far, I've been the only coder for my projects at work and my games at home, so it *might* not be quite as effective for large teams, although what I've read on XP seems to suggest that it can still be very effective.

Re:I do this personally. (1)

matt328 (916281) | more than 8 years ago | (#15265001)

This is definitely the way to go. I do this myself, lay out a project a single component at a time, and test all along. Sometimes I only change or add a couple lines of code at a time before I compile and test it. Seems like this would take a long time to code anything, but I cut out all the rigorous testing (and possible debugging, and even worse, rewriting entire modules)

Re:I do this personally. (1)

bigpat (158134) | more than 8 years ago | (#15265157)

I usually do some quick general design and planning beforehand

Exactly. I really don't think taking more time to "code" is the answer. The majority of security problems in software come about because of design issues. The focus should be on security as a functional requirement. Sure buffer overflows and such can result from poor coding techniques, but I have found it is just a general lack of functional definition which dooms a project to a lot of revision later in the process.

Catch-22 (5, Informative)

kentyman (568826) | more than 8 years ago | (#15264404)

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.

Re:Catch-22 (1)

Amouth (879122) | more than 8 years ago | (#15264863)

yea the catch 22 is if they write better code then they don't have a job to write the patchs

Slippery slope (3, Funny)

metamatic (202216) | more than 8 years ago | (#15264408)

Jeez, next thing programmers will be expected to document their code.

What will the XP weenies do then?

Ain't gonna last (5, Funny)

FiveDollarYoBet (956765) | more than 8 years ago | (#15264412)

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

Well I learned that at Uni (4, Interesting)

Yrd (253300) | more than 8 years ago | (#15264425)

Correct-by-construction programming is a fundamental part of a proper education in software engineering, I would have thought.

Where did these people learn to code?

Re:Well I learned that at Uni (4, Interesting)

truthsearch (249536) | more than 8 years ago | (#15264491)

In the real world... where the client says, "I don't care about security, just get it done!" Of course they start to care after a break-in, so they have things fixed in hind-sight.

Re:Well I learned that at Uni (1)

ximenes (10) | more than 8 years ago | (#15264628)

Probably by themselves, since teaching actual programming is beneath most university curriculums.

What you learned is bullshit (0)

Anonymous Coward | more than 8 years ago | (#15264940)

There is no such thing as software engineering. Software is still in the craftsmanship stages. Come back 100 years from now and maybe it will be approaching the rigor of engineering, as a discipline.

"Big design up front" does not work for software projects. ALL PHASES of software development are *design*. You have to do continuous evolution of the design and the code in tandem. As the C2 wiki would say: Practice ContinuousIntegration. Do ShortIterations to MeasureVelocity (i.e. to get constant feedback about your progress). RefactorMercilessly. CodeUnitTestsFirst. And most important of all: write something OnceAndOnlyOnce, and DoTheSimplestThingThatCouldPossiblyWork. Because YouArentGonnaNeedIt.

That's why... (5, Funny)

GillBates0 (664202) | more than 8 years ago | (#15264430)

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.

Re:That's why... (1)

MasterC (70492) | more than 8 years ago | (#15264650)

...but nothing beats using the best quality, industrial-strength (tm) bits to start with...

For those not in the industry sector but in information technology sector, are those the same as the Best Information Technology Strength (BITS) bits? I've used BITS bits before and they were solid and performed quite well.

The Big Unsigned Superior Technology bits are the best choice for the adult entertainment sector. They're so successful that I hear its those bits that dominate the internet and slashdotters' hard drives, mobile phones, CD-R stacks, and push the capacity of their Tivo/MythTV. I wish I had the patent on those bits!

Re:That's why... (1)

Sponge Bath (413667) | more than 8 years ago | (#15264842)

...use the highest quality bits

I bought a box of 'Great Quality' bits from Fry's.
It only contained zeros, but they price was great!

All this is such old news (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15264432)

I don't know if I should call this article a dupe, but in case you are interested RIM holes [] have been discussed to death over here.

warning: not work safe link (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15264707)

you fuck

Duh! (1)

cashman73 (855518) | more than 8 years ago | (#15264444)

Has Ric Romero seen this report yet?

This Just In From Microsoft (4, Funny)

Metabolife (961249) | more than 8 years ago | (#15264455)

After taking this training routine, Microsoft says that Vista will be delayed another 2 years.

Re:This Just In From Microsoft (1)

cazbar (582875) | more than 8 years ago | (#15265118)

If they did this, Vista might actually be worth the money.

gets() and people (3, Insightful)

mkiwi (585287) | more than 8 years ago | (#15264466)

Sometimes it amazes me what people do with the C programming language, for good or for bad. Take some pro programmers who I caught using gets() instead of fgets(). I'm not a rocket scientist, but I'd say anything that uses gets() is a serious problem, since that function does no bounds checking and is prone to attacks.

How do people learn to code like this? Is it just early habits that do not go away?

Re:gets() and people (0)

Anonymous Coward | more than 8 years ago | (#15264583)

Wow. I've never seen anybody use gets().

It's good that most systems' documentation for gets() explicitly warns not to use it, so it's a pretty hard mistake for someone learning programming today to make. The OpenBSD linker also warns people not to use it at link time.

But come to think of it: why is gets still present at all in libc? It should be removed, or made into macro for abort(), or print some severe warning (and rightfully so, scolding) on stderr that says if the programmer values his life and all that is holy, he'd better change his code.

At least functions like strcpy(), though unsafe in most usage, can actually be legitimate in some cases where the buffer size is gauranteed to be enough. gets(), on the other hand, has no legitimate purpose: you should never by any means trust that a file descriptor will have data of a given size.

Re:gets() and people (1)

Richard Steiner (1585) | more than 8 years ago | (#15265107)

I've always wondered why such harmful code is allowed to survive. We certainly don't allow it in our own local utility libraries.

Rewrite the standard gets() function, and have the compiler force programs which utlize the old one to handle the new one (either by making the change transparent to existing code or by forcing the programmer to address the problem by making some minor changes).

Problematic standard library functions are traps just waiting to happen.

UNIX is too "steeped in tradition" for its own good sometimes...

OT: not a Catch 22 (4, Insightful)

cain (14472) | more than 8 years ago | (#15264468)

The example in the write up is not a catch 22 [] . A catch 22 requires two things be done, each one before the other, thus neither can be done.

Re:OT: not a Catch 22 (1)

Peyna (14792) | more than 8 years ago | (#15264947)

Have you read the book "Catch-22"?

"There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he was sane he had to fly them. If he flew them he was crazy and didn't have to; but if he didn't want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.

'That's some catch, that Catch-22,' he observed.
'It's the best there is, Doc Daneeka agreed."

So actually, based on the origin of the phrase "catch-22", the article seems to be more right that the version you ripped off the top of the Wikipedia page. "Damned if you, damned if you don't," is much closer to the original and (while Wikipedia disagrees) more familiar version of catch-22.

So, with the article we have here, what they're saying is they have two choices: 1. Delay the release and everyone hates you for endless delay; or 2. Release the product on time and everyone hates you for releasing buggy code. Of course, to have perfect code, you have to delay indefinitely, so the product would never get released.

Re:OT: not a Catch 22 (2, Insightful)

LargeWu (766266) | more than 8 years ago | (#15265177)

No, I think you have failed to comprehend the example from the book. Go back and read it again. A catch-22 is a circular set of conditions that can only be fulfilled if the other is true. The second condition in your example falsely assumes that code which is released on schedule cannot also be bug free. Furthermore, "Damned if you do, damned if you don't" is a lose-lose situation, not a catch-22. This phrase assumes that "do" and "don't" are not dependent on each other. Of course, if you have to "do" in order to "not do", and have to "not do" in order to "do", then you've got a catch-22.

A lot of presumption on their part... (1)

Bomarc (306716) | more than 8 years ago | (#15264479)

This would presume that developers know how to TEST software. LARGE presumption on their part... It would be better to have competent TESTERS actually- test the code.

Re:A lot of presumption on their part... (1)

Richard Steiner (1585) | more than 8 years ago | (#15265147)

Software development is an iterative process that involves unit, subsystem, and system testing, optimally by BOTH the programmer(s) and by at least one dedicated third party.

We always had business analysts test our stuff. They knew how it was supposed to work, but more importantly: they usually didn't understand the technical underpinnings, so they didn't know what they *weren't* supposed to test. That sometimes produced interesting results. :-)

Go ahead, feed the script kiddie community (1)

Goblez (928516) | more than 8 years ago | (#15264495)

Taking the time during development to test and debug your code. I'm sorry, but this isn't something new, nor somethign to be ignored. People mistakenly think that you throw your code together, and if it works you're done. This is wrong. Any production system code should be tested before being put in. Maybe testing and debugging should be considered overhead in an industry that doesn't have much thereof (consider manufacturing of hardware).

Otherwise we are just fueling the fire of exploitation and bad-user experiences.


Thinly veiled ad? (5, Insightful)

Mr Z (6791) | more than 8 years ago | (#15264515)

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

Re:Thinly veiled ad? (3, Interesting)

cant_get_a_good_nick (172131) | more than 8 years ago | (#15264548)

Seems they've been astroturfing for a while. wasn't that long ago they did a big writeup on flaws Coverity found in certain FLOSS projects. at least then they found some bugs and helped fix.

I'm all for tools like this. YOu can find a billion text editors on but very few good programmers tools. Just this smells like an add for me.

Re:Thinly veiled ad? (1)

biscon (942763) | more than 8 years ago | (#15265061)

Better sheep, sap, root or offtank it then ;)

Good at publicising themselves (5, Informative)

derek_farn (689539) | more than 8 years ago | (#15264535)

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:Good at publicising themselves (1, Informative)

Anonymous Coward | more than 8 years ago | (#15264856)

I approached Coverity recently regarding their tool. It is astoundingly expensive. And that is understating it. $49,000 for a license to work on 500,000 lines of code. For one year. Thats right, after one year that $49,000 piece of software no longer functions. Ouch. If I remember correctly support is extra.

That is the pricing for the entry-level product "Prevent". The other product "Extend" is more expensive.

They do offer discounts for larger amounts of code.

We didn't purchase.

Re:Good at publicising themselves (1)

blitz487 (606553) | more than 8 years ago | (#15265068)

I went to Coverity's web site. There isn't much useful information there about what it does, but there is lots of vague hype and attempts to get you to register. But what turned me off was their website hijacked the 'back' button so you couldn't leave their site.

Why do companies think that is a good idea?

Slashdot Advertisers for Coverity Again (0)

Anonymous Coward | more than 8 years ago | (#15264544)

Automated static analysis spurs second wave of XP hysteria. Formal methods found dead from apparent suicide in home.

Deadlines are set wrong (4, Insightful)

192939495969798999 (58312) | more than 8 years ago | (#15264586)

If being careful makes you miss the deadline, then the deadline is set wrong. Shipping a product with security holes that you knew about + could've fixed with a bit more time is how we got into the position we're in. Pushing back a release date to fix them first should be the rule, not the exception.

Re:Deadlines are set wrong (0)

Anonymous Coward | more than 8 years ago | (#15264722)

You've obviously no plans to upgrade to Vista then

Still developing secure code is not easy (1)

Billly Gates (198444) | more than 8 years ago | (#15264590)

Especially if you don't know assembler.

The problem I see is that hackers today use buffer and stack overflows. The compiler creates the insecure code more than the program.

I wonder how secure managed code in .Net is? I know MS boasts that not a single security hole has been spotted so far but I do not know of any apps that use it? I know Java is secure for that reason but less usefull on the desktop.

Unit testing is your friend (1)

Billosaur (927319) | more than 8 years ago | (#15264604)

Assuming you have a good idea of what input to your program is supposed to be, and you have an adequate method of checking to make sure the data is not some sort of goo (love those regexs!), then you should be able to test the software as you go. I'm of the school that tends to build each part, test it, and move on. It cuts down on the holes if I know where a piece of data comes from, where it's going, and what manipulations may happen to it along the way.

Really insulting title (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15264641)

We know how to code securely, at least in the same way that every profession has its skill levels on a bell curve.

What the industry needs, as has been pointed out here, is companies that are
A) willing to give developers the time to design software correctly,
B) willing to give testers the time to test software thoroughly, and
C) willing to delay software that the testers find holes in.

Obligatory Fight Club (3, Funny)

Weaselmancer (533834) | more than 8 years ago | (#15264671)

Narrator: A new program written by my company is shipped on time, but with bugs. The network stack locks up. The OS crashes and burns and scrambles the hard drive. Now, should we initiate a code review? Take the number of licenses in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a code review, we don't do one.
Business woman on plane: Are there a lot of these kinds of bugs?
Narrator: You wouldn't believe.
Business woman on plane: Which software company do you work for?
Narrator: A major one.

Nothing to see here, move along (1)

955301 (209856) | more than 8 years ago | (#15264693)

Now advertisements for COTS products are news articles?

While I appreciate the articles on NASA releasing code analysis tools - or pointers to freshmeat - embelishing about something I can't immediately use is boring. Procurement happens at a snails pace for purchased software - gimme something I can throw on the stage and start training dev's to use.

Or at least something in depth that shows statistics on *how much* the schedule slips by when taking this security first approach - that would be news:
"WSJ reports security-first approach to software costs 18% increase in time to deliver"


Security is a Voyage Not a Destination (2, Insightful)

Greyfox (87712) | more than 8 years ago | (#15264719)

I see static analysis and code auditing as an excellent step on the road of security, but at a completely different level you have to also make sure that the processes you're coding are also secure. All the secure programming techniques in the world will not help you if your design itself has flawed assumptions. So not only should you program for security but you should also design for security.

Laws? (2, Insightful)

VGR (467274) | more than 8 years ago | (#15264721)

From the article:
Many companies rushed to beat rivals with new software, and checking for bugs that could later be exploited by hackers was often seen as a waste of time. That has begun to change in the past few years as new laws force the disclosure of security holes and breaches...
What laws are these? This is the first I've heard of such a thing. And why do I have a feeling these laws have a clause that directly or indirectly exempts certain large software companies?

Re:Laws? (0)

Anonymous Coward | more than 8 years ago | (#15264888)

It is called Sarbanes-Oxley or SOX. It is part of a concept called management risk mitigation.

Bullshit (1)

suv4x4 (956391) | more than 8 years ago | (#15264783)

I've some inside info and let me tell you how it works: write the best code, check for holes, make sure there are no bugs and so on and so on, but if you miss the deadline you're definitely fired.

And since the deadline is always unrealistic, all checks get down in priority as you try to keep your job hammeric code that barely works with the speed of light.

catch 22 ... sure... (0)

Anonymous Coward | more than 8 years ago | (#15264792)

If "many companies" are teaching their programmers to write secure code then "many companies" should recalculate the deadlines and include code-checking in their timepath, instead of complaining about missed deadlines....

i mean either include code-checking and allocate time for it or don't check it and finish earlier... can't have it both ways...

Open Source alternatives (1)

coreboarder (412771) | more than 8 years ago | (#15264880)

Probably fanning the flames here I'm wondering is there a free (as in beer [] ) alternative to these products?

Code reviews aren't new! (1)

the packrat (721656) | more than 8 years ago | (#15264928)

Code reviews by cow-orkers are nothing new. Ed Yourden and many others were publishing books in the late 80s and early 90s showing that it was a really good way to get code that was nicer and had fewer defects. To say nothing of Brooks's programming unit teams from over 25 years ago.

It's nice that someone is waving the security flag to promote it, but a little sad that everyone wasn't already doing it.

Deadlines (1)

tcolvinMI (922327) | more than 8 years ago | (#15264937)

Ahh, deadlines, where would we be without them. Personally, I think that deadlines are the catch 22 of software development. With a strict deadline, you sacrifice quality. However, with a loose deadline, you sacrifice a product to your customer, which then sacrifices money coming into the company, which sacrifices your paycheck and even your job. Deadlines definitely have their place in the world, but I also believe that they should be loose enough to give you time to get a secure, thoroughly tested, and correct version of software out to the customer. Either that or a signed paper that says you're not responsible for anything you code because you were told to get the product out on time. However, that thought is incredibly naive at best.

Re:Deadlines (0)

Anonymous Coward | more than 8 years ago | (#15265104)

Why is that naive, look at microsoft for example... do they accept responsibility for dataloss (for example) when they have buggy code? i don't think so...

Missed deadlines = poor project management (1)

tgrigsby (164308) | more than 8 years ago | (#15265029)

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

As with everything in a project, adherence to security guidelines must be figured into the time estimates for a project. Time estimates must in turn be based on department-reviewed technical specs. Tech specs are based on design and development reviewed functional specs. Functional specs are based on user and business requirements. If the project manager pushes for concrete time estimates using comprehensive one-to-one project description methodology, deadlines will still get missed, but it won't be because of a single requirement like security. Sometimes this means the project manager has to push back on the developers to say something like, "Are you sure it's only going to take you 80 hours to implement centralized licensing?" But that's what the project manager is supposed to do.

Business sometimes requires that releases occur on a schedule. Ok, fine, but that means scaling back the features included, not the quality of the product, and in today's market, security is one of the variables in determining quality.

Also (1)

ezeecheez (931550) | more than 8 years ago | (#15265036)

More savvy programmers have started referring to crashes as 'security-necessitated shutdowns'.

Miss the deadline? (0)

Anonymous Coward | more than 8 years ago | (#15265045)

This task should be included in the schedule. If the deadline is missed because of this task then it is due to bad estimation, just like all the other tasks.

The five laws of software process. (0)

Anonymous Coward | more than 8 years ago | (#15265079) []

The Laws of Software Process
There are are some immutable laws that apply to software process, and govern our (software) lives. This issue identifies these laws, gives some examples, and explains the consequences. Here they are:

The First Law of Software Process
Process only allows us to do things we already know how to do.

    The Corollary to the First Law of Software Process
You can't have a process for something you don't know how to do

    The Lemma of Eternal Lateness
The only processes we can use on the current project were defined on previous projects. Which were different from this one.

The Second Law of Software Process (See also "The Rule of Bifurcation")
We can only define software processes at two levels: too vague and too confining

    The Rule of Bifurcation
Software process rules should be stated in terms of two levels: a general statement of the rule, and a specific detailed example (eg. The Second Law of Software Process).

    Armour's Observation on Software Process
What all software developers really want is a rigorous, ironclad, hide-bound, concrete, universal, absolute, total, definitive, and complete set of process rules that they can break.

      The Third Law of Software Process (also known as the Footwear Manufacturer's Minor Dependent's Law)
The very last kind of knowledge to be considered as a candidate for implementation into an executable software system will be the knowledge of how to implement knowledge into an executable software system.

    The Twin Goals of Optimal Termination
1. The only natural goal of a software process group should be to put itself out of business as soon as possible.
2. The end result of the continuous application of effective process will be that nobody actually has to use it.
The Five Orders of Ignorance
Did you know

Software is not a product, it's a medium (see Software is not a Product) for storing knowledge. Therefore, software development is not a product producing activity, it is a knowledge acquiring activity. Knowledge is just the other side of the coin of ignorance, therefore software development is an ignorance-reduction activity.

So what kinds of ignorance do we have? It turns out there are five levels or "Orders of Ignorance". They are (starting from zero, 'cos we are computer folk, and we always count from zero):

        0th Order Ignorance (0OI)--Lack of Ignorance
I have Zeroth Order Ignorance (0OI) when I know something... ...and can demonstrate my lack of ignorance in some tangible form, such as by building a system that satisfies the user.

        1st Order Ignorance (1OI)--Lack of Knowledge
I have First Order Ignorance (1OI) when I don't know something... ...and I can readily identify that fact.

        2nd Order Ignorance (2OI)--Lack of Awareness
I have Second Order Ignorance (2OI) when I don't know that I don't know something. ...That is to say, no only am I ignorant of something (I have 1OI), I am unaware of that fact

        3rd Order Ignorance (3OI)--Lack of Process
I have Third Order Ignorance (3OI) when I don't know of a suitably efficient way to find out that I don't know that I don't know something.... ...So I am unable to resolve my 2OI

        4th Order Ignorance (4OI)--Meta Ignorance
I have Fourth Order Ignorance (4OI) when I don't know about the Five Orders of Ignorance... ...which you no longer have, dear reader.

These Five Orders of Ignorance play an tremendously important role in systems development: our job is the reduction of 2OI. All systems processes and methodologies are 3OI processes. 2OI and 3OI explain most of our problems in systems development. Our management systems are set up to deal only with 0OI and 1OI, and are wholly inadequate for the modern world (mostly because of 4OI).
Software is not a Product
The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product.

If we consider where--what medium, that is--we can store knowledge, we see there are only a few places. For this purpose, and to avoid getting into debates about what knowledge is, let's consider "knowledge" as being the necessary "instructions" (steps, data, events, situations, etc..) necessary to achieve something of value to an organism. There are only five places in which such knowledge can be stored, and software is simply the most recent. They are:

        DNA Instinctual knowledge is DNA-stored knowledge. Much of the way our body functions is courtesy of DNA-stored knowledge

        Brain The human race stores most of its functional and intentional knowledge in this medium

        Hardware Although we don't usually consider hardware to be a knowledge store, that's what it is. A ruler stores knowledge of length, a wrench store knowledge of nuts and bolts. Hardware has the added advantage of allowing us to apply the knowledge

        Books Books (and even most web pages) store knowledge in a relatively accessible and persistent form. However, the knowledge representation is entirely passive. Knowledge in books doesn't do anything

        Software Knowledge stored in software is active. Not only can the knowledge be described in software, it can be executed

The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).


        Software is not a product, it is a medium for storing knowledge.

        Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"--we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.

The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.

        Businesses that learn to manage the real product will become unbelievably efficient and productive. Businesses that don't will become marginalized. Productively improvements of 1000% are possible and should become routine in those companies that figure out this issue and learn to effectively manage the empirical knowledge of their domains.

I don't buy the idea of missed deadlines (2, Insightful)

Allnighterking (74212) | more than 8 years ago | (#15265134)

The problem is one of doing things in software the way Automobile companies did in the 60's and Japan stopped doing in the 70's. Traditionally in software development you design... then send to engineering to build then send to QA for an endless cycle of test bitch fix bitch retest bitch fix bitch test bitch deadline ooops market. QA should be involved the moment some fool says "I have an idea" and stay in the loop all the way. Testing in increments as things are built. I've done more in a white paper on my site as for writing this all up but this is the jist. Integration of Quality control from the start means less problems. The idea of. I'll fix it later sucks because it never gets to be later.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>