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.

If you are purchasing code, but don’t have an internal software security process — as is the case for the majority of businesses — you need to follow an industry consensus of what the definition of minimum due care is for software sellers. With the recent release of the CWE/SANS list of Top 25 Most Dangerous Programming Errors, every company now has a place to start.

The CWE/SANS Top 25 was created by a group of individuals from over 30 organizations from government, academia, and industry. (Disclosure: I was one of the contributors.) It is not a list of attacks, but a list of root causes, the programming errors, that lead to successful attacks. If you eliminate the root causes, you eliminate the vulnerabilities. The programming errors were selected based on prevalence and severity. These are the programming errors that end up causing the vast majority of application security breaches.

One attribute I like about the CWE/SANS Top 25 is that there was so much agreement across a wide group of contributors of what should be on the list. The second attribute I like about the list is it is short.

Software security experts are sometimes their own worst enemy. We revel in the details and complication of coding errors. It sometimes seems as if there are hundreds of different ways a vulnerability can arise in code and indeed the Common Weakness Enumeration (CWE) has cataloged over 600 classes of programming errors. If you look at the prevalence of what ends up being the root cause of vulnerabilities reported in real world software, you will see that after the top 25, it’s exceedingly rare. The 26th most prevalent problem is CRLF Injection and it was reported in 0.2 percent of cases, or in eight out of 4855 total vulnerabilities, in 2008.

The 25 most prevalent entries in CVE — not exactly the same as the CWE/SANS Top 25 — make up over 70 percent of the reported vulnerabilities. By focusing on the 4 percent of common CVE cases, we are using the 80/20 rule to help bound a problem to the most important part that you can solve in a reasonable amount of time. The CWE/SANS Top 25 takes a long and complex list of errors that a programmer could make and makes prevention tractable.

With the CWE/SANS Top 25, software purchasers can force third-party contract coders to avoid a reasonable list of programming errors. One organization, New York State, has drafted Application Security Procurement Language to "make code writers responsible for checking the code and for fixing security flaws before software is delivered." I expect more organizations will follow suit, as progress is made in codifying accountability and the processes needed to enforce contract terms.

This is the best way forward. If purchasers don't hold sellers accountable, we will never solve the software security problem.