One more thought on your database hypotheticals.....
> Like how does it know that creating a Statement with a concatenated string can cause SQL injection?
> What if I use a concatenated string to create a PreparedStatement?
> What if I use JPA?
> What if I use third party utilities like Apache DButils?
> What if I have my own library that is similar to DBUtils?
Contrast identifies vulnerabilities by combining two very powerful techniques: Data Flow Analysis and our Code Execution Pattern Matching. In Contrast, data flow analysis is done by actually tracking strings, byte arrays, and other Objects as they flow through the code. So we always know exactly which Objects (actually which exact part of Objects) need to be tracked. For SQL injection, we're looking to track untrusted, but if you want to track some other kind of data that's certainly possible. We have some clients using Contrast's DFA to make sure credit-card numbers don't go anywhere they shouldn't, for example.
So once we know where untrusted data is going, we just have to make sure we properly match the pattern of SQL Injection. We match all the possible ways of using JDBC to interact with the database, including Statement, PreparedStatement, and others. We match the JDBC API, not any one particular implementation, so no matter what database driver or persistence layer you are using, Contrast will properly identify the SQL injection.
Give it at try -- I'd love to hear how it works for you. Thanks for all the great questions.
--Jeff