AOH :: ISNQ5941.HTM

Proposal Would Hold Software Developers Accountable For Security Bugs




Proposal Would Hold Software Developers Accountable For Security Bugs
Proposal Would Hold Software Developers Accountable For Security Bugs



http://www.darkreading.com/vulnerability_management/security/app-security/showArticle.jhtml?articleID=222900574 

By Kelly Jackson Higgins
DarkReading
Feb 16, 2010

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 
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."

[...]


________________________________________ 
Did a friend send you this? From now on, be the 
first to find out! Subscribe to InfoSec News 
http://www.infosecnews.org 

Site design & layout copyright © 1986-2014 CodeGods