Security

Security Fixes: We Need More Than a List

Oh, not again. Last week, the SANS Institute and Mitre released yet another list of the most serious programming errors that break software security. And this time, SANS and Mitre got dozens of other organizations to sign on, including Microsoft , Apple, Oracle , Tata, Symantec , the Department of Homeland Security and the National Security Agency .

But no matter how good it is, a list won't solve this problem.

Yes, it's a fine list. It includes all our old favorites: overflowing buffers , unchecked input, random numbers that aren't really random, failure to block cross-site scripting and SQL injection . (You can find the complete list at www.sans.org/top25errors .)

Trouble is, we've seen lists like these before . Security groups have been issuing them for decades -- and nothing much has changed.

SANS and Mitre say this one is better, because this time they tapped dozens of other organizations to help compile the top 25 programming problems. Surely that will convince programmers to see the error of their ways and start coding securely, won't it?

No, it won't. Programmers who care about security don't need this new list. They already know about these problems and work to avoid them.

And programmers who don't care about security won't even notice the new list. They figure security is somebody else's job.

But this list isn't a complete waste. There's the germ of a new idea here -- and if we're really lucky, SANS and Mitre will make it a reality.

One of the goals for this new list is that big software buyers will be able to use it to improve software quality. For example, SANS says some state governments are already thinking about requiring software suppliers to certify in writing that their code is free of the errors on the list.

Self-certification? Yeah, good luck with that.

But wait -- there's no special reason why any buyer should have to trust a software provider's word that the code is clean. Why not make third-party certification the standard? Certification companies could get access to the source code, run automated code checks and provide reliable results to software buyers about how clean the code really is.

Of course, the reliability of those third-party certifiers would depend on the quality of their test suites. If every certifier gins up its own tests, that quality could be all over the map.

But it doesn't have to be -- not if SANS and Mitre and their partners sponsor development of a standard test suite and then make it freely available.

Think about it. Those third-party certification companies would gladly use that test suite, because the certifiers would be off the hook for any top-25 errors the test suite fails to find.

Software providers would happily use the test suite to make sure their code would achieve third-party certification on the first pass.

Security companies would fall all over themselves to discover top-25 errors that could get past the test suite. They'd issue their press releases, the test suite would be updated, and the new version would be the new standard.

Companies that currently make software testing tools? They could integrate the top-25 test suite with their own products, which customers would still buy for all the other code problems that those products catch.

And corporate IT shops that think they can't afford testing tools? They'd have no excuse not to use the free top-25 test suite.

Developing that suite wouldn't be easy -- technically or politically. But SANS and Mitre have already lined up the big players who can help make it happen. This is their chance to make more-secure software a reality.

That would sure beat yet another list.

Frank Hayes is Computerworld 's senior news columnist. Contact him atfrank_hayes@computerworld.com .

This version of the story originally appeared in Computerworld 's print edition.

Got something to add? Let us know in the article comments .

Subscribe to the Security Watch Newsletter

Comments