Proposal Would Hold Software Developers Accountable For Security Bugs

SANS' newly released Top 25 list of common programming flaws came with a little legal muscle, too, with representatives from SANs, Mitre, the U.S. Department of Homeland Security, the National Security Agency, and other organizations pushing for custom software developers to be held liable for insecure code they write.

Experts from more than 30 U.S. and international organizations, including OWASP, Microsoft, Apple, EMC, Oracle, McAfee, and Symantec, contributed to the CWE/SANS Top 25 list. And procurement experts from some of the organizations are recommending standard contract language for procurements that would ensure buyers aren't held liable for software that contains security flaws. "Wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems," says Alan Paller, director of research for the SANS Institute.

Paller says the contract language would be based in part on a draft in the works by the State of New York (PDF) that refers to the SANS Top 25 and would make the state's custom-software vendors contractually bound to provide apps that are free of those bugs. Paller says although there is "no formal agreement on the language" among the group at this point, it's focused on the section of New York's proposed contract language that reads: "the Vendor shall, at a minimum, conduct a threat assessment and analysis of vulnerability information, including the current list of SANS 25 Most Dangerous Programming Errors; provide the Purchaser with a written report as soon as possible after a vulnerability, threat, or risk has been identified."

He says some final tweaking of the language would ideally add a warranty for correcting secure-coding errors "at vendor expense."

Such a legal arrangement would not only protect customers of the software, Paller says, but also provide developers with a "safe harbor" of sorts. "What do I have to do to supply software that's safe enough so I don't get into legal problems with the customer?" he explains.

Joe Jarzombeck, director for software assurance for the national cybersecurity division at DHS, says any contract language would be voluntary. "There is no unified mandate," Jarzombeck says. And the Common Weaknesses Enumeration (CWE)/SANS Top 25 list is now being adopted by tool vendors as well, he notes.

"The [list is not to] say, 'Here's how to be 100 percent secure,' but to more definitive in the specific risks," he says.

For the buyer, making the vendor liable for security bugs would help protect its organization from potential breaches exploiting those flaws as well as prevent the vendor from charging them extra to fix them. And for developers, it's a "minimum standard of due care," SANS' Paller says.

But Gary McGraw, CTO of Cigital, whose company was involved with the project, says he predicts such an effort would yield "zero lawsuits" and would instead lead to more expensive software. "The liability angle is not the right idea," McGraw says. "The market is working right now. Sure, software is still busted. But companies are really making marked progress. As long as that's working, I don't see why you should invoke the liability hammer."

SANS' annual list had been criticized by security experts as more of a laundry list rather than offering a solution, but this year the list came with so-called "focus profiles" that broke the programming errors into groups based on categories of weaknesses and also provided mitigation information. The list is in order of priority this year, with failure to preserve Web page structure (think cross-site scripting) as No. 1, and race condition mistakes as No. 25, notes Robert Martin, lead for compatibility and outreach at Mitre.

The Top 25 encompasses programming mishaps that are the root cause of most major cyberattacks, including the breaches at Google, power companies, military systems, and attacks on small businesses and home users, its creators say.

Even with the upgrades to the Top 25, McGraw says it's ineffective: "It's still a popularity list and not based on actual bug data from any real company," he says. Meanwhile, OWASP, which is working on its final Top 10 list of Web application security risks, was "mapped" to this list as well, says Chris Wysopal, CTO of Veracode, who was among the participants in the Top 25.

Wysopal says large organizations in finance, government, or that run applications associated with "life or limb" applications are already including language in their large software contracts that hold their vendors accountable for clean software.

But the legal implications of secure coding contracts remain unclear. "I don't see an organization being held accountable when they submit their software for testing, get a clean bill of health, and later a defect is found that was missed," Wysopal says. "We know the state-of-the-art is not 100 percent."

Cigital's McGraw says software developers don't need to be forced to do the right thing: "They need to know what the right thing is," he says. "It's more important to teach them how to do it right than how to avoid a thousand bugs."

And many developers aren't even aware of secure coding issues at all, which the Rugged Software Development initiative, launched last week, aims to remedy by reaching out to the masses about secure development practices. Joshua Corman, research director for the enterprise security practice at The 451 Group and a co-founder of Rugged, says Rugged hopes to inform and steer developers toward secure coding efforts, such as the Top 25.

"This is very complementary to Rugged," Corman says of the SANS Top 25 list. "We would serve as a catalyst or on-ramp to help people learn of the Top 25."

Thus far, efforts to preach secure coding to developers haven't worked, he says. "What we want is people to care about security and developing rugged code," Corman says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.