Another example why SATS technology needs custom rules (re: Detecting SQL Injection on .NET Entity framework)

In Darren's great SQL Injection with Entity Framework 5 and Static Code Analysis post, he mentions how all SAST tools he used failed to find this security vulnerability:


The reason is simple: None of the tools he used had the Database.SqlQuery Method marked as a Sink (and btw last time I checked FxCop is not a SAST tool)

One of the things I wanted to do this week was to add a rules manager/editor to CAT.net (see my current research on this SAST tool from Microsoft here), and this could a good example (i.e. show how to write a custom CAT.Net rule to detect this security issue).

On the topic of documentation, it would be nice if the MSDN documentation pages on these methods mentioned the SQL Injection dangers:

• Database.SqlQuery Method
• Database.SqlQuery<TElement> Method (String, Object[])
• Database.SqlQuery Method (Type, String, Object[]) 

Actually looking at the Database class, there are a couple other dangerous methods (assuming the attacker can control the string value):

• Database.ExecuteSqlCommand Method 
• Database.Exists Method (String) 
• Database.Delete Method (String) (this one could be a nasty one if exposed via an XSRF vuln)

Question: Is there a list of all Linq and Entity framework methods that need to be marked out as Sinks? (for a SAST engine)