CodeQL: Query-based Static Analysis

• CodeQL is a query-based static analysis framework that transforms source code into a relational database, enabling data-flow and semantic queries for vulnerability detection.
• Its architecture uses language-specific trap extractors and incremental database updates, supporting whole-codebase analysis and seamless CI integration.
• The integration of LLMs for refining and synthesizing queries underscores CodeQL’s evolving role in advanced, scalable program analysis.

CodeQL is a query-based static analysis framework used in GitHub Code Scanning and GitHub Advanced Security. Across the studies surveyed here, it is described as extracting source code into a relational or fact database, then evaluating declarative QL queries—often with data-flow reasoning—over that representation to emit alerts tied to code locations. It has been applied in research and practice to Python, Java, C/C++, Go, JavaScript, Ruby, and C#, and it is routinely used for whole-repository or whole-codebase analysis rather than local snippet inspection (Ferrand et al., 8 May 2026, Szabó, 2023, Nazari et al., 10 May 2026).

1. Query language, database model, and execution pipeline

CodeQL analyses are written in QL, a declarative language that compiles internally to DIL and then to lower-level relational algebra. In the production pipeline described for pull-request feedback, repository source code is first processed by language-specific trap extractors, which generate trap files; a trap importer then builds the extensional database, and the CodeQL compiler and solver derive the intensional database from which query results are produced (Szabó, 2023). Other studies describe the same core mechanism more abstractly: CodeQL converts code into a fact database containing syntactic and semantic relations, then evaluates QL queries over that database, often through data-flow reasoning (Andersson et al., 27 Apr 2026).

This execution model is central to why CodeQL is used as a whole-codebase analysis substrate. In large-repository settings, such as those targeted by Merlin, the appeal is precisely that CodeQL supports expressive semantic queries over codebases that may span millions of lines of code and thousands of files, where lexical tools such as grep are inadequate and direct LLM-only reasoning is constrained by context limits (Nazari et al., 10 May 2026). In the longitudinal CodeQL study, each version of the tool is operationalized not merely as a CLI binary but as a versioned combination of the CLI, query packs, and underlying libraries, which underscores that CodeQL behavior is inseparable from its shipped query suites and LLMs (Ferrand et al., 8 May 2026).

The same database-centric architecture also explains CodeQL’s use in CI and review workflows. Production CodeQL analyses are designed to surface findings during pull-request review, and this deployment context motivates systems work on incrementalization so that updates can be processed proportionally to code changes rather than by full re-analysis from scratch (Szabó, 2023).

2. Analytic abstractions and query styles

The dominant analytic idioms built on CodeQL are relational pattern matching, data-flow analysis, taint analysis, and control-flow reasoning. In the IRIS formulation, CodeQL is treated as the engine that, given a project graph together with source and sink specifications and a CWE-specific query, returns the set of taint paths satisfying the analysis. That framing is representative of a large body of work in which CodeQL is less a monolithic scanner than a programmable substrate for source–sink reasoning (Li et al., 2024).

Several domain analyses show how flexible this substrate is. RLC# implements a modular resource-leak checker for C# using CodeQL intraprocedural local data flow, then compensates for missing interprocedural precision with method-boundary specifications such as MustCall, Owning, EnsuresCalledMethods, CreateMustCallFor, and MustCallAlias. Its leak condition is expressed as a combination of local flow, alias predicates, and a backward control-flow check that determines whether a resource can reach method exit without disposal (Gharat et al., 2023). A different line of work encodes thread-safety of Java classes in CodeQL by checking three sufficient properties: no escaping state, safe publication, and correct synchronization of conflicting accesses on the same monitor. That analysis relies on CodeQL classes for field accesses, recursive intraclass reachability from public methods, and dominance/post-dominance conditions around lock/unlock regions (Jåtten et al., 2 Sep 2025).

CodeQL has also been used as a substrate for domain-specific static rule packs. In the Cosmos SDK study, the original cosmos-sdk-codeql rules were criticized for relying on inconsistent package blacklists; the refactored rules instead introduced a ConsensusCriticalFuncDecl abstraction to scope analysis to consensus-critical code. This shift from blacklist filtering to semantic scoping substantially improved precision and removed duplicates, illustrating a broader CodeQL design lesson: high-value results often depend more on accurate semantic scoping than on broad repository-wide matching (Surmont et al., 2023).

