DARPA slaps $2m on the bar for the ULTIMATE security bug SLAYER

Re: Ambitious, much?

Agreed. The problem isn't a lack of tools and methodologies - while there's plenty of room for improvement in both areas, the vast majority of software developers aren't making significant use of either. The problem is practice, and the lack of incentives to improve it. For most developers security vulnerabilities, and poor code quality in general, are externalities: they don't get penalized for them, and they don't get rewarded for preventing them.

That's not to say that we couldn't stand some tweaks in the available tools to make them easier to use. I've been on the splint mailing list for several years, and new adopters keep running into the same problems. If it were part of the typical toolchain for C developers, a lot of those would have been ironed out by now.

Re: hmm

"The US government can make offers you can't refuse. Being able to print your own money has its advantages."

Actually, the US government does not print the money anymore. The central banks circle jerk it into existence by lending non-existent money to each other and calling it money creation.

Re: hmm

This links explains why software can never be truly fully tested which is the same for testing software or people.

http://badsoftware.com/imposs.htm

Re: hmm

You can prove pretty trivially that verifying all code paths for a given program and arbitrary input, in general, is isomorphic to the Halting Problem.

Note, though, that the HP properly only applies to machines with infinite storage, and no physically-realizable computer has infinite storage. Any possible real computer can be reduced to a deterministic finite state machine, and modeled completely by another computer with exponentially more (but still finite) storage. For real computers, what the HP really says is general program analysis is asymptotically infeasible, because eventually the only way you'll be able to analyze some inputs would require more storage than you have physical reasons for. (Basically, the HP says "if you treat your input as a TM, some inputs will not be computable"; the alternative is treating your input as the less-powerful machine it really is, and then some inputs will be too large.)

Re: Statement of intention

Um, no, that's not it at all.

Once upon a time, like about 18 years ago, I was hired to do "software maintenance" on a product. Well, what I received was a .zip file 20Mb in size, and that was it. The product was a gateway router, running in the background on MS-DOS. 2/3 of the code was C, and 1/3 was assembly. The compiler vendor was out of business, the software had been hacked on for a decade, there were over 100 unique compilation flags (#ifdef, for memory models, code that wasn't used, and on and on), a terrible number of global variables, structures that were accessed from anywhere in the code, and the mess was absolutely not portable to either Borland or Microsoft. The source code control database was missing, and evidently the programmers weren't using it anyways because the product was compiled from many similar directories depending on what they were kind of trying to do.

I had to get everything compiling again, and fix bugs in it. And yes, I fixed every bug I could reproduce.

So when DARPA wants a tool that can handle a mess like this, I say, "Go for it, fools!"

The closest that I've seen has been from Microsoft, with the Pex tool. The tool can follow a C# program's path, map it out, and generate tests. However, it's easy to write code that Pex can't map, and so the tool becomes useless.

Here's another couple of tools from Microsoft: Stylecop and FXcop. Stylecop works on the source code, and fxcop works on the compiled code. How often are these avoided? All the time.

The problem is not the lack of tools or methodologies, it's the lack of will to write good code. Java was supposed to be a write-once-run-anywhere solution, and provide a marvelous bulwark against malicious and heinous activities by miscreants. Now, how many times has Java and .NET been patched for security holes? Does using either result in inherently secure programs? Sorry, no, try again.