Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[All Languages] Enrich CodeQL Query Results to Provide more Details #11912

Open
JLLeitschuh opened this issue Jan 17, 2023 · 2 comments
Open
Labels
question Further information is requested

Comments

@JLLeitschuh
Copy link
Contributor

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.

@JLLeitschuh JLLeitschuh added the question Further information is requested label Jan 17, 2023
@JLLeitschuh
Copy link
Contributor Author

@smowton
Copy link
Contributor

smowton commented Jan 17, 2023

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants