Slashdot Mirror
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.'"
Writers are encouraged to proofread.
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...
The Army reading list
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
The new Black!
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.
Creator of the popular web game Proximity
You know where you are? You're in the $PATH, baby. You're gonna get executed!
Jeez, next thing programmers will be expected to document their code.
What will the XP weenies do then?
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
It sounds good and all but there's a direct correlation between the deadline and how bullet proof the code is.
insert sig here
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?
Miri it is whil Linux ilast...
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.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
After taking this training routine, Microsoft says that Vista will be delayed another 2 years.
How do people learn to code like this? Is it just early habits that do not go away?
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.
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.).
Program Intellivision!
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.
to paraphrase Oscar Wilde: Anyone who doesn't have enough time to do it right, has enough time to do it again.
Apology to Ubuntu forum.
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.
stuff |
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.
Weaselmancer
rediculous.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The Internet is full. Go away.
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.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
Everybody makes mistakes. That is how we learn and progress to a more experienced state of being.
By telling people not to make mistakes is letting them know that they cannot try out new and inventive, sometimes even shorter ways of doing things.
Unit testing is fine and should be encouraged, but really the thing you want to do here is make your build process do all the donkey work as much as possible, and let your programmers worry about the programming issues and doing things smarter and achieve the most with the least possible effort.
The build process can do the following, if you do it right:
-> Build the code to executable format and even CD ISO distributables (duh)
-> Do code indenting and formatting etc. to conform to a standard.
-> Do unit testing on code segments, and even tell you what % parts were not tested.
-> Scan the code for bad practices such as strcpy and unmatched mallocs.
-> Gather all your TODO's and your FIXME's into an output file.
-> Run the program live and do input fuzzing testing, with extended debugging logs.
-> Run nessus and other attack scripting languages to take care of the obvious issues.
With all these measures in place, it is a simple matter of having *somebody* go through the build logs and make a priority / TODO list, fixing security first and stability later, and the small imperfections last.
But alas. Nobody looks at the logs. Logs are boring. Thats why you have to keep them visible. Maybe via RSS, IM or email?
But to stay with the topic, analysis tools are just that: tools. They are not a cure to chronic software problems. Developers are not excused from the responsibility of at least attempting to write quality code.
Some current project development methods really contribute to buggy and insecure code. Example: XP. I really think that some aspects of XP programming are a bad idea. Namely, the "code as fast as you can" aspect of it is fraught with errors. A more thoughtful, disciplined approach might seem like it is terribly slow. Yet being inherently less buggy, it can reach the target faster than the sloppier, more haphazard approach. This is much like the Tortoise and the Hare. Or maybe a better analogy would be like a rally driver who is more careful with his fuel and tires.
Don't get me wrong. Some parts of XP are fine. The Buddy System is an excellent way to get things done quickly by short-circuiting the collaboration cycle.
It is very nice that this bozo has a (very expensive I read) little program that tries to detect problems when they have already happened. So along comes mr friendly one day (or more?) after the fact to dicipline the programmer? That does not sound like a very positive approach to me.
If you want to learn someby something (I hope mr belittle does) it works much better if you have a quick feedback loop, react immediately when something is going wrong, not one weekend later when the programmer has all but forgotten why he did it that way. I agree you cannot use a mr little for such feedback, but unittests and other tests that have to run before the developer can turn in his work can be run automagically. Test are not partial, do not have favorites, and are easy to understand by a programmer. Mr little is probably the opposite. You will either need a pairprogramming or review process to prevent programmers from just disabling the test that fail, but with such a process you will have good software and happy programmers. Mr Little does not make programmers happy.
Have a look at aegis, a Configuration management system that can enforce such a process and do a lot of other commonsense things. The 'problem' with aegis is that it does not have a pretty pictures interface, so it's advantages are hard to explain to pointy haired bosses.
This space is intentionally staring blankly at you
Good. Fast. Cheap. Pick any two. You can define the scope, the deadline, or the budget. Pick one. Not two. Not three. One.
You should really read Unit Testing in Java: How the Tests Drive the Code. XP is about small, direct steps, and when these are done with tests first, they greatly improve the quality of the code. You can draw all the big, fancy, pie-in-the-sky diagrams you want, and still get sloppy code.
Lies about crimes