False positives Due to query inability to check Dependency Presence

**Description of the false positive**

For example, the Java detection for insecure-bean-validation is only a vulnerability when the underlying bean validator resolves EL Expressions. Although the Netflix team fixed this vulnerability, it's still listed on LGTM.com as being vulnerable.

https://lgtm.com/projects/g/Netflix/conductor/?mode=list&tag=security&id=java%2Finsecure-bean-validation

The fix is described here:
https://github.com/Netflix/security-bulletins/blob/master/advisories/nflx-2020-001.md#the-fix

According to @pwntester:

> they fixed it using Apache BVal instead of Hibernate Validator. Apache BVal is secure by default since it does not resolve EL expressions

Because CodeQL can't query what dependencies are present or not-present, you can't validate whether or not the vulnerability truly exists.

Similar cases exist when looking at HTTP Request Splitting Vulnerabilities that are due to the use of the Java Servlet Container API's. I presume that certain Java servlet container APIs may still be vulnerable to HTTP Response Splitting, but neither the Query, nor the associated documentation describes what dependencies are known to make you vulnerable and which are not vulnerable.

https://codeql.github.com/codeql-query-help/java/java-http-response-splitting/

Best case, CodeQL queries should be able to communicate something along the lines of the following:
- If this implementation library is present on the classpath, this is known to be vulnerable.
- If this implementation library is on the classpath, that's the probable implementation being used, so it is most likely not vulnerable.
- If no implementation library can be found, then assume that any implementation could be present at runtime, so alert.

I believe something like the above would help reduce false positives in-general.