CodeQL 2.25.6が公開：Swift 6.3.2、C# 14/.NET 10、GitHub Actions再検出の確認ポイント

このテーマをもう少し広げて見るなら、GitHub code scanningが非アクティブリポジトリの30日周期スキャンに対応：default setupと管理者の確認ポイント と Copilot CLIに/security-reviewが公開プレビュー：CodeQL・Secret scanningと併用する確認ポイント も合わせて確認してください。CodeQLの更新を、default setupを使う組織の継続スキャン運用まで広げて確認できます。

3行まとめ

対象の拡大

Swift 6.3.2、C# 14、.NET 10など、新しい言語やランタイムへの対応が進みました。

検出の変化

Actions、Avro、scanf_s系、機微データ検出の改善により、同じコードでもアラートの見え方が変わる可能性があります。

確認の入口

CodeQL version、query ID、alert state、alert location、dismiss reasonを分けて見ます。

アラート件数の増減だけで判断せず、解析バージョンとクエリ単位で差分を確認します。

GitHubは2026年6月5日、CodeQL 2.25.6の更新をGitHub Changelogで告知しました。CodeQL公式changelog上のリリース日は2026年6月4日で、Swift 6.3.2対応、C# 14/.NET 10のフルサポート、GitHub Actionsクエリ変更、複数言語の機微データ検出改善が中心です。

今回の更新は、対象リポジトリで新しい問題が突然混入したという話だけではありません。解析モデル、データフロー、alert location、ヒューリスティックが変わるため、コードを変更していなくてもCode scanning alertsの見え方が変わる可能性があります。

まず見るべき場所は、対象言語、query ID、CodeQLバージョン、新規か再オープンか、過去のdismiss reasonです。GitHub.comのcode scanning利用者と、GitHub Enterprise Serverや外部CIでCodeQL CLIを固定しているチームでは、確認順が少し変わります。

CodeQL 2.25.6で何が変わったのか

1. 1言語対応

   Swift 6.3.2、C# 14、.NET 10により、新しい構文やランタイムを含むコードを解析しやすくなります。

2. 2モデル追加

   Java/KotlinのAvro、C/C++のscanf_s系など、データの入口や出口を追う材料が増えます。

3. 3クエリ改善

   GitHub Actionsや機微データ検出の変更で、既存コードのリスクが別の形で表示されることがあります。

4. 4差分確認

   新規混入、再オープン、表示位置変更、誤検知の減少を分けて確認します。

CodeQLはコードをデータベース化してクエリで検出するため、モデルやヒューリスティックの変更でも結果が変わります。

CodeQLは、GitHub code scanningの静的解析エンジンです。GitHub Docsは、CodeQLを使うとコード内の脆弱性やエラーを特定でき、その結果がGitHub上のcode scanning alertsとして表示されると説明しています。つまり今回の更新は、単なるCLIの細かなバージョン更新ではなく、GitHub上でセキュリティアラートを見ている開発チームの運用に関わります。

2026年6月5日のGitHub Changelogでは、CodeQL 2.25.6について大きく4つの方向が示されています。Swift 6.3.2でビルドしたアプリの解析対応、C# 14と.NET 10のフルサポート、Java/KotlinやC/C++のモデル追加、GitHub Actionsと機微データ検出のクエリ改善です。詳細はCodeQL公式changelogで、2026年6月4日付のCodeQL CLI 2.25.6として公開されています。

ここで大事なのは、アラート件数の増減をそのまま「コード品質が悪化した」「誤検知が増えた」と読まないことです。CodeQLはコードをデータベース化し、クエリで問題を探します。サポートする構文、ライブラリモデル、source/sink、データフロー、検出ヒューリスティックが変われば、同じコードでも検出結果が変わります。

対象になりやすいリポジトリ

優先して見るべきなのは、今回の変更対象に入る言語やワークフローを持つリポジトリです。Swift 6.3.2やC# 14/.NET 10を使っているリポジトリはもちろん、GitHub Actionsのworkflowが多いリポジトリ、Apache Avroを使うJava/Kotlinプロジェクト、scanf_s系の入力処理があるC/C++プロジェクトも確認対象になります。

JavaScript/TypeScript、Python、Swift、Rustでは、passwordやprivate dataを扱うコードの機微データ検出が改善されています。ログ出力系のアラート、特にclear-text logging関連のquery IDが動いた場合は、単純に新規バグと決めず、検出ロジックの改善で既存コードが見えるようになった可能性を見ます。

日付の読み分け

本文では、GitHub Changelogの告知日を2026年6月5日、CodeQL公式changelogのリリース日を2026年6月4日として分けます。小さな違いですが、社内の変更管理や週次レポートではこの差が効くことがあります。

たとえば、GitHub.comのcode scanningを使っているチームは、GitHub側の自動展開により比較的早く新しいCodeQLの影響を受ける可能性があります。一方で、GitHub Enterprise Server、自己管理のActions runner、外部CI、手動でダウンロードしたCodeQL bundleを使う環境では、利用中のCLIバージョンが2.25.6とは限りません。

最初に確認する5項目

• 直近のcode scanning runで使われたCodeQLバージョン
• 対象リポジトリの主要言語とworkflow
• 増えたアラートのquery ID
• 新規アラートか、再オープンか、既存アラートの表示位置変更か
• 過去にdismissした理由と、今回の検出位置が一致しているか

この5項目を見てから、修正、再評価、dismiss維持、設定見直しを分けると、CodeQL更新直後のノイズを減らせます。

Swift 6.3.2とC# 14/.NET 10で見るべきこと

項目	内容	見方
Swift 6.3.2		XcodeやSwift toolchain、build mode、CodeQL database作成ログを確認し、機微データ関連のquery IDとも切り分けます。
C# 14		新しい言語構文を含むコードが、意図したビルド条件で解析されているかを確認します。
.NET 10		runtimeモデルの更新により、API利用やデータフローの検出結果が変わっていないかを見ます。
共通		SDK更新日、スキャン実行日、CodeQL version、query IDをそろえて差分を読みます。

新バージョン対応は、すぐ修正が必要という意味ではなく、これまで見えにくかったコードパスが見える可能性を示します。

今回の目立つ変更は、SwiftとC#です。GitHub Changelogは、CodeQLがSwift 6.3.2でビルドされたアプリの解析をサポートし、C# 14と.NET 10のフルサポートを完了したと説明しています。CodeQL公式changelogでも、C# 14の新しい言語構文、QL library、データフロー解析、.NET 10 runtimeのModels as Dataモデルが対象になっています。

新しい言語やランタイムへの対応は、すぐにアラートが大量に増えるという意味ではありません。ただ、これまで解析が弱かった構文やAPIがより正しく扱われると、既存コードのリスクが見えるようになります。特に、先行して新しいSDKやtoolchainを入れているチームは、次回スキャンの差分を丁寧に見た方がよいでしょう。

Swift 6.3.2対応の見方

Swiftリポジトリでは、まずビルド環境とCodeQLのbuild modeを確認します。GitHub Docsのcompiled languages向け説明では、Swiftはautobuildまたはmanualのbuild modeに対応しています。XcodeやSwift toolchainの更新、依存関係、手動ビルド手順が変わっている場合、CodeQLのデータベース作成ログまで確認した方が安全です。

Swift 6.3.2対応だけを見ていると、機微データ検出改善との切り分けを見落とします。Swiftではswift/cleartext-loggingなど、機微データに関わる検出改善も話題に入っています。アラートが出たら、言語バージョン対応による解析範囲の拡大なのか、passwordやprivate dataを扱うパターンの検出改善なのかをquery IDで分けます。

Swiftチームの確認順

Swiftリポジトリでは、次の順番で見ると混乱しにくくなります。

• XcodeまたはSwift toolchainの更新時期
• CodeQLの解析が成功しているか
• autobuildかmanualか
• 新規アラートのquery ID
• ログ出力、認証情報、個人情報の扱いに関係するアラートか

