Top 25 programming errors for 2009 announced in Washington D.C.

Today, in Washington D.C., a convergence of industry specialist have gathered to release the Top 25 Programming Errors and to also announce the establishment of common contract language that does not hold buyers liable for software containing flawed code.

The list includes many exploits that have been recently used; including the flaw that allowed Chinese hackers to infiltrate Google’s secured network.  The idea is that with broader education of the most commonly exploited flaws, programmers will be able to better protect their products.

The group of “acquisition experts [also] agreed on a standard for contract language between software buyers and developers. The use of this contract language helps ensure buyers are not held liable for software containing faulty code. Coding errors are a common gateway for attackers to penetrate networks.”  While this language is important to help protect the end user, it is up to the software vendor to include the wording in their own EULA. 

Lists such as these are important to help build more secure applications.  With the most common flaws for programming exposed it should help to build more secure applications and reduce network vulnerability.  These lists do not only help ensure that consumers are protected but also government agencies that may depend on consumer products.  

Report a problem with article
Previous Story

Hands on: New Android HTC Desire phone

Next Story

Aperture 3 causing crazy memory leaks

8 Comments

Commenting is disabled on this article.

If proper error handling is put in palce, and through validation is put in palce I guess a lot of problems can be sloved. For often I guess becuase of the pressure of deadline people tend of miss out few thing, but I am sure every company there are a few excessive human resource that could be put to proper use and make sure that the progam complies to all the necessary security checks and behaves properly. More stringent testing is necessary to double check that the error handling. And this is a well know fact I suppose, when using the code from the net, make sure to test it properly and aslo make sure that the code is tested proplery, and aslo in comments mention the source and give due credit. Also make sure that the code is well commented and documented.

Very interesting read. Most of these are stuff that any decent programmer should know about. Still that deadline is always pushing you and we are all human. Will read this through thoroughly when I get the time and send it to all the programmers at my company.
More stuff like this on neowin please!

p1p3 said,
Very interesting read. Most of these are stuff that any decent programmer should know about. Still that deadline is always pushing you and we are all human. Will read this through thoroughly when I get the time and send it to all the programmers at my company.
More stuff like this on neowin please!

As a software developer, i conur with all what you have said ...

p1p3 said,
Very interesting read. Most of these are stuff that any decent programmer should know about. Still that deadline is always pushing you and we are all human. Will read this through thoroughly when I get the time and send it to all the programmers at my company.
More stuff like this on neowin please!

I'd say that is a bit of a broad statement. Paint.net actually had a Race Condition in the previous version (albiet not security related, if you opened a dialog and entered a negative value fast enough you could make it crash or something)
Some of them, like buffer overflows are just common sense but not all of them are so simple.

omnicoder said,

I'd say that is a bit of a broad statement. Paint.net actually had a Race Condition in the previous version (albiet not security related, if you opened a dialog and entered a negative value fast enough you could make it crash or something)
Some of them, like buffer overflows are just common sense but not all of them are so simple.

That was what I said. Anybody writing production code should know about them, including race conditions. However they are easy to miss, especially when you have to get your code out the door fast. Cant remember how many times I had to ship code with known bugs because of a deadline (nothing serious that could cause a security breach but still).
Don't know the specifics about the Paint.Net bug but that sounds more like an input validation bug causing a race condition and input validation is a lot simpler to fix.

Magallanes said,
it is easy to say but it is hard (if not impossible) to prevent.


yea, but with some simple "rules" or checks while coding the app can make it allot harder