Security or performance risks using SQL CLR
The question, as Remus pointed out, is too generic to get an answer as the answer depends on the context of what functionality is to be used and how will it be used.

Regarding "Security":  

If you are asking about anything that can be done in an assembly marked with PERMISSION_SET = SAFE, then there aren't any issues that I have ever been able to find. And SQLCLR is "safer" than using xp_cmdshell or the wonderful (that was sarcasm) sp_OA* procs (or even Extended Stored Procedures, but hopefully nobody is creating any of those anymore).

If you would like a walk-through of what "SAFE" means in practical terms, please see this article: Stairway to SQLCLR Level 3: Security (General and SAFE Assemblies) (free registration required).

If you are asking about anything that can be done in an assembly marked with PERMISSION_SET = EXTERNAL_ACCESS, then there are certainly risks, again, depending on what functionality is being used. If you write a routine to read directories and file names (i.e. read-only), then it is just a matter of what should be seen and not seen. If you are writing code that allows for deleting a file, the risk increases. But what can be done with those external resources is controlled by:


whether or not you are using Impersonation:

no Impersonation means accessing external resources is done via the "Log on as" account of the SQL Server service. Whatever that account has access to, your SQLCLR function will be able to do.
using Impersonation means that the Login in SQL Server that is running the function, if that Login corresponds to a Windows Login, can do whatever that particular Windows Login is allowed to do. If the Login in SQL Server is a SQL Server Login, then attempting to use Impersonation will get an error.

What permissions are set up on the external resource. For filesystem access, this is controlled through ACLs on NTFS drives.


If you are asking about anything that can be done in an assembly marked with PERMISSION_SET = UNSAFE, that is fairly open-ended. A lot of functionality is deemed only usable in UNSAFE assemblies because they are issues of stability and/or consistent behavior more than security or performance. For example, in an UNSAFE assembly it is possible to have a writable static variable. This is typically not a good thing to do since the SQLCLR classes are shared across all sessions. If your intention is to share data in memory across all sessions and have planned for race conditions (and done plenty of testing), then you should be fine as you are expecting this behavior. But if you simply wanted a writable static variable to cache a value for a particular session to not have to look it up again or calculate it again, and were not aware that other sessions are reading that value and possibly over-writing it, well, that would be an issue.

But if you are worried about someone writing to the Registry, but yet don't have any code that actually writes to the Registry, then you probably don't need to worry about this ;-).

If you would like a walk-through of how EXTERNAL_ACCESS and UNSAFE work in practical terms, and the difference between setting TRUSTWORTHY ON (not preferred) vs using an Asymmetric Key- or Certificate- based Login, please see this article: Stairway to SQLCLR Level 4: Security (EXTERNAL and UNSAFE Assemblies) (free registration required).

Regarding "Performance":  

This is all a matter of what you are trying to do and how you go about doing it. There are some things that are much faster in SQLCLR, and some things that are slower. But just like with T-SQL, it is possible to take a somewhat simple and/or efficient task and make it complicated and/or inefficient by doing things incorrectly. But using SQL CLR is not inherently, by its very nature, slower.