Swift対応は、Appleプラットフォームの開発チームにとってありがたい更新です。ただし、CodeQL更新だけで安全性が保証されるわけではありません。ビルドが成功していること、対象ファイルが解析に入っていること、アラートの内容をレビューできることが前提です。

C# 14/.NET 10フルサポートの意味

C#側では、C# 14と.NET 10への対応が大きいポイントです。公式changelogは、extractorが新しい言語機能をサポートし、QL libraryとデータフロー解析が新しいC# 14言語構文に対応し、.NET 10 runtimeの生成済みModels as Dataモデルを含むと説明しています。

これは、.NET 10を試しているチームや、C# 14の新構文を使い始めているチームにとって、CodeQLの解析結果が実コードに近づく可能性があるということです。従来は構文やAPIモデルの不足で追いきれなかったデータフローが、より自然に追えるようになる場合があります。

C#チームの確認順

C#リポジトリでは、次のように確認します。

• 対象プロジェクトのTarget Framework
• C# language versionの設定
• CodeQLのbuild mode
• dotnet --versionやCI上のSDKバージョン
• CodeQL database作成ログ
• 新しいアラートが.NET 10 runtime APIやC# 14構文に関係するか

GitHub Docsでは、C#のCodeQL build modeとしてnone、autobuild、manualが説明されています。default setupでは、C#リポジトリのbuild modeが自動的にnoneになる説明もあります。高度な設定や外部CIを使っている場合、実際にどのbuild modeで解析しているかをworkflow側で確認してください。

GitHub Actionsアラートは再オープンを先に見る

1. query ID

   まずactions/untrusted-checkout/criticalかどうかを確認します。

2. alert location

   表示位置がcheckout pointに寄っただけなのか、別の実態を指しているのかを見ます。

3. dismiss reason

   false positive、risk accepted、used in testsなど、過去判断の理由を確認します。

4. 次の対応

   dismiss維持、説明更新、workflow修正、権限や入力元の見直しに分けます。

再オープンはリスクの急増とは限らず、過去判断と新しい検出位置の対応関係を確認する入口になります。

CodeQL 2.25.6で混乱しやすいのはGitHub Actions関連です。GitHub ChangelogとCodeQL公式changelogは、actions/untrusted-checkout/criticalのalert locationを、artifactを取得する場所、つまりcheckout pointにそろえたと説明しています。この変更により、以前に閉じた同じqueryのアラートが再オープンする可能性があります。

これは、GitHub Actionsのリスクが急に増えたというより、アラートの位置づけが変わることで、過去のdismiss状態と新しい検出位置が合わなくなる可能性があるという話です。再オープンしたアラートを見たら、まずquery IDとlocationを確認します。

actions/untrusted-checkout/criticalで確認すること

actions/untrusted-checkout/criticalは、信頼できない入力やリソースをcheckoutするリスクに関わるクエリです。今回の変更では、関連するuntrusted resource queriesとそろえる形で、アラート位置がcheckout pointに寄せられます。公式changelogは、この変更によって閉じたアラートが再オープンすると明記しています。

再オープンが出た場合、まず過去のdismiss reasonを見ます。開発チームが「false positive」として閉じたのか、「risk accepted」として閉じたのか、「used in tests」として扱ったのかで、次の対応は変わります。locationだけが変わって同じ実態を指しているのか、以前より正確な場所を指すようになったのかも確認します。

再オープン時の確認順

再オープンしたアラートは、次の順番で確認します。

1. query IDがactions/untrusted-checkout/criticalか
2. alert locationがcheckout周辺へ変わっているか
3. 過去のdismiss reasonは何か
4. workflowに外部入力、fork、pull request、third-party actionが関係するか
5. 今回は修正すべきか、dismiss維持か、説明を更新すべきか

この順番を共有しておくと、CodeQL更新直後に「閉じたはずのアラートが戻ってきた」とだけ騒がずに済みます。再オープンは運用ノイズではなく、過去判断を新しい検出位置で見直す機会です。

SHA-256やBash regexの改善も見る

GitHub Actionsでは、actions/unpinned-tagも更新されています。64文字のSHA-256 commit hashが、40文字のSHA-1 hashと同じく適切にpinされた参照として認識されるようになり、false positiveが減る可能性があります。