3. Empirical effectiveness, actionability, and system evolution

The most extensive longitudinal evaluation applies 114 versions of CodeQL to 3,993 CVEs from 1,622 repositories across six languages, amounting to more than 20 billion lines of code analyzed. In that study, CodeQL identified 171 CVEs in total, and 83 of those were detectable by a CodeQL version released before the vulnerability was fixed. The same study also examines actionability and finds that, for 50% of the 171 detections, more than 50% of findings in the vulnerable file are located in the vulnerable location; however, detections are not monotonic across versions, as 21 CVEs were no longer detected following a version change and 17 were never redetected (Ferrand et al., 8 May 2026).

Those results portray CodeQL as practically useful but version-sensitive. The same paper shows that updates can change the utility–cost frontier of the tool by shifting both the number of detected vulnerabilities and the alert burden, and it identifies query-pack evolution—not only analysis-engine evolution—as a source of changing coverage (Ferrand et al., 8 May 2026). This is a distinctive property of CodeQL as a living, versioned query ecosystem rather than a fixed algorithm.

Performance work on incrementalization reinforces the deployment relevance of this perspective. A prototype incremental solver for production CodeQL analyses demonstrates update times proportional to change size, with fully incremental updates typically at or below about 15 seconds for commits affecting up to 1000 lines and hybrid updates below one minute. Although the prototype remained memory-heavy, the result establishes that sophisticated CodeQL analyses with inter-procedural and context-sensitive features still admit useful reuse across repository revisions (Szabó, 2023).

4. Representative applications beyond generic vulnerability scanning

A notable feature of the literature is the breadth of problems encoded in CodeQL. The “CodeQueries” dataset was constructed from 52 public CodeQL Python queries and turned those analyses into semantic question-answering instances over file-level code, with 133,456 query-file examples overall. The underlying premise is that CodeQL queries already capture semantic developer questions about correctness, reliability, maintainability, and security, and can therefore serve as a benchmark for neural models that aim to approximate symbolic program analysis (Sahu et al., 2022).

In software engineering studies, CodeQL has been used to analyze autonomous driving systems, blockchain frameworks, concurrency contracts, and resource management. In the ADS study on Autoware, AirSim, and Apollo, 37 CodeQL queries were run across multiple versions, and the detected weaknesses were dominated by CWE-190 at 59.6% and CWE-20 at 16.1%; the authors also tracked persistence of findings across releases and reported developer-confirmed fixes for selected issues (Cheng et al., 27 Feb 2025). In the Java thread-safety study, CodeQL queries were evaluated on the top 1000 GitHub repositories, covering 3,632,865 Java classes, of which 1,992 were annotated @ThreadSafe; the queries produced 3,893 alerts and ran in under two minutes for repositories up to 200k lines of code, 20k methods, 6000 fields, and 1200 classes (Jåtten et al., 2 Sep 2025). In RLC#, CodeQL-based leak checking over 2.53M lines of C# found 24 true leaks with 37 false positives, versus 3 true positives and 318 false positives for a naive existing CodeQL query (Gharat et al., 2023).

These case studies suggest that CodeQL functions as a general-purpose program-analysis workbench. The same relational/query infrastructure has been used for bug finding, semantic QA datasets, concurrency reasoning, nondeterminism detection, and domain audits of large evolving systems, with the specific semantics coming from the query or specification layer rather than from a fixed predefined analysis.

5. LLM-assisted and neuro-symbolic extensions

A major recent trend is to keep CodeQL as the symbolic backend while using LLMs to generate, refine, or contextualize CodeQL analyses. Merlin integrates an LLM with CodeQL to answer free-form developer questions over large repositories. Its architecture combines retrieval-augmented iterative CodeQL generation with a self-test/debugging mechanism based on assistive queries that generate concrete witnesses for semantic flaws in candidate queries. In a within-subject user study, access to Merlin increased task accuracy by an average of 3.8× and reduced completion time by 31% (Nazari et al., 10 May 2026).

