Bill Gates must be livid. Just after he publishes an e-mail letter to customers outlining Microsoft's progress on its Trustworthy Computing initiative, the SQL Slammer worm--376 bytes of code also known as Sapphire, w32.SQLexp.worm, and Helkern--exploits known vulnerabilities in Microsoft SQL 2000 servers. It creates a global Internet slowdown and another embarrassment for the chairman of the world's most powerful software company. And to top it off, Microsoft's own servers were Slammed.

The worst part is that a patch for the vulnerability exploited by the Slammer worm was issued last summer and was included in the latest service pack for Microsoft SQL Server 2000. In fact, the majority of successful hacks come as a result of an exploitation of a known vulnerability. In failing to apply the updates to some of its servers, Microsoft didn't follow its own security polices. Gates, Ballmer and the other Microsoft execs are probably still cooling down, trying to avoid strangling the company's system administrators.

Given that a patch was available, Microsoft should not have both feet held to the fire. Gates and company are extremely serious about removing the stigma attached to the level of security in its products. With customers looking to cut costs and Linux initiatives cutting into Microsoft's dominant share across multiple markets, having a reputation for defective, insecure products is not helpful in convincing customers to stay the course.

As part of the year long focus on security, the company claims that it retrained 11,000 developers--at a cost of more than $200 million in lost productivity--to make its products more secure. Tools like the Microsoft Baseline Security Analyzer, which scans systems for common misconfigurations across most of the company's products, are popping up.

But it's the customers who are also stuck with escalating costs to deal with vulnerabilities from Microsoft and many other vendors at a time when cost reduction is crucial IT priority. Sticking customers with the cost of maintaining the security of products is unacceptable. System administrators who fail to apply patches are certainly to blame in cases where a fix was available, but it's not that simple.

Applying patches can have unintended consequences. Because patches that fix one problem can create new ones, system administrators are understandably conservative when it comes to deploying patches without rigorous and time-consuming testing. Microsoft is trying to address the problem with its Software Update Services (SUS), which allows customers to download relevant patches to a SUS server and test the patch before deploying it in a live environment. But the cost of running those compatibility tests is borne by the customer, and the test isn't going to replicate exactly the live production environment in which the patch must live.

And, as Microsoft's own problems with the Slammer worm point out, keeping up with the stream of patches required to stay ahead of hackers is not easy, especially in an environment with downsized IT departments. In light of this situation, I have simple proposal. Microsoft makes products that have defects. It may be the result of a complex eco-system in which making millions of lines of code invulnerable to hackers is a Sisyphean task. Still, the cost to implement patches is a financial burden to Microsoft's customers.

With more than $40 billion stashed away, waiting for a good use besides providing a dividend for shareholders, Microsoft should use a small amount of those cash reserves to pay customers for the cost of testing and installing patches that address specific vulnerabilities. You don't pay to have your car repaired when a manufacturing defect is found.

Microsoft may be the biggest culprit because of the huge Windows market, but it's obviously not alone. The Red Hat Network, for example, routinely posts patches to address security vulnerabilities with its Linux distribution.

Any vendor whose products need patching due to security vulnerabilities can cut you a check for the labor associated with installing patches. And who should foot the bill for downtime and lost business due to a security breach in a specific piece of software? Maybe the vendor should help to pay your hacker insurance premium.

It will take time to sort this out, but the cost of keeping your network and systems secure should be a shared burden, not just a cost of doing business.

What do you think? Should Microsoft or other vendors pay you to apply the patches in their software? Share your views in ZDNet's TalkBack forum or e-mail me at dan.farber@cnet.com.