また、Bashのregex checkについて、SHA-1やSHA-256 hashなど英数字制限を確認するパターンがより認識されるようになりました。コマンド出力を使う前に検証しているworkflowでは、これもfalse positiveの減少につながる可能性があります。

severity変更と混同しない

公式changelogには、GitHub Actions queryのhelp file descriptionsの文言調整も含まれています。ただし、説明文の微修正をseverity変更やリスク増加と混同しない方がよいです。優先度は、query ID、security severity、workflowの権限、外部入力の有無、tokenの権限で判断します。

GitHub Actions周辺の運用は、GitHub Copilotや開発者自動化ともつながります。GitHub/Copilot周辺の開発基盤更新をまとめて追う場合は、製品・サービス・ソリューションカテゴリから関連更新を確認できます。

Java/Kotlin、C/C++、機微データ検出の確認範囲

Java/Kotlin

org.apache.avroのsource/sinkモデル追加により、Avroを通るデータの入口、変換、保存、送信を確認します。

C/C++

scanf_s系のflow source model追加により、入力値の境界チェック、フォーマット指定、後続処理を確認します。

JavaScript/TypeScript

passwordやprivate dataがログ、例外、デバッグ出力へ流れていないかをquery IDごとに確認します。

Python、Swift、Rust

機微データ検出の改善により、既存のログ出力やエラーハンドリングが新しく検出される可能性があります。

セキュリティ検出は単純な優劣ではなく、扱うデータ、入力元、出力先、既存のdismiss履歴を合わせて判断します。

SwiftとC#以外にも、実務で効く更新があります。Java/Kotlinではorg.apache.avroのsource/sinkモデルが追加され、C/C++ではscanf_sおよび関連関数のflow source modelが追加されています。さらに、JavaScript/TypeScript、Python、Swift、Rustでは、passwordやprivate dataを扱うコードの検出ヒューリスティックが改善されています。

これらの変更は地味ですが、実際のCode scanning alertsには効きます。Avroを使うデータ処理、C/C++の入力処理、ログ出力やデバッグ出力に機微データが入るコードは、次回スキャン後に差分を見ておく価値があります。

org.apache.avroモデル追加を見る

Apache Avroは、データシリアライズやスキーマ管理で使われます。CodeQL 2.25.6では、Java/Kotlin向けにorg.apache.avroのsource/sinkモデルが追加されました。これは、Avroを使っているだけで自動的に問題が出るという意味ではありません。データがどこから入り、どこで変換され、どこへ保存または送信されるかをCodeQLが追いやすくなるという意味です。

Avroを使うプロジェクトでは、依存関係、データの入口、シリアライズ/デシリアライズ、外部送信、ログ出力、既存のdismissed alertsを確認します。アラートが増えた場合は、コード変更の有無だけでなく、モデル追加によってデータフローが見えるようになった可能性を考えます。

scanf_s系モデル追加を見る

C/C++では、scanf_sと関連関数のflow source modelが追加されました。安全版関数という名前がついていても、入力として扱われる以上、その値が後続処理でどう使われるかは確認対象になります。

見るべきなのは、入力値の境界チェック、フォーマット指定、バッファサイズ、後続の信頼境界です。外部入力を受け取り、検証せずにファイルパス、コマンド、メモリ操作、ログ出力へ流している場合は、CodeQL更新で新しく見える可能性があります。

機微データ検出は増減の両方を見る

機微データ検出の改善は、アラートが増える可能性と減る可能性の両方があります。GitHub Changelogは、passwordやprivate dataを扱うコードの検出ヒューリスティックが改善され、より多くの正しい結果と少ないfalse positivesにつながる可能性があると説明しています。

ここで避けたいのは、「誤検知が増えた」と決めつけることです。新しく拾われたアラートが、これまで検出できなかった正しいリスクかもしれません。一方で、パターン認識の改善で不要なアラートが減ることもあります。

レビューで見る場所

機微データ系アラートでは、次を見ます。

• 検出された変数名やプロパティ名
• ログ出力先
• マスク処理の有無
• 個人情報、認証情報、token、secretとの関係
• secret scanningやログ保持ポリシーとの関係
• テスト用データか本番データか

セキュリティ担当者は、開発者に「新しいバグを入れた」と伝えるより、「CodeQLのモデル更新で既存コードの見え方が変わったので、query IDごとに確認したい」と説明した方が建設的です。

GitHub.com、GHES、外部CIでは確認順が違う

1. 1GitHub.com

   default setupでは自動展開を前提に、対象言語、スキャン頻度、pull request時の挙動を確認します。

2. 2advanced setup

   codeql workflowのinit、autobuild、analyze、language matrix、custom queries、build modeを確認します。

3. 3GHES

   GHESバージョンごとの推奨CodeQL CLI versionを確認し、2.25.6で解析済みかを切り分けます。

4. 4外部CI

   固定しているCodeQL CLI、キャッシュ、アップロード先、実行ログを確認してからアラート差分を読みます。

CodeQL 2.25.6の影響かどうかは、まず実際にそのバージョンで解析されたかを確認してから判断します。

GitHub Changelogは、CodeQLの新しいバージョンはGitHub.comのcode scanning利用者へ自動展開されると説明しています。また、CodeQL 2.25.6の新機能は将来のGitHub Enterprise Serverリリースにも含まれ、古いGHESでは手動でCodeQL versionを上げられると案内しています。

この違いは、実務ではかなり大きいです。GitHub.comで同じリポジトリを見ている人と、GHESや外部CIを使っている人が「CodeQL 2.25.6の影響」と言っても、実際にはまだそのバージョンで解析されていない可能性があります。

GitHub.comのdefault setupとadvanced setup

GitHub.comでdefault setupを使っている場合、CodeQLの更新には追従しやすいと見てよいでしょう。ただし、リポジトリごとの有効言語、スキャン頻度、pull request時の動き、alert表示は設定に左右されます。

advanced setupでは、.github/workflows/codeql*.ymlを確認します。github/codeql-action/init、autobuild、analyze、language matrix、custom queries、query suites、build modeを見ます。SwiftやC#のようなcompiled languagesでは、ビルドが成功しているか、どのbuild modeで解析しているかが重要です。

GHESと外部CIで見るCodeQL CLI

GitHub Enterprise ServerのDocsには、GHESバージョンごとの推奨CodeQL CLI versionが掲載されています。たとえば、掲載されている表ではGHES 3.21の推奨CodeQL CLIは2.24.3、GHES 3.20は2.23.9、GHES 3.19は2.22.4といった形で示されています。これは、2.25.6とは別です。

外部CIでCodeQL CLIを実行している場合は、CIログやセットアップスクリプトで実際のcodeql versionを確認します。CodeQL bundleを固定URLや社内ミラーから取得している場合、GitHub Changelogの告知だけでは更新されません。

バージョン確認の実務メモ

GHESや外部CIでは、次を見ます。

• GHESのバージョン
• GitHub Docs上の推奨CodeQL CLI version
• Actions workflow内のgithub/codeql-actionバージョン
• 外部CIが取得しているCodeQL bundle
• codeql versionのログ
• CodeQL database作成ログ
• query packやcustom queryの固定有無

この確認ができていないと、アラート差分をCodeQL 2.25.6由来と説明できません。社内報告では「CodeQL 2.25.6の告知を受けて確認したが、自社GHESの推奨CLIは別バージョンだった」という結論も十分あり得ます。

チームで使える確認チェックリスト

項目	内容	見方
CodeQL version		2.25.6の影響か、GitHub.com、GHES、外部CIの違いかを切り分けます。
query ID		Swift、C#、Actions、Avro、scanf_s系、機微データ検出のどれに近い変更かを分類します。
alert state		新規、再オープン、表示位置変更、false positiveの減少を同じ増減として扱わないようにします。
build log		compiled languagesでは、解析対象とbuild modeが変わっていないかを確認します。
dismiss reason		過去の判断を維持するか、説明を更新するか、修正に回すかを決めます。

「アラートが増えた」ではなく、解析対象の変化、既存リスクの再検出、修正が必要な新規問題に分けて伝えると対応しやすくなります。

CodeQL更新後の確認は、セキュリティ担当だけで抱え込むより、開発チームに見てもらう項目を分けた方が進みます。ここでは、次回スキャン後にIssueやSlackへ貼れる粒度で整理します。

まず、アラートを4種類に分けます。新規検出、再オープン、表示位置の変更、false positiveの減少です。すべてを同じ「増減」として扱うと、対応優先度を間違えます。

最初に見る項目

次回スキャン後に見る項目は、次の通りです。

確認項目	見る理由	対応の分け方
CodeQL version	2.25.6の影響か判断する	GitHub.com、GHES、外部CIで分ける
query ID	どの変更に近いか判断する	Swift/C#/Actions/Avro/機微データに分類
alert state	新規か再オープンかを分ける	dismiss履歴を確認
alert location	位置変更か実コードの別問題かを見る	Actionsではcheckout周辺を確認
build log	解析対象が変わったかを見る	compiled languagesでは特に重要
dismiss reason	過去判断が今も妥当か見る	維持、修正、説明更新に分ける

この表を先に共有しておくと、CodeQL更新直後のレビューが進めやすくなります。特にactions/untrusted-checkout/criticalは、再オープンが公式に想定されているため、担当者に事前共有しておく価値があります。

説明のしかた

セキュリティ担当者が開発者に伝えるなら、「CodeQL 2.25.6で解析対象と検出モデルが広がったため、既存コードの見え方が変わる可能性がある。新規混入か、既存リスクの再検出か、dismiss維持でよいかをquery IDごとに確認したい」という言い方が現実的です。

逆に、「アラートが増えたので直してください」だけだと、開発者側はコードを変えていないのに責められたように受け取りがちです。CodeQLの更新内容とquery IDを添えると、レビューの会話が前に進みます。

修正とdismissの判断

判断は、次の4つに分けます。

• すぐ直す: 機微データのログ出力、危険なworkflow、外部入力の未検証など実害が明確
• 担当者に確認: 新しい言語機能やランタイムAPIが絡み、仕様理解が必要
• dismiss維持: 過去判断が今も妥当で、location変更だけと説明できる
• 設定見直し: build mode、query suite、custom query、workflow設定の問題が見つかった

2026年6月のMicrosoft/GitHub関連更新は、Microsoft 2026年6月重要トピックまとめにも集約しています。CodeQLのような短いChangelog更新は見落としやすいので、月次の公式発表と合わせて追うと流れがつかみやすくなります。

---

次に読むなら

参照した主な情報源

• GitHub Changelog, "CodeQL 2.25.6 adds Swift 6.3.2 support and improves C# coverage"（確認日: 2026年6月9日JST）

CodeQL 2.25.6 adds Swift 6.3.2 support and improves C# coverage

• CodeQL Docs, "CodeQL 2.25.6 (2026-06-04)"（確認日: 2026年6月9日JST）

https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.25.6/

• GitHub Docs, "Code scanning with CodeQL"（確認日: 2026年6月9日JST）

https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql

• GitHub Docs, "Concepts for CodeQL"（確認日: 2026年6月9日JST）

https://docs.github.com/en/code-security/concepts/code-scanning/codeql

• GitHub Enterprise Server Docs, "CodeQL build options and steps for compiled languages"（確認日: 2026年6月9日JST）

https://docs.github.com/en/enterprise-server@3.19/code-security/reference/code-scanning/codeql/build-options-for-compiled-languages

• GitHub Enterprise Server Docs, "GitHub Enterprise Server releases"（確認日: 2026年6月9日JST）

https://docs.github.com/en/enterprise-server@3.17/admin/all-releases

Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の情報整理サイトです。この記事は公式情報の確認を目的としており、投資助言や売買推奨ではありません。

更新通知を受け取りたい場合は、ニュースレターでMicrosoftの公式発表、GitHub Changelog、製品更新、噂確認の追跡をまとめて受け取れます。