gitdash

CodeQL 2.27.2: Check Go Custom Queries Before Upgrading

CodeQL 2.27.2 improves C++, Go, Rust, and JavaScript analysis, but its rewritten Go control-flow graph can affect custom queries. Here is a practical upgrade checklist.

A static analysis path moving from source code through a security review gate with highlighted findings

CodeQL 2.27.2 is available with analysis improvements for C++, Go, Rust, and JavaScript/TypeScript. The release is mostly a normal upgrade for teams using GitHub's standard queries. It deserves more care if you maintain custom Go queries or libraries because CodeQL has rewritten the Go control-flow graph implementation. The official CodeQL changelog calls this a breaking change for code that depends on specific CFG nodes, edges, locations, textual representations, or basic-block boundaries.

The useful upgrade path is not to freeze on the old bundle forever. Run the new version against a small set of representative repositories, test custom packs separately, and compare both compilation and findings before changing every runner.

The Go CFG change is the main compatibility risk

CodeQL now builds the Go control-flow graph with the shared CFG library. The graph includes more accurate nodes for assignments, parameters, results, range statements, and deferred calls, and only includes nodes reachable from the entry point. That can change how a custom query walks or describes a Go function even when the application source has not changed.

  • `BasicBlocks::Cfg` has been removed. `BasicBlock` uses the shared basic-block implementation directly.
  • `ControlFlow::EntryNode` and `ControlFlow::ExitNode` now provide the specific entry and exit types.
  • `IfStmt.getCond` is deprecated in favor of `IfStmt.getCondition`.
  • Several older IR instruction classes were removed or consolidated.

If your Go pack asserts exact CFG structure, update the pack to use semantic predicates and the current library API where possible. Tests that snapshot node counts or textual graph output are especially likely to fail. That failure is useful: it shows where the query depends on representation rather than behavior.

What improves in the language libraries

The release also adds coverage that can improve results without changes to your workflow files. The practical items are:

  • C/C++ gets a parser for ECMAScript regular expressions used with `std::regex`.
  • Go models the `github.com/coder/websocket` import path alongside the existing websocket model.
  • Rust adds extractor support for `AnyAttr` and `DocComment`, plus better data flow for async blocks using `await`.
  • JavaScript and TypeScript recognize Workflow SDK directives and improve Hapi route-handler and request-input tracking.

Small CLI changes can affect automation

CodeQL 2.27.2 now prefixes plain-text messages written to standard error with `ERROR:` or `WARNING:`. Structured output such as SARIF and stored diagnostics keeps its severity data. If a wrapper parses human-readable stderr, test it instead of assuming the output is unchanged.

  • Invalid `qlpack:` or `from:` values in query suites now produce clearer user-facing errors.
  • YAML data-extension integers outside the signed 32-bit range are now rejected instead of being truncated or accepted.

A practical upgrade plan

  1. Inventory the CodeQL CLI, CodeQL Action, query packs, and any local bundles used by your runners.
  2. Run the default and extended suites on representative C++, Go, Rust, and JavaScript repositories. Save the SARIF and logs as a baseline.
  3. Compile and test custom packs separately, with extra attention to Go CFG and IR APIs.
  4. Review new and disappeared findings as separate changes. A count difference is a prompt to inspect the rule and code, not proof of a regression.
  5. Roll out to the remaining runners after stderr parsers, query packs, SARIF ingestion, and alert triage have passed.

Pin deliberately, then schedule the next upgrade

Pinning a known CodeQL version can buy time while a custom pack is repaired, but it should have an owner and an expiry date. The language and query improvements in 2.27.2 are useful only after the bundle is part of the normal test path. Treat the Go CFG work as a compatibility task, not a reason to skip the release indefinitely.

For teams using only GitHub's standard CodeQL queries, start with a staged runner upgrade and compare alerts. For teams with custom Go analysis, start with the pack tests. The release is valuable, but the control-flow graph change is the part to make visible before it reaches every repository.