Mike Vernal has a write-up of some counter-arguments for the recent CyberInsecurity paper in which he discusses the effect of a SQL-based virus against computers across the world. The SQL Slammer virus was compounded by the need to track redistribution of components of SQL Server, not just the server product itself. The Windows world has a model of redistribution using "merge modules" - shrink-wrapped components of a larger application that customers can redistribute. The trouble with this model is that when a merge module is installed the package code associated with it doesn't get registered on the system and so detecting installation is made more difficult, likewise patching if the redistributable is detected. On WSE, we're concerned about this problem as it affects our ability to service indirect customers - those that have our assembly installed as part of someone else's product.
We're going to take some pro-active steps to try to mitigate this in the final 2.0 release but, like the dependency Microsoft has on people running Windows Update, we're still dependent on people that redistribute our product having plans in place to monitor for security bulletins and then be able to redistribute any patches in a timely manner to their customers. This is true whether the redistribution is via an internal IT department or an ISV. If you're going to redistribute, make sure you take account of this and plan appropriately. Alternatively, don't redistribute WSE but have the customer install it directly as a pre-requisite - that way at least the customers IT department has a chance to get into the loop and prepare themselves.