2026年4月16日時点で、Kotlinを使う開発組織がGitHub code scanningを継続利用するうえで重要な更新は、CodeQL 2.25.2がKotlin 2.3.20までの分析に対応したことです。これにより、Kotlin側のバージョン更新にセキュリティスキャンが追従しやすくなり、独自の回避策や古いKotlinへの足止めを減らせます。
特に、GitHub上のcode scanningにCodeQLを任せているApplication SecurityチームやKotlin開発者にとっては、「新しいKotlinに上げたいが、CodeQLの対応状況が不安」という判断ポイントが一つ減ったことになります。あわせて、Java/Kotlin向けの誤検知削減やセキュリティ重要度の見直しも含まれているため、単なる言語バージョン対応ではなく、アラート運用の精度にも関わるリリースです。GitHub公式Changelogでは、CodeQL 2.25.2についてKotlin 2.3.20対応、複数クエリの精度改善、複数言語にまたがるsecurity severityの調整が案内されています。(The GitHub Blog)
GitHub CodeQL / code scanningの最新動向として何が変わったのか
今回のCodeQL 2.25.2で、Kotlinチームに最も関係する変更は次の3点です。
| 変更点 | Kotlin組織への影響 | 確認すべきこと |
|---|---|---|
| Kotlin 2.3.20までの分析に対応 | Kotlinのアップデート後もGitHub code scanningを継続しやすい | リポジトリのKotlinバージョンとCodeQLの実行環境 |
| Java/Kotlin向けクエリの誤検知削減 | AppSecチームのトリアージ負荷を下げやすい | 既存アラートの変化、dismiss済みアラートの扱い |
| Java/Kotlinを含む複数言語でsecurity severityを調整 | アラート優先度が変わる可能性がある | XSS、Android WebView、log injection関連の優先度 |
GitHubのCodeQL Changelogでは、Java/Kotlinについて「Kotlin versions up to 2.3.20 are now supported」と明記されています。また、java/tainted-arithmeticやjava/potentially-weak-cryptographic-algorithmの誤検知削減、Java/Kotlinのjava/xssやAndroid WebView関連クエリの重要度引き上げ、java/log-injectionの重要度引き下げも示されています。(CodeQL)
なぜKotlinショップにとってCodeQL 2.25.2が重要なのか
Kotlinを本格利用している組織では、言語やGradleプラグインの更新がアプリ開発の速度に直結します。ところが、静的解析ツールの言語対応が遅れると、次のような問題が起こりがちです。
- Kotlinは上げたいが、セキュリティスキャンが壊れるため保留する
- CodeQLとは別にKotlin用の補助スキャンを追加する
- 解析対象から一部ディレクトリを外す
- AppSecチームが「スキャン結果が信頼できるか」を毎回確認する
- CIの失敗を避けるため、CodeQLの設定に例外処理を増やす
CodeQL 2.25.2のKotlin 2.3.20対応は、こうした運用上の摩擦を減らす更新です。特にGitHub code scanningを標準のセキュリティゲートとして使っている組織では、開発チームがKotlinを更新しても、スキャン基盤側で特別なつぎはぎを入れずに追従しやすくなります。
GitHub Docsでは、CodeQLがGitHub code scanningの分析エンジンとして使われ、検出結果はGitHub上のcode scanning alertsとして表示されると説明されています。CodeQLはJava/Kotlinをサポート対象言語に含み、Java、Kotlin、またはその両方を分析する場合はjava-kotlinを使う点も明記されています。(GitHub Docs)
「カスタム回避策なしで最新に追従できる」とはどういう意味か
ここでいう「カスタム回避策なし」とは、CodeQLの標準的なcode scanning運用から外れずに、Kotlinの比較的新しいバージョンを解析できる状態を指します。
たとえば、次のような対応を避けやすくなります。
| 避けたい回避策 | なぜ問題になりやすいか | CodeQL 2.25.2で期待できる改善 |
|---|---|---|
| Kotlinだけ別の静的解析ジョブを追加する | CIが複雑になり、結果の集約や重複管理が必要になる | CodeQL/code scanning中心の運用に寄せやすい |
| Kotlinのアップデートをセキュリティスキャン待ちで止める | 開発チームの技術更新が遅れる | Kotlin 2.3.20までの対応により更新判断がしやすい |
| CodeQLの古い設定を固定し続ける | 新しいクエリ改善や重要度調整を取り込めない | GitHub.comのcode scanningでは新しいCodeQLが自動展開される |
| 誤検知を大量にdismissする | AppSecレビューの信頼性が落ちる | Java/Kotlin向けクエリ改善で一部の誤検知削減が期待できる |
GitHub Changelogでは、GitHub.comのcode scanning利用者には新しいCodeQLバージョンが自動的にデプロイされると説明されています。一方、GitHub Enterprise ServerではCodeQL 2.25.2の機能は将来のGHESリリースに含まれ、古いGHESを使う場合はCodeQLの手動アップグレードが選択肢になります。(The GitHub Blog)
Kotlinチームがまず確認すべき3つのポイント
GitHub.comかGHESかを確認する
GitHub.comでGitHub code scanningを使っている場合、CodeQLの新バージョンは自動的に展開されます。つまり、通常はCodeQL CLIを自分で差し替えたり、リポジトリごとに特殊な対応を入れたりする必要はありません。
一方で、GitHub Enterprise Serverを使っている組織では事情が異なります。GHESのバージョンによって利用できるCodeQLの内容が変わるため、Kotlin 2.3.20対応を使いたい場合は、現在のGHESで利用できるCodeQLバージョンを確認してください。
判断基準はシンプルです。
| 利用環境 | 推奨アクション |
|---|---|
| GitHub.com | 次回のcode scanning実行結果を確認し、Kotlin関連の警告やアラート変化を見る |
| GitHub Enterprise Cloud | 基本的にはGitHub.com同様に最新動向を確認しつつ、組織設定を点検する |
| GitHub Enterprise Server | GHESのリリース状況、CodeQLのバージョン、手動アップグレード可否を確認する |
| 外部CIでCodeQL CLIを直接実行 | 使用しているCodeQL CLI / bundleのバージョンを確認する |
Kotlin分析でbuild-mode: noneになっていないか確認する
Kotlinプロジェクトでは、CodeQLの「言語対応」だけでなく「ビルドモード」が重要です。GitHub Docsでは、Javaはnone、autobuild、manualに対応する一方、Kotlinはautobuildまたはmanualに対応すると説明されています。さらに、Javaのみのリポジトリでnoneモードを使っていた後からKotlinを追加した場合、Kotlinがサポートされないことを示す警告が出るため、default setupを再有効化するかadvanced setupへ変更する必要があります。(GitHub Docs)
Kotlinファイルがあるのにbuild-mode: noneで運用していると、CodeQL 2.25.2へ上がっていても、Kotlinコードが期待どおり分析されない可能性があります。今回のリリースはKotlin 2.3.20対応を追加するものですが、「Kotlinはビルドが必要」という前提までなくなるわけではありません。
確認すべき箇所は、主に.github/workflows/codeql-analysis.ymlです。
- uses: github/codeql-action/init@v4
with:
languages: java-kotlin
build-mode: autobuild自動ビルドでうまくいかない場合は、advanced setupでmanualを使い、実際のビルドコマンドを明示します。
- uses: github/codeql-action/init@v4
with:
languages: java-kotlin
build-mode: manual
- run: ./gradlew clean build -x test
- uses: github/codeql-action/analyze@v4実務では、./gradlew buildが重すぎる場合もあります。その場合は、CodeQLに解析させたいモジュールがビルドされる最小限のGradleタスクに絞るのが現実的です。
アラートの増減を「悪化」と決めつけない
CodeQLの更新後にアラート件数が増減することがあります。これは必ずしもコードの安全性が急に悪化したという意味ではありません。
今回のCodeQL 2.25.2では、Java/Kotlin関連で次のような変化があります。
| 変化 | 実務上の見方 |
|---|---|
java/tainted-arithmeticの誤検知削減 | 境界チェックのような意図的な比較処理が不要に警告されにくくなる |
java/potentially-weak-cryptographic-algorithmの誤検知削減 | EC、HMAC、PBKDF2などが過剰に弱い暗号として扱われにくくなる |
java/xssの重要度引き上げ | WebアプリのXSS関連アラートは優先的に見るべき |
| Android WebView関連クエリの重要度引き上げ | AndroidアプリではWebView設定やJavaScript bridgeの扱いを再点検する価値がある |
java/log-injectionの重要度引き下げ | 対応不要ではなく、他の高リスク項目との優先順位を見直す |
つまり、更新直後は「件数」だけでなく「どのルールIDが変わったか」「新規なのか、重要度だけが変わったのか」を見ることが大切です。
AppSecチーム向け：CodeQL 2.25.2後の運用チェックリスト
CodeQL 2.25.2を受けて、AppSecチームは次の順で確認すると効率的です。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Kotlin 2.3.20を使うリポジトリがあるか | Gradle設定、Kotlin plugin設定 | 対象リポジトリを優先確認する |
CodeQLがjava-kotlinで実行されているか | CodeQL workflow | JavaだけのつもりでKotlinが漏れていないか |
build-mode: noneが残っていないか | CodeQL workflow、default setupの状態 | Kotlinがあるならautobuildまたはmanualを検討 |
| 新規・再分類アラートが増えていないか | Securityタブ、code scanning alerts | XSS、Android WebView、暗号関連を優先 |
| dismiss理由が古くなっていないか | 既存アラートの履歴 | 誤検知削減後も同じ判断でよいか見直す |
| GHES利用時にCodeQLが古くないか | 管理者設定、CodeQL bundle | 必要ならアップグレード計画を立てる |
特に大規模組織では、全リポジトリを一度に見るよりも、次のように優先順位を付けると現実的です。
- 外部入力を扱うAPIサーバー
- WebViewを使うAndroidアプリ
- 認証、決済、個人情報を扱うサービス
- Kotlin 2.3系へ更新済み、または更新予定のリポジトリ
- CodeQLの警告が以前から出ているリポジトリ
AppSecの観点では、今回の更新を「スキャンツールのニュース」として流すのではなく、「Kotlinアップデートのセキュリティゲートを最新化するタイミング」と捉えるべきです。
Kotlin開発者向け：プルリクエスト前に見ておきたいこと
Kotlin開発者は、CodeQLの細かいクエリ仕様をすべて覚える必要はありません。ただし、次の点を押さえておくと、AppSecレビューで止まりにくくなります。
GradleビルドがCI上で再現できる状態にする
KotlinのCodeQL分析ではビルドが重要です。ローカルでは通るがGitHub Actionsでは依存関係が取れない、特定の環境変数がないとビルドできない、生成コードのタスクが省略されている、といった状態では解析の精度が落ちる可能性があります。
実務でよくある失敗は次の通りです。
| 失敗例 | 起こる問題 | 対策 |
|---|---|---|
| private Maven repositoryへの認証がCIにない | 依存関係解決に失敗する | GitHub Actions secretsやOIDC連携を整備する |
| Android/Kotlin Multiplatformの一部タスクだけ失敗する | 自動ビルドが途中で止まる | manual buildで解析対象モジュールを明示する |
| 生成コードがビルド前に作られない | 実際のコードパスが解析されにくい | 生成タスクをCodeQL前のビルドに含める |
| テストやLintまで実行して時間切れになる | code scanningが遅くなる | CodeQLに必要なコンパイル範囲に絞る |
XSSやAndroid WebView関連の指摘を軽く扱わない
CodeQL 2.25.2では、Java/Kotlinのjava/xssやAndroid WebView関連のセキュリティ重要度が引き上げられています。これは、該当するアラートが出たときに、単なる静的解析のノイズとして片付けないほうがよいというシグナルです。(CodeQL)
たとえば、次のようなコードはレビュー対象になりやすい領域です。
- ユーザー入力をHTMLへ埋め込む処理
- テンプレートやレスポンス本文を手動生成している箇所
- Android WebViewでJavaScriptを有効化している箇所
addJavascriptInterfaceを使ってネイティブ機能を公開している箇所- URL、リダイレクト先、HTML断片を外部入力から組み立てる処理
CodeQLの指摘が出た場合は、まず「本当に外部入力が到達するか」「出力前に適切にエスケープされているか」「WebViewの公開範囲が必要最小限か」を確認しましょう。
default setupとadvanced setupの使い分け
GitHub code scanningには、default setup、advanced setup、外部CIでCodeQL CLIを実行して結果をアップロードする方法があります。GitHub Docsでは、default setupは分析対象言語、実行クエリ、スキャンを起動するイベントを自動選択し、advanced setupではCodeQL workflowを追加してカスタマイズできると説明されています。(GitHub Docs)
Kotlin組織では、次のように使い分けるとよいでしょう。
| 状況 | おすすめ |
|---|---|
| 単純なGradle/Maven構成で自動ビルドが通る | default setupまたはautobuild |
| モノレポで対象モジュールを絞りたい | advanced setup + manual build |
| AndroidやKotlin Multiplatformで自動ビルドが不安定 | advanced setup + 必要なGradleタスクを明示 |
| 既存CI基盤でセキュリティスキャンを統合したい | CodeQL CLI + SARIFアップロード |
| 社内フレームワークや独自ライブラリのデータフローを補いたい | model packsやカスタム設定を検討 |
重要なのは、「Kotlin 2.3.20対応になったから何もしなくてよい」と考えないことです。言語バージョン対応と、正しくビルドされて解析対象に入ることは別問題です。
リリース後にアラートが変わったときの見方
CodeQLのような静的解析エンジンは、リリースごとに対応言語、ライブラリモデル、クエリ精度、重要度が変わります。そのため、CodeQL 2.25.2後にアラートが変わった場合は、次の順で確認すると混乱を避けられます。
| 確認順 | 見ること | 目的 |
|---|---|---|
| 1 | CodeQL実行ログ | Kotlinファイルが正しく分析されたか確認する |
| 2 | 新規アラートのRule ID | 新しい脆弱性か、重要度変更かを切り分ける |
| 3 | 影響範囲 | 本番コード、テストコード、生成コードのどれかを見る |
| 4 | データフロー | 外部入力から危険なsinkまで到達するか確認する |
| 5 | 修正方針 | コード修正、設定変更、dismissのどれが適切か判断する |
特にAppSecチームは、単に「Highが増えた」と開発チームへ差し戻すのではなく、「今回のCodeQL更新でXSS系のseverityが上がったため、外部入力の到達可能性を確認してほしい」のように、理由と確認観点を添えると対応が速くなります。
まだカスタム対応が必要になるケース
CodeQL 2.25.2はKotlin組織にとって前向きな更新ですが、すべてのカスタム対応が不要になるわけではありません。
次のような場合は、引き続き設定調整が必要です。
| ケース | 必要になりやすい対応 |
|---|---|
| GHESで古いCodeQLを使っている | CodeQLまたはGHESの更新計画を確認 |
| Kotlinを後から追加したJavaリポジトリ | build-mode: noneからの移行確認 |
| 自動ビルドが失敗する | advanced setupでmanual buildを設定 |
| モノレポで不要なモジュールまで解析して遅い | ビルド対象やworkflow matrixを整理 |
| 社内独自フレームワークを多用している | CodeQL model packsやカスタムクエリを検討 |
| アラートの重複やノイズが多い | dismiss理由、query filter、スコープ設定を見直す |
GitHub Docsでも、標準クエリで認識されないライブラリやフレームワークに対して、分析範囲を拡張できることが説明されています。つまり、今回の更新で「Kotlin言語バージョンの追従」は進みましたが、社内固有のフレームワークやデータフローまで完全に自動で理解されるとは限りません。(GitHub Docs)
いま取るべき実務アクション
Kotlinを使う組織は、CodeQL 2.25.2のリリースを次のように扱うのがおすすめです。
まず、Kotlin 2.3系を使っている、または近く更新予定のリポジトリを洗い出します。次に、GitHub code scanningの実行ログを確認し、java-kotlinで分析されているか、build-mode: noneが残っていないかを点検します。最後に、CodeQL更新後のアラート差分を見て、XSS、Android WebView、暗号関連、log injectionの優先度を見直しましょう。
開発チームにとっての価値は、Kotlinアップデートとセキュリティスキャンを対立させずに済むことです。AppSecチームにとっての価値は、GitHub code scanningを中心にした標準運用を保ちながら、最新の言語対応とクエリ改善を取り込めることです。
CodeQL 2.25.2は派手な新機能というより、Kotlinを実務で使う組織が「スキャン基盤を壊さずに前へ進む」ための重要なメンテナンスリリースです。まずは対象リポジトリのCodeQL workflowとビルドモードを確認し、次回のcode scanning結果でKotlinコードが正しく解析されているかを見てください。
コメント