CodeQL and Semgrep have spent the last few years converging on the same problem from opposite directions, and the choice between them is now less about capability and more about how your security and engineering teams want to spend their time. Both produce real findings on real code. The differences that actually matter at evaluation time are subtler than the marketing pages suggest.
How do their analysis models compare?
CodeQL builds a relational database of your codebase and runs declarative queries against it. The model is powerful, with full inter-procedural and inter-file taint tracking that handles complex data flows other tools miss. The cost is build time: extracting a CodeQL database for a medium-sized Java or C++ repository takes 15 to 45 minutes, and incremental analysis is limited. Semgrep operates at the AST level with pattern matching plus a lighter dataflow engine. Analysis is fast, often under a minute on the same repo, but the dataflow depth is shallower. The Semgrep Pro engine has closed much of the gap since 2024, particularly for cross-function taint, but it has not matched CodeQL's depth on the hardest queries.
The practical implication is that CodeQL finds bugs Semgrep misses, and Semgrep finds findings inside the developer feedback loop while CodeQL is still building. Both effects are real and matter for different reasons.
How do they compare on rule authoring?
This is where the philosophies diverge most. CodeQL queries are written in QL, a declarative logic language that takes serious engineering investment to learn. A skilled CodeQL author can express almost anything, but you will not have many of them. Semgrep rules are written in YAML with pattern syntax that is closer to grep, and almost any engineer can author a useful rule in an afternoon. The Semgrep community library reflects this: tens of thousands of rules, with quality ranging from excellent to questionable, against the smaller but generally higher-signal CodeQL standard library.
For an appsec team that wants to write custom rules for internal frameworks, Semgrep is dramatically faster to productive output. For a team that wants depth on specific high-stakes queries, CodeQL's expressive power earns its learning curve. Most mature programs end up running both, with custom Semgrep rules for the long tail and CodeQL for the handful of queries that justify the investment.
What does performance look like in CI?
On a representative monorepo, Semgrep completes a full scan in 2 to 5 minutes and incremental scans in seconds, which means it fits inside the normal PR feedback loop. CodeQL on the same repository takes 25 to 60 minutes for a full scan and does not offer true incremental analysis, so it typically runs nightly or on merge to main rather than per-PR. GitHub's hosted runners absorb some of the CodeQL cost on public projects, but private monorepos quickly outgrow them.
This timing difference shapes the developer experience more than any single technical feature. Semgrep findings show up in the PR while context is fresh. CodeQL findings show up the next morning, attached to a build the developer has already moved past. Both can be valuable, but they require different remediation workflows.
How does noise compare on real code?
On the 12 codebases we ran in our 2026 benchmark, Semgrep with the default community ruleset produced roughly 3x more findings than CodeQL with its standard query suite, and Semgrep's false positive rate ran 28% versus CodeQL's 11%. Tuning closes much of that gap: a curated Semgrep ruleset focused on high-confidence patterns gets the false positive rate under 15% without losing much coverage on the bugs that matter.
The takeaway is that out-of-the-box Semgrep is louder, and tuned Semgrep is competitive on signal-to-noise with CodeQL. The tuning effort is real and ongoing. Teams that adopt Semgrep without committing to rule curation tend to end up with developer fatigue and ignored findings within a quarter.
Which one should you pick?
If you are starting from zero, Semgrep is the easier on-ramp and will produce useful findings within a week of installation. If your codebase contains memory-unsafe languages or has known patterns of complex taint flow, CodeQL earns its setup cost. For most organizations, the right answer is Semgrep in the PR loop plus CodeQL on a slower cadence for the queries it uniquely handles well, accepting the operational cost of running two tools. The license economics work out reasonably if you use Semgrep OSS plus a paid CodeQL license rather than paying both vendors at scale.
The wrong answer is to pick one and ignore the gap it leaves. Both tools have real coverage holes, and a SAST program built on one engine will miss findings the other would catch.
How Safeguard Helps
Safeguard ingests findings from both CodeQL and Semgrep alongside SCA, container, and runtime signals, and Griffin AI deduplicates and prioritizes across all of them so developers see one ranked list rather than three tool dashboards. Reachability analysis on the SCA side complements SAST taint analysis: a CodeQL or Semgrep finding in dead code gets deprioritized automatically when our reachability engine confirms the path is unreachable from any exposed entry point. Policy gates can require CodeQL or Semgrep coverage at specific severity thresholds before merging, and TPRM scores upstream dependencies for SAST hygiene so you can see which suppliers actually run static analysis on the code you depend on.