Thanks for the post, Steve. I'll chime in since I have a feeling I know where the idea for this Editorial came from 😉

I think xp_cmdshell should be disabled, period, and there should be additional controls in place to block and audit attempts to enable or use it. I agree with the previous poster Antares686 wholeheartedly....layering in your security strategy is fundamental. Disabling xp_cmdshell is but one layer.

On such a controversial, deep and broad topic as "securing your SQL Server", and how daunting it can appear to be, xp_cmdshell is but one attack vector. All vectors deserve to be addressed and disabling xp_cmdshell as well as putting a few additional controls in place in an attempt to prevent it from being enabled (including Policy Based Management to prevent it from being enabled and possibly dropping the XSP itself) are well worth the effort and can be added to an "instance setup" script so it won't be much effort. I am thinking of publishing my PBMs but need to do some additional testing with dropping the XSP before going public with that.

I also like what jfogel said about challenging himself to work without xp_cmdshell. With so many great tools being released since SQL 2000, including .NET, SSIS, and especially PowerShell, we as database and system administrators really have a lot of other much more robust options avaiable besides xp_cmdshell.

It's hard to tell if the writing is in fact on the proverbial wall for xp_cmdshell because nothing official has been released from Microsoft, but Extended Stored Procedure Development has been officially deprecated in favor of SQLCLR Development and Microsoft has been slowly dropping their own Extended Stored Procedures from their product. I for one hope xp_cmdshell is one day deprecated, and eventually removed from the product. At minimum I would like for a way to force a true install of it so that it could not be simply enabled using sp_configure, and instead would require the installation media to be used to bring that feature online. That would put to rest this idea that there is no use in disabling xp_cmdshell because a sysadmin could easily re-enable it.

In addition to the various security concerns I and others have mentioned, and thanks to TravisDBA for highlighting "DOS injection", there is also the problem of auditability. xp_cmdshell does support a proxy account, but only one for the entire instance. This means that anyone using xp_cmdshell as a non-sysadmin will appear as the same person to the host operating system which can pollute auditing and make troubleshooting very difficult. In the case of sysadmins you have the same auditing problem except the host operating system sees the cmd shell process as being invoked by the SQL Server service account. This could amount to permission elevation. Now, you may say a sysadmin could gain elevated permissions via a SQL Agent Job or a SQLCLR object and you would be right, but that's why security is an exercise in eliminating possible points of attack and layering your defenses. I look at everything and everyone as a possible security threat to the systems and data I manage and no matter how I slice it xp_cmdshell brings with it a negative net effect on security and auditability whereas disabling xp_cmdshell brings with a positive net effect, no matter how small some folks may argue that net effect may be. So for me, xp_cmdshell simply doesn't make the cut. I say it should be disabled on all instances and measures should be taken to keep it that way.