Other systems focus on vulnerability discovery by synthesizing new CodeQL models or rules. IRIS treats CodeQL as the taint-analysis backend but augments it with LLM-inferred source and sink specifications; on CWE-Bench-Java, stock CodeQL detected 27 of 120 vulnerabilities, whereas IRIS with GPT-4 detected 69 (Li et al., 2024). QLPro uses CodeQL simultaneously as extraction engine, execution target, and baseline: official CodeQL rules detected 24 of 62 confirmed vulnerabilities in JavaTest, while QLPro detected 41 and additionally found 6 previously unknown vulnerabilities, 2 confirmed as 0-days (Hu et al., 30 Jun 2025). QLCoder goes further by synthesizing CodeQL vulnerability queries directly from CVE metadata; on 176 Java CVEs across 111 projects, it produced correct queries for 53.4% of CVEs, compared with 10% for plain Claude Code (Wang et al., 11 Nov 2025).

Several systems specialize this pattern for difficult language domains. SemTaint augments CodeQL for JavaScript/npm by extracting package-specific sources, sinks, missing call edges, and library flow summaries; it reports detecting 106 of 162 vulnerabilities previously undetectable by CodeQL (Ghebremichael et al., 15 Jan 2026). MemHint augments CodeQL for C/C++ memory-leak detection by discovering custom allocators and deallocators, validating the inferred summaries with Z3, injecting them into CodeQL’s allocationFunctionModel and deallocationFunctionModel, and then filtering warnings by path feasibility; MemHint-augmented CodeQL found 42 bugs compared to 19 for vanilla CodeQL (Huang et al., 28 Mar 2026). QRS, operating on Python packages, uses autonomous agents to generate CodeQL queries, review results, and sanitize findings; against 39 validated vulnerabilities in the Top100 PyPI study, the stock CodeQL ruleset detected 0 while QRS detected all 39 (Tsigkourakos et al., 10 Feb 2026).

Taken together, these systems reframe CodeQL from a fixed scanner into a programmable symbolic backend for agentic analysis. The recurring pattern is consistent: the LLM contributes semantic hypothesis generation, specification extraction, or query synthesis; CodeQL contributes whole-codebase execution semantics, scalable relational reasoning, and path reporting.

6. Limitations, controversies, and open directions

The literature is equally clear that CodeQL should not be treated as a universally sufficient oracle. In a human-validated study of 1,080 GPT-4o-generated Python code samples, CodeQL classified 80% of samples as secure whereas human review judged 61% secure; its per-sample agreement with ground truth was 61%, with recall 0.34, precision 0.67, and F-measure 0.45. That paper’s conclusion is that CodeQL is useful as a component signal but unreliable as the sole evaluator of code security (Firouzi et al., 5 Feb 2026). A broader secure-code-generation study makes a similar point from another angle: CodeQL often reported nearly 100% security scores on Python benchmarks where other analyzers found many issues, and the authors explicitly state that CodeQL can miss more than 20% of vulnerabilities in generated code (Dai et al., 18 Mar 2025).

Domain specificity is another recurring limitation. In cryptographic Rust, the off-the-shelf rust-security-extended.qls suite produced only two findings across 56 compiled samples, both judged false positives, जबकि a crypto-specific analyzer found vulnerabilities in 57.1% of the same compiled population; the authors therefore treat CodeQL as a useful negative control rather than a sufficient validator for AEAD misuse (Elsayed et al., 29 Apr 2026). In Go cryptographic API misuse detection, built-in CodeQL support covered 5 of 14 misuse classes and produced 256 detections across 328 projects; the study highlights CodeQL’s semantically rich handling of some cases, such as SSH host-key validation and JWT verification, but concludes that it is insufficient as a standalone detector when broad out-of-the-box coverage is required (Andersson et al., 27 Apr 2026).

A plausible implication is that CodeQL’s limiting factor is often not the underlying relational engine but the availability, specificity, and maintenance of models and queries. This interpretation is explicitly advanced in work such as IRIS, QLPro, MemHint, SemTaint, and QLCoder, all of which keep CodeQL as the execution substrate while attacking the bottleneck of specification engineering (Li et al., 2024, Hu et al., 30 Jun 2025, Huang et al., 28 Mar 2026, Ghebremichael et al., 15 Jan 2026, Wang et al., 11 Nov 2025). Another plausible implication is that future CodeQL research will continue to move in two directions at once: tighter developer-facing deployment mechanisms, such as incremental evaluation for pull requests, and richer query/model generation mechanisms, increasingly driven by retrieval, language servers, counterexample-guided repair, and neuro-symbolic validation (Szabó, 2023, Wang et al., 11 Nov 2025).