CodeQL is missing an inline mechanism to suppress warnings

This was asked about in #9298 and the issue log stated "closed as not planned". The "answer" was to dismiss via the UI. But this alone is really not a sufficient mechanism:

Having to interact with the UI is supremely annoying
Spurious new warnings if the code moves cannot be avoided this way
It is good to be forced to comment these exception inline where they happen
What if you are running codeql locally? Then here is no mechanisim?

Please consider supporting this basic, table-stakes feature that many, many linting/scanning tools afford.

@bryevdv

Hi @bryevdv! Thanks for taking the time to give us feedback on CodeQL. We're constantly considering how we can improve GitHub code scanning and CodeQL.

Having to interact with the UI is supremely annoying

I completely understand where you're coming from on this one, and it's a topic that is often debated in the team — many different opinions! We've also asked users whether they'd prefer to dismiss alerts in the UX, or whether they'd prefer to do that in-line in the code. The former turned out to be more popular. But you're certainly not the only one who would have preferred the latter!

Two other reasons that led us to choose for UX-based dismissal:

It means that in large organisations, security teams (who often don't have commit access to a codebase) can still help triage alerts and thereby reduce the number of alerts that developers need to deal with.
It makes it a lot easier for the CodeQL team to improve the analysis based on the FP reports from users (and the messages they include in that). We keep an eye on how different CodeQL analyses (for different types of vulnerabilities) behave; if a particular category of results is ignored more than others, we take a closer look.

Maintaining two approaches for dismissing alerts (in-code + UX) can lead to significant confusion. However, this is certainly something we will continue thinking about.

Spurious new warnings if the code moves cannot be avoided this way

When code moves, the context of an alert changes too. For example, what was previously a non-exploitable SQL injection might suddenly be exploitable. Due the high precision of the CodeQL analysis, we don't hear very often that users are frustrating that we flag up the same alert again. If/when an alert re-appears, it's therefore often worth a quick look and double-check!

(Note that code scanning does a pretty good job at not flagging up the same alert again if there are small, unrelated changes to the code!)

What if you are running codeql locally? Then here is no mechanisim?

Many people use CodeQL in so many different ways! I'd love to hear more about how you use CodeQL locally, so we can see whether we can improve how the tool works for your particular workflow.

Please consider supporting this basic, table-stakes feature that many, many linting/scanning tools afford.

I hope I've been able to convince you that a lot of thought and consideration has gone into code scanning and CodeQL. The CodeQL engine and GitHub code scanning are carefully fine-tuned, and we aim to give our users much more precise alerts and a better user experience than most linters do.

Cheeky side-note 😛 — if you have ideas on how to improve the quality of our analysis further, please consider making a contribution to our open source codebase, or consider joining the team! Examples of current openings 1, 2, 3; full list here.

Thanks again for taking the time to share your thoughts — much appreciated. We'll definitely keep your suggestion in mind for future consideration!

@sj

HI @sj thanks for the reply

reasons that led us to choose for UX-based dismissal

Well, I used to work for Microsoft. I know that the primary reason is the desire to collect telemetry from the web UI. 🙂

security teams (who often don't have commit access to a codebase)

I appreciate a web UX might be useful for that situation, but I also submit that many/most OSS projects are not in that situation, and that overworked, oversubscribed OSS maintainers would really just prefer to streamline their process. Being able to leave one comment, once, inline, in one place, is the most economical option under that lens.

I'd love to hear more about how you use CodeQL locally

I'm not sure what there is to add. GH publishes instructions for using the CodeQL CLI. I (and I am sure others) do run CodeQL that way sometime. Perhaps I can turn the question around: if someone is using the CodeQL CLI, what is the accepted mechanism for them to ignore specific warnings? If there is not one, is that not an important feature omission?

Maintaining two approaches for dismissing alerts (in-code + UX) can lead to significant confusion.

Is there evidence for this claim? It's not personally confusing to me, at all. LGTM offered a line exclusion comment, can you speak to specific data collected at Semmle that demonstrated significant confusion when it was available? When I worked in MS DevDiv there were often controlled usability studies conducted on APIs, are you saying this specific question has been examined in proper usability studies?

And even if so: if having both options at once is the problem, the choice for one or the other method could a mutually exclusive global configuration for the repo.

Lack of support for in-code alert management is just bizarre to me. The code is the context — not your UI, not config files, not workflows. Combine this with the currently poor control over which files/folders to include/exclude in compiled code and it's just unnecessarily hard to configure CodeQL.

Same here, we are observing #11407 and #11408 on our code base, which are effectively false positives, and would love to use an inline mechanism to suppress the corresponding warnings. Just to list a few examples:

As far as we understand, CodeQL does not feature inline suppression comments/instructions, like what LGTM did with lgtm[py/import-and-import-from], right? (crate/crate-python@4397cc2e7)

The code is the context — not your UI.

👍

Thanks for adding your voice to the discussion, everyone 🙇 . We'll definitely take this feedback into account!

I am honestly shocked that there is no inlining mechanism to suppress false positives. Or at least a way to identify them in a configuration file of some sort...

I just re-re-read through all the documentation again thinking I must have somehow missed it...or that since Ruby is a new kid on the block it hadn't been implemented yet...but nope.

Glad that I (finally) thought to come and look here...

@sj

Is there a solution planned for this or has anyone found a workaround? Almost every other scanning and linting tool I have used in the past 5+ years has inline 'exception' capabilities. I understand the arguments that @sj is making here but this feels like an prescriptive solution that makes this untenable in the long run for some folks like myself.

The key benefit of inline suppressions is that the reason and intent for the suppression is recorded in the most prominent place: at the site of the warning. Once a PR is merged, no one is going to look up the PR that introduced a CodeQL warning and dig out the dismissal comment. People read source code, not merged PRs.

As others have said, every other tool for static code analysis has this feature. I'd say the burden of proof lies with those that claim this feature is not needed.

Not going to use it until it supports this.

I think my favorite part about this is that LGTM supported suppressing issues using a comment in the code - so someone made the deliberate decision to remove that feature after Semmle was acquired by Github.

The advanced-security/dismiss-alerts Action implements support for inline suppression comments and automatically dismisses alerts in GitHub Code Scanning.

Dear Arthur,

thank you very much for telling us about advanced-security/dismiss-alerts. Based on what we reported at #11427 (comment), how we used lgtm-based suppression comments in the past, the documentation at getting started with dismiss-alerts,

A user can provide their own custom alert-suppression query, or use the ones that we provide (//lgtm or //codeql style comments).

and, referring to crate/crate-python@4397cc2e7, would that be a correct way to annotate code correspondingly today, in this case for Python?

class DummyTable(self.Base):  # codeql[py/unused-local-variable]
    pass

With kind regards,
Andreas.

@amotl

@amotl That would indeed be the right way to annotate code if you run the default AlertSuppression.ql query in addition to the normal CodeQL rules. The legacy #lgtm comments should also work, however, I see you removed them already from your code.

Chore: Suppress unqualified CodeQL admonitions

Has anyone tried to mimic the codeql + dismiss-alerts duo locally? We'd like to run this kind of checks beforehand, and don't see the alerts we dimissed

fix: properly suppress CodeQL regex injection warnings using filter-s…

fix(codeql): use correct suppression syntax for py/unused-import

chore: remove ineffective inline CodeQL suppression comments

fix(codeql): use correct suppression syntax for py/unused-import

Any updates on this?

Have you considered using the https://github.com/advanced-security/dismiss-alerts action as a workaround?

@aibaars

Dear @aibaars thank you for your answer. I am using it indeed as a workaround and it does work. but it is not ideal. Using Dismiss Alerts Action means that there's one more codebase to understand, utilize, and trust. Is this "workaround" implemented based on the arguments from 2022?

It seems to me (unless I'm missing some further context) that the reason why CodeQL does not have inline warning suppressing functionality is so users are forced to use the UI. @sj kindly suggested that security concerns may appear from the divergence between UI and inline rules, but IMO that's the user concern and responsibility, and of course assumes that users are interested in using the UI :-)

It seems to me (unless I'm missing some further context) that the reason why CodeQL does not have inline warning suppressing functionality is so users are forced to use the UI.

Doesn't that make the existence of the CodeQL GitHub Action useless?

I think this is more about the codeql security magic workflow than a codeql action.

https://github.com/github/codeql-action has a bunch of things including upload-sarif which is fairly useful (I no longer use it, as I've reimplemented the pieces that I need).
You could also write your own workflow that does some processing of codeql output before it submits and that should probably work fine (minus having to write that code).

The on: dynamic bits definitely sound frustrating, and I'm glad it isn't something I personally need to worry about (it certainly is the point of this issue).

Throwing my own $0.02 in here to agree. No in-source suppression for false alarms makes this tool worse than useless and https://github.com/advanced-security/dismiss-alerts frankly just doesn't work.

Tests that cry wolf get ignored. Tests that get ignored are worse than no test.

dismiss-alerts is worse than useless when working with the Advanced Security tasks in Azure Pipelines, because it requires SARIF files to modify, and the AdvancedSecurity-Codeql-Analyze task feeds directly into the Advanced Security system without any SARIF files to intercept. It's incredibly silly how CodeQL doesn't have this, how weak their defense of removing it has been, and the complete silence towards those of us who are asking for it to be brought back.

Navigation Menu

Repository navigation

CodeQL is missing an inline mechanism to suppress warnings #11427

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CodeQL is missing an inline mechanism to suppress warnings #11427

Description

Activity

sj commented on Nov 25, 2022

bryevdv commented on Nov 27, 2022

ckreibich commented on Nov 29, 2022

amotl commented on Dec 2, 2022

sj commented on Dec 2, 2022

DarrenKipu commented on Dec 5, 2022

scotthain commented on Mar 6, 2023

hannes-ucsc commented on Apr 27, 2023

hoonto commented on Jul 20, 2023

randombit commented on Aug 9, 2023

aibaars commented on Sep 15, 2023

amotl commented on Sep 17, 2023

aibaars commented on Sep 18, 2023

9 remaining items

amotl commented on Nov 14, 2024

ffissore commented on Feb 11, 2025

RafaelAPB commented on Jun 8, 2026

aibaars commented on Jun 8, 2026

RafaelAPB commented on Jun 9, 2026

ThrawnCA commented on Jun 9, 2026

jsoref commented on Jun 9, 2026

jay-depot commented on Aug 15, 2026

chrisc-onaorg commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions