The notion of holding third-party software developers liable for such errors is not new.
Generally it is a good idea to ensure that procurement contracts include language spelling out the security expectations for a project, said Gary McGraw, chief technology officer at Cigital, a Washington D.C. security consulting firm. But rather than tying the procurement language to a generalized list of top programming errors, such as the one released today, companies should customize it to their particular environments, he said.
Companies should compile a list of the most common vulnerabilities in their own environments and use that as a basis for the language in their procurement contracts he said. "The notion of controlling your vendors to make sure they are following software security is a very good notion. But it need to tailored to your environment," he said.
Jaikumar Vijayan covers data security and privacy issues, financial services security and e-voting for Computerworld . Follow Jaikumar on Twitter at @jaivijayan , send e-mail to firstname.lastname@example.org or subscribe to Jaikumar's RSS feed .
Read more about software development in Computerworld's Software Development Knowledge Center.