Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Contracting for Secure Code
Chris Wysopal, 2009-03-06

Forcing suppliers to attest to the security of provided software is gaining adherents: Just ask Kaspersky Lab.

Last month, the anti-malware company became the target of a hacker that used an SQL injection attack to gain access to the firm's support website. The attacker, a Romanian hacker, posted the details of the attack on his blog, claiming that he could access customer information and providing, as evidence, the details of the internal database table structure. A forensic investigation by database security expert David Litchfield determined that no customer data was accessed.

In the end, while there was a vulnerability, it wasn’t nearly as bad as it could have been.

Some might consider this to be a ho-hum story of a mediocre security bug that got overplayed because the attacker was publicizing it and the target was a well known computer security company. I find it interesting because Kaspersky didn’t develop the vulnerable Web site code. Instead, a third-party under contract provided the code to the company.

At a press conference, Roel Schouwenberg, the company’s senior antivirus researcher, laid the blame on his own company. "It was basically our fault. It slipped through our review process that normally all our code goes through," he said.

Kaspersky wasn’t blaming the company from which they purchased the code. To their credit, they were blaming themselves because they were the ones who accepted vulnerable code and deployed it.

Kaspersky's statement, however, points the way to a solution. Companies that want to take security seriously need to apply a review, not only to code they develop, but to the code they purchase. If purchasers don't hold sellers accountable, they will never solve the software security problem.

It’s undeniable that software developers building both packaged and custom developed software have a secure coding problem. Some of the major classes of vulnerabilities and how to prevent them have been known for 10 years or more, but they are still getting into software and causing problems for companies and their customers. Even companies that get security for their own development — still a minority, to be sure &mash; totally ignore quality when they outsource or buy software.

The availability of software security guidance, training, and tools hasn’t made much of dent in the number of attacks, which I predict will get worse unless companies buying code — especially under contract — include provisions that require secure code. Sellers would need to show evidence of minimum due care in preventing vulnerabilities or their software wouldn’t be fit to sell.

The obvious first place to implement this approach is when companies outsource part of their application development to an external party, such as Kaspersky did in the its recent case. In many transactions, the purchaser has leverage over the seller and can get the seller to agree to strict acceptance terms. The company gets the code delivered to them in source code form and performs the same security processes on it that they perform on their own code. If they find security problems in the code, they require the external party to fix the problems before final acceptance of the code and payment to the seller. If Kaspersky had followed that path, as they say they are going to, they would have prevented the cost and distraction of a PR problem.

Story continued on Page 2 

Chris Wysopal is co-founder and CTO of Veracode, a provider of on-demand software security testing services. Chris co-authored the password auditing tool L0phtCrack and was a researcher at the security think tank, L0pht Heavy Industries. He has held key roles at @stake and Symantec and is the author of The Art of Software Security Testing: Identifying Security Flaws.
    Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Comments Mode:
Third-party software 2009-03-11
Andre Gironda
Caveat Emptor 2009-03-12


Privacy Statement
Copyright 2010, SecurityFocus