Top 25 Programming Errors: Should Software Developers be Liable?
Group Proposes Accountability; Expert Calls Plan' Silly'
Linda McGlasson
February 16, 2010

Should software developers be held liable for their programming errors? A consortium of international cybersecurity experts says yes - and will present its plan for such a program on Tuesday. But at least one dissenting voice calls the effort "counterproductive and silly."

In Washington, D.C., on Tues., a group of more than 30 U.S. and international cybersecurity organizations, led by MITRE and SANs, will release a new list of the 25 most dangerous programming errors. These mistakes have been the cause of almost every major type of cyber attack, the group says, including the recent strike on Google, power utilities, military systems, small businesses and consumers' PC's.

A similar list of programming errors was released in January 2009 and had the backing of the National Security Agency and the Department of Homeland Security's National Cyber Security Division.

Vendors Held Accountable

In addition to naming the most common programming errors, this year's panel of experts has also agreed upon a standard for contract language between software buyers and developers that would essentially hold vendors accountable for their programming errors.

"Nearly every attack is enabled by mistakes programmers make that provide a handhold for attackers," says Alan Paller, Director of Research at the SANS Institute. "The only way programming errors can be eradicated is by making software development organizations legally liable for the errors. And that can only be done if there is a safe harbor."

A safe harbor provision in a contract reduces or eliminates a party's liability on condition that, in this case, the software develop performs its action in good faith.

The latest announcement is "the foundation for the safe harbor for software vendors," Paller says. One of the leaders in the development of the standard for contract language was Wil Pelgrin, director of New York State's Office of Cyber Security & Critical Infrastructure Coordination. The draft states that the "'highest applicable industry standards' should be defined as the degree of care, skill, efficiency and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances."

"Software vendors can be held liable for their errors because we know have a definitive minimum standard of due care," Paller says. "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, he adds.

This year's Top 25 is a big improvement to the 2009 list, Paller says, but the spirit and goals are the same. The list prioritizes its entries using inputs from 28 different organizations that have evaluated each weakness based on prevalence and importance. The new list introduces focused profiles to allow developers and other users to select the parts of the Top 25 that are most relevant to their concerns. The new list also gives a small set of the most effective mitigations, to aid in reducing or wiping out entire groups of weaknesses.

Reaction: "Counterproductive and Silly"

While last year's Top 25 List garnered much fanfare when first announced, one global software security expert doesn't see this annual exercise doing much good in the fight against cyber attacks and cyber crime.

Gary McGraw, CTO at Cigital, a software security company, says his thoughts on these lists of bugs remains pretty much the same as last year, when he published his response, "Top Eleven Reasons Why Top Ten Lists Don't Work."

While McGraw says he does agree that awareness and further education for programmers is needed, and that he welcomes the spotlight being turned on software security flaws and bad code in general, "I think procurement language linked to a list of specific bugs is counterproductive and silly." Based on his experience as an expert in litigation, "My prediction is that there will be zero lawsuits, and that this list will do nothing to provide safe harbor in the case of insecure software," McGraw says. "There is much more to building secure software than hunting down 25 bugs."

Close Window is your source for bank information security news, regulations, and education.