Keep CodeQL Scanning When Your Runner Changes
A code-scanning policy can remain enabled while the analysis it depends on no longer completes. CodeQL 2.27.2 makes that risk immediate for teams upgrading Apple build runners or maintaining custom Go queries.
The release deserves an upgrade gate built around scan continuity. New detections matter only after the runner creates a valid database, the queries execute and the result reaches the place where defenders review it.
The break is in traced compiled-language builds
GitHub’s 9 October announcement says compiled-language CodeQL autobuild and manual modes are unsupported in these environments:
| Runner combination | Traced autobuild and manual status |
|---|---|
| macOS 27 with any Xcode version | Unsupported |
| macOS 26 with Xcode 27 | Unsupported |
| At most macOS 26 with Xcode 26 | GitHub’s stated path for these modes |
These limits apply to compiled-language traced analysis, so they do not establish that every CodeQL scan on macOS 27 fails. GitHub says it is improving build mode none on macOS. Confirm the language and setup before treating that mode as a replacement.
The repository setting is weak evidence by itself. The useful evidence is a completed run with the expected language database, query execution and uploaded result. A runner-image upgrade can change those outcomes without anyone editing the repository’s security policy.
BlackTree’s earlier coverage of the GitHub Actions macOS 14 runner brownout showed why platform transitions need an inventory before a cutoff. CodeQL 2.27.2 adds a different check: identify which jobs depend on traced build prerequisites before changing macOS or Xcode.
Custom Go queries need their own upgrade gate
The detailed 2.27.2 changelog records a breaking change in the Go control-flow graph library. The shared CFG adds nodes for constructs including assignments, parameters, results, range statements and deferred calls. It excludes nodes that are unreachable from the entry point and changes edges, locations, textual representations and basic-block boundaries.
Several API details also move. BasicBlocks::Cfg is removed, IfStmt.getCond is deprecated, and some predicate return types change. A custom query can therefore compile differently, fail to compile or return a different result set after the library upgrade.
Treat those changes as a testable migration. Compile each custom Go query pack against 2.27.2, run its tests, and compare expected results on representative databases. GitHub’s query-pack reference documents dependency locking and compatibility considerations that help make that comparison reproducible.
Do not accept a clean result count without checking the path that produced it. A drop to zero findings can mean cleaner code, a changed control-flow model, a failed custom query or a missing scan. Those outcomes require different responses.
Measure completed protection, not configured protection
BlackTree recommends adding five checks to the release gate:
- Map the build path. Record the runner operating system, Xcode version, language and CodeQL build mode for every compiled-language job.
- Exercise the next runner image. Run a representative branch through the intended macOS and Xcode combination before changing the default image.
- Test custom Go packs. Compile and execute them with 2.27.2, then review result additions, removals and location changes.
- Watch the whole scan. Alert on missing databases, failed query execution, absent uploads and stale last-success timestamps, as well as findings.
- Keep a supported fallback. Preserve a runner using at most macOS 26 and Xcode 26 for traced compiled-language analysis until an alternative path has passed the same checks.
This is the same validation principle BlackTree applied to GitHub advisory provenance: a capability being present does not prove that the operational data is complete. For CodeQL, the acceptance evidence is an expected scan reaching completion with comparable coverage.
Hosted and self-managed rollouts have different clocks
GitHub says new CodeQL versions are automatically deployed to code scanning on github.com. GitHub Enterprise Server does not receive 2.27.2 on the same clock. A future GHES release will include it, while administrators on older GHES versions can choose a manual CodeQL upgrade.
That difference belongs in change records. A test against github.com does not prove that a GHES appliance is already using the same library, and a manually upgraded appliance may move ahead of its bundled version. Record the actual CodeQL version with the scan result.
Wider coverage is useful after continuity is proved
CodeQL 2.27.2 expands analysis across several languages and frameworks. It adds C++ regular-expression parsing, a Comdb2 SQL-injection model, Go support for the github.com/coder/websocket import path, Rust TLS flow summaries, and improved Hapi request tracking. It also lets the unpinned GitHub Actions query remove selected owners from its trusted set.
Those changes can produce useful findings. GitHub does not publish a measured detection uplift, an affected-repository count or a failure rate for this release. Teams should report their own result deltas after confirming that the same repositories, languages and query suites completed successfully.
Source timing and limits
The detailed CodeQL changelog dates version 2.27.2 to 7 October. GitHub published the product announcement on 9 October. BlackTree observed both pages on 10 October; neither exposed a separate revision date.
This is a defensive tooling change, with no CVE or exploitation claim. The immediate decision is whether the next runner and query-library upgrade preserves a complete, observable scan.
