Description
CodeQL is incredibly powerful to detect security vulnerabilities, but the pre-canned queries are, sometimes, really bad about explaining WHY a vulnerability was flagged.
In particular, this comes up when there are multiple data flow algorithms used to detect a security vulnerability.
To provide a more concrete example, let's look at the java UnsafeDeserilization query, this is the message you get when this vulnerability gets flagged: Unsafe deserialization depends on a $@.", source.getNode(), "user-provided value
This vulnerability may get flagged because of the following Faster Jackson code: com.fasterxml.jackson.databind.ObjectMapper::readTree. But, supposedly, Faster Jackson is secure by default. So why is it getting flagged? The CodeQL query also looks and tries to find classes that are annotated with @com.fasterxml.jackson.annotation.JsonTypeInfo with either the arguments CLASS or MINIMAL_CLASS.
Now, CodeQL knows this, and has found all the AST nodes that indicate this vulnerability is present, but this information isn't communicated to the end-user at all. All the end user gets is a very vague message, when these messages could be greatly enriched with so much useful data to simplify the triaging of a vulnerability report.
If you ever look at the output of an error from the Rust Compiler, the error messages are incredibly rich, and can even point to documentation.
CodeQL's query outputs can be so rich, because of the information that can be captured from the code, but this richness seems entirely under utilized in the message generation.
I'd like to challenge the CodeQL development team to try to think more deeply about the error messages presented to users, and how we can enrich the messages these queries provide.