CodeQL の autobuild・manual build は macOS 27 と Xcode 27 で非対応

macOS ランナーでコンパイル言語を CodeQL にかけているなら、OS と Xcode を上げる前に確認が要る。GitHub が2026年10月9日に公開した CodeQL 2.27.2 の changelog によると、macOS 27 では Xcode のバージョンを問わず、また macOS 26 でも Xcode 27 を選んだ場合、コンパイル言語の autobuild と manual build の両モードがサポートされない。これらのビルドモードを使い続けるなら、macOS 26 と Xcode 26 までに留めるよう案内されている。

理由も changelog に書かれている。macOS 27 と Xcode 27 のリリースで、Apple が x86-64/arm64 のマルチアーキテクチャバイナリを同梱しなくなった。CodeQL は traced analysis にこのバイナリを必要とするため、ビルドを伴うモードが成り立たなくなる。

解析が止まる macOS と Xcode の組み合わせ

macOS	選択している Xcode	autobuild / manual build（コンパイル言語）
macOS 27	どのバージョンでも	サポートされない
macOS 26	Xcode 27	サポートされない
macOS 26	Xcode 26	使える（案内されている上限）

出典：GitHub Changelog「CodeQL 2.27.2 improves C++, Go, Rust, and JavaScript analysis」の macOS 27 compatibility 節

見落としやすいのは 2 行目だ。ランナーの OS が macOS 26 のままでも、ジョブが Xcode 27 を選んでいれば同じ制約に当たる。ワークフローを点検するときは、ランナーのラベルと、ジョブが使う Xcode の両方を見る必要がある。changelog の言い方は「at most macOS 26 and Xcode 26」で、OS と Xcode の両方に上限が付いている。

none への切り替えは言語と解析範囲の確認が必要

GitHub は、この制限を和らげるために macOS での build mode none のサポート改善に取り組んでいると書いている。ただし時期も、どの言語で改善されるかも changelog には書かれていない。autobuild・manual を維持する場合、発表が示す対応は OS と Xcode の両方を26系以下に留めることだ。

非対応の対象は指定の OS・Xcode 上での autobuild・manual であり、none が全言語で使えないという発表ではない。自分の言語で none を利用できるか、必要な解析範囲を保てるかは、この発表だけでは判断できない。モードを変更する前に言語別の対応と解析範囲を確認する必要がある。

2.27.2 で増えた解析対象

macOS の件とは別に、言語ごとのモデル追加がまとまって入っている。

• C/C++ では、std::regex で ECMAScript 文法を使う正規表現を CodeQL が解析するようになった。Comdb2 C API の SQL インジェクション sink と、Bloomberg BDE のコーデックやバイトストリーム逆シリアライザの flow summary も加わった
• Go では、nhooyr.io/websocket に加えて github.com/coder/websocket のインポートパスをモデル化した
• Rust では、extractor が AnyAttr と DocComment クラスに対応し、await と組み合わせた async ブロックのデータフローが改善された。native-tls、async-native-tls、tokio-native-tls の flow summary も入った
• JavaScript/TypeScript では、Workflow SDK の "use workflow" と "use step" ディレクティブを認識し、Hapi のルートハンドラとリクエスト入力の追跡が、独自のルート登録ヘルパーや高階関数を通しても効くようになった

クエリ側では、C# の cs/web/missing-x-frame-options が ASP.NET Core のレスポンスヘッダと CSP の frame-ancestors をクリックジャッキング対策として認識する。cs/web/xss は、Razor のタグヘルパー属性値で WriteLiteral によって書かれたものを XSS sink として扱わなくなった。GitHub Actions の actions/unpinned-tag では、信頼済みオーナーの集合から !github のように ! を付けたエントリで除外でき、ファーストパーティのオーナーでもピン留めされていないタグを報告させられる。

スクリプトと自作クエリが影響を受ける箇所

CodeQL CLI を直接呼んでいるジョブは、標準エラーの出力を確認しておきたい。エラーと警告のメッセージに ERROR: と WARNING: の接頭辞が付くようになった。ログや SARIF などの構造化出力は変わらないので、SARIF を読んでいる処理には影響しない。標準エラーの文字列を照合しているスクリプトだけが対象になる。

データ拡張の YAML では、符号付き 32 ビットの範囲外の整数が拒否されるようになった。これまでは一部の値が黙って切り詰められていた。クエリスイートの不正な qlpack: と from: は、クラッシュではなく明確なエラーとして報告される。

Go の自作クエリを持っているチームには破壊的変更がある。Go の制御フローグラフが共有 CFG ライブラリに移り、ノード、エッジ、位置、基本ブロックの境界が変わった。BasicBlocks::Cfg は削除され、IfStmt.getCond は IfStmt.getCondition を優先して非推奨になり、IfStmt.getThen と LoopStmt.getBody の戻り値の型は Stmt になった。以前の表現に依存するクエリは書き換えが要るかもしれない。

github.com と GHES での反映

github.com の code scanning には、新しい CodeQL バージョンが自動でデプロイされる。GHES には今後のリリースで入り、それより古い GHES では CodeQL を手動で更新できる。2.27.2 の時点で、Default スイートは 170 の CWE をカバーする 498件のセキュリティクエリを実行し、Extended スイートはさらに 32 の CWE に対する 131件のクエリを加える。CodeQL のプラットフォーム別バンドルの話は プラットフォーム別バンドルと Linux arm64 対応の記事 で扱った。

macOS ランナーで autobuild か manual build を使っているなら、当面の対応は二つになる。ランナーのラベルとジョブの Xcode 選択が 26 系を超えていないかを確認し、その二つのビルドモードを維持したまま macOS 27 や Xcode 27 へ移行しない。none へ切り替えられるかは、言語と解析範囲を別に確認して判断する。