CodeQL 2.26.4 で Actions の防御判定が厳格化、コードを変えずにアラートが増えうる

コードを一行も変えていないのに、code scanning のアラート数が動く。GitHub Actions のワークフローを解析しているリポジトリと、Rust のデータフロー系クエリを使っているリポジトリでは、2026年9月3日付の GitHub Changelog に載った CodeQL 2.26.4 がその原因になりうる。github.com の code scanning には CodeQL の新版が自動で配られるので、有効化の操作は要らないし、見送る操作もない。

変更の向きは「防御として数えていたものを、数えなくなる」だ。誤検知を減らす変更も同じリリースに入っているが、Actions については検出が増える側の記述が三つ並ぶ。増える理由を先に見て、そのあとで各言語の細かい変更と GHES の扱いを確認する。

Actions で「防御あり」と判定されなくなる三つの条件

changelog の GitHub Actions の項は三つの箇条で、いずれも ControlCheck か actions/unpinned-tag の判定に関わる。順に見る。

イベントが持たないフィールドの検査

最初に挙がっているのは、イベントペイロードから読んだ actor フィールドの検査だ。例として github.event.pull_request.user.login が示されている。この種の検査は、書いてあれば防御として扱われていた。2.26.4 からは、そのフィールドを実際に持つイベントに対してだけ防御として数える。

複数のイベントで起動するワークフローで、一部のイベントにしか存在しないフィールドを条件にしている場合、残りのイベントでは条件が空振りする。CodeQL はそれを防御なしと見なすようになった。この変更で ControlCheck クラスを使うクエリのアラートが増える可能性がある、と changelog は明記している。

reusable workflow の可変参照

actions/unpinned-tag クエリは、reusable workflow への可変参照も検出対象に加えた。これまでの検出対象に、呼び出し先のワークフローが加わる形だ。タグやブランチ名のように後から差し替えられる参照が、固定されていないものとして報告される。組織内の reusable workflow をブランチ名で呼んでいるなら、ここで新しいアラートが出うる。

environment を sanitizer から外す

三つ目は EnvironmentCheck だ。models-as-data のモデルとして指定できるようになった。environment による保護を sanitizer として十分と見なさない設定にすると、ControlCheck を使うクエリの結果が増えうる、と changelog は書いている。

既定の判定が変わったのではなく、指定の手段が増えた、と読める。ただしこれは changelog の文面からの推測で、models-as-data でモデルをどう書くかは changelog に載っていない。

Rust はアラートが閉じて、別のアラートとして開き直す

Rust のデータフロー系クエリは、アラートの位置が実際の source と sink のノードに基づくようになった。位置が変わったアラートは新規として現れ、以前のアラートは閉じる。件数の増減ではなく入れ替わりなので、ダッシュボードだけ見ると新規が急に増え、同じ数だけ解決したように映る。

トリアージの記録をアラート単位で持っているチームには、ここで影響が出うる。旧アラートに付けた却下理由やコメントが新しい位置のアラートに引き継がれるかは changelog に書かれていない。引き継がれない前提で確認した方が安全だ。

言語ごとの変更は対応追加と誤検知減が中心

Actions と Rust 以外は、対応範囲の追加と精度の調整だ。

言語	変更
Go	Go 1.27 に対応
Java/Kotlin	Spring R2DBC の DatabaseClient と R2DBC SPI に SQL インジェクションの sink モデルを追加。引数が CharSequence（String や StringBuilder）のとき、String.valueOf(Object) の呼び出しを通って taint が伝播する
JavaScript/TypeScript	正規表現の d フラグと、React Native Worklets の 'worklet' ディレクティブに対応
Python	list.extend と list.insert を通る taint flow を追加。既存の list.append と同じ扱い
C#	cs/web/missing-token-validation が、antiforgery ミドルウェア使用時の有効な ASP.NET Core RequireAntiforgeryToken 属性を認識。cs/virtual-call-in-constructor は nameof 式内の仮想メンバーを呼び出しではないとして報告しない。cs/useless-cast-to-self と cs/simplifiable-boolean-expression は build-mode: none のデータベースで誤検知が減る

出典：GitHub Changelog「CodeQL 2.26.4 improves GitHub actions security detections」（2026年9月3日付）

Java/Kotlin と Python の行は、解析が追う経路を足す変更だ。R2DBC の DatabaseClient を SQL インジェクションの sink に加え、list.extend と list.insert を list.append と同じ扱いで追う。

GHES は次のリリースまで据え置き

github.com の code scanning には新版が自動で配られる。GHES には将来のリリースで入る、と changelog は書いているが、どのバージョンかは示されていない。古い GHES で先に取り込みたければ、CodeQL のバージョンを手動で上げる手段がある。

github.com と GHES の両方でスキャンしているなら、GHES 側が追いつくまで同じワークフローでも結果が食い違いうる。片方だけアラートが出たときは、まず CodeQL のバージョン差を疑える。

次のスキャン結果を見るときに

対応が要るのは、Actions のワークフローで github.event 配下の actor フィールドを条件に使っている箇所と、reusable workflow をタグやブランチで呼んでいる箇所を持つリポジトリだ。順番は次で足りる。

1. 新規アラートを ControlCheck 系と actions/unpinned-tag で分ける。前者は条件が効かないイベントを洗い出し、後者は参照を固定するかを判断する。
2. Rust の新規アラートは、閉じた旧アラートと突き合わせる。同じ経路で位置だけ変わったと確認できたものは、旧アラートの判断を引き継ぐ。
3. コード外の統制でリスクが抑えられていると判断したものは、8月20日に追加された Mitigated の却下理由で閉じる。Won’t fix と分けて記録でき、例外承認のプロセスと揃えやすい。

このリリースが変えるのは CodeQL の判定だ。アラート数を指標にしている組織では、9月の数字が理由なく跳ねたように見える。跳ねた理由がこのリリースだと分かっていれば、それで済む。