You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Thanks for the feedback -- we will discuss and do our best to expose as much useful explanatory information as possible, as prioritisation of the various possible avenues for improvement permit. PRs welcome in the meantme of course -- but since your contributions to the project are already plentiful, I appreciate your time is also limited :)
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 argumentsCLASS
orMINIMAL_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.
The text was updated successfully, but these errors were encountered: