Swift 6.3.3やKotlin 2.4.10へ更新した後、「現在のGitHub CodeQLで正しく解析できるのか」「GitHub Enterprise Server側も更新が必要なのか」と迷うケースがあります。
結論として、Swift 6.3.3とKotlin 2.4.10への対応が追加されたのはCodeQL 2.26.2です。GitHub.comでGitHub管理のcode scanningを利用している場合、CodeQLの新バージョンは自動的に反映されるため、通常は利用者による更新作業は必要ありません。一方、旧バージョンのGitHub Enterprise Server（GHES）や外部CIでCodeQL CLIを運用している場合は、CodeQL 2.26.2以降への手動更新が必要になることがあります。(The GitHub Blog)
ただし、CodeQLのバージョンを上げただけで必ず解析が成功するわけではありません。KotlinのビルドモードやSwiftのビルド環境、解析対象言語の指定も併せて確認する必要があります。
Swift 6.3.3・Kotlin 2.4.10を解析できるCodeQL版は？
Swift 6.3.3とKotlin 2.4.10の対応関係は次のとおりです。
| 対象言語 | 解析対象のバージョン | 対応が追加されたCodeQL |
|---|---|---|
| Swift | Swift 6.3.3でビルドされたアプリ | CodeQL 2.26.2 |
| Kotlin | Kotlin 2.4.10まで | CodeQL 2.26.2 |
CodeQL 2.26.2では、Swift 6.3.3でビルドされたアプリを解析できるようになりました。Java/Kotlin解析では、Kotlin 2.4.10までがサポート対象になっています。(CodeQL)
KotlinはCodeQL上でJavaと共通の解析系として扱われます。ワークフローやCLIで言語を指定するときは、通常、言語識別子としてjava-kotlinを使用します。(GitHub Docs)
CodeQL 2.26.2は「対応開始版」
CodeQL 2.26.2は、Swift 6.3.3とKotlin 2.4.10への対応が始まった基準となるバージョンです。
新規導入時に、あえて2.26.2へ固定しなければならないわけではありません。運用環境で利用可能な、2.26.2より新しい安定版を選ぶのが基本です。CodeQLの公式変更履歴では2.26.2以降のバージョンも公開されているため、導入時点のリリースノートを確認して判断してください。(CodeQL)
判断基準は次のようになります。
- CodeQL 2.26.1以前を使用している場合は更新対象
- CodeQL 2.26.2ならSwift 6.3.3とKotlin 2.4.10の対応条件を満たす
- 新規構築では、検証済みの新しい安定版を優先する
- 社内規定でバージョン固定が必要な場合は、最低ラインを2.26.2とする
GitHub.comとGHESでは更新の必要性が異なる
CodeQLの更新が必要かどうかは、code scanningをどこで実行しているかによって変わります。
| 利用環境 | CodeQL 2.26.2への更新 | 利用者が行うこと |
|---|---|---|
| GitHub.comのデフォルトセットアップ | 原則不要 | 次回の解析結果を確認する |
| GitHub.comのCodeQL Action | 通常は自動反映 | ワークフローを実行してログを確認する |
| GitHub.comで独自CLI bundleを固定 | 必要な場合あり | CLIのバージョンを確認する |
| 古いGHES | 必要な場合あり | 管理者が同梱版・配布bundleを確認する |
| インターネット非接続のGHES | 手動同期が必要な場合あり | CodeQL Action sync toolを使用する |
| Jenkinsなどの外部CI | 原則として手動 | CodeQL bundleを更新する |
| ローカルのCodeQL CLI | 手動 | CLI bundleを入れ替える |
GitHubは、GitHub.com上のcode scanning利用者に新しいCodeQLを自動展開しています。CodeQL 2.26.2の機能は将来のGHESリリースにも含まれますが、古いGHESを使用している場合はCodeQLを手動更新できると案内されています。(The GitHub Blog)
GitHub.comでは基本的に手動更新不要
GitHub.comで次の構成を利用している場合、通常はCodeQL CLIを自分でダウンロードし直す必要はありません。
- code scanningのデフォルトセットアップ
- 標準的なCodeQL Actionによる高度なセットアップ
- GitHubが提供するCodeQL bundleを自動取得する構成
ただし、自動反映されたからといって、過去の解析結果がその場で自動的に作り直されるとは限りません。SwiftやKotlinのバージョンを更新した後は、次回のCodeQLワークフローが完了した時点で解析結果を確認してください。
GitHub Actionsのログは、リポジトリの「Actions」からCodeQLワークフローを開き、「Analyze」ジョブを選択して確認できます。(GitHub Docs)
CodeQL ActionのバージョンとCodeQL CLIのバージョンは別
ワークフロー内に、次のような記述があったとします。
uses: github/codeql-action/init@v4このv4はCodeQL Actionのメジャーバージョンです。CodeQL CLI 2.26.2を意味するものではありません。
CodeQL Actionと、実際に解析を行うCodeQL CLI bundleは別に管理されます。GHESでは、アプライアンスやActionの構成に応じて特定のCodeQL bundleがダウンロードされるため、ワークフローに書かれた@v4だけを見てもSwift 6.3.3対応の有無は判断できません。(GitHub Docs)
現在のCodeQLバージョンを確認する方法
CodeQL CLIや外部CIを管理している場合は、最初に次のコマンドを実行します。
codeql versionJSON形式で取得したい場合は、次のように実行できます。
codeql version --format=jsoncodeql versionは、使用中のCodeQLツールチェーンのバージョンを表示する公式コマンドです。(GitHub Docs)
結果の判断方法は次のとおりです。
| 表示されたバージョン | 判断 |
|---|---|
| 2.26.1以前 | Swift 6.3.3・Kotlin 2.4.10対応のため更新する |
| 2.26.2 | 対応条件を満たしている |
| 2.26.2より新しい | ビルドモードやリリースノートも確認する |
| コマンドが見つからない | PATHまたはCLIの配置を確認する |
更新したのに古いバージョンが表示される場合
新しいCodeQL bundleを展開しても、PATHの先頭に古いcodeqlが残っていると、古いバージョンが実行されます。
次の点を確認してください。
- CIランナー上に複数のCodeQL CLIが残っていないか
- PATHの先頭が新しいbundleを指しているか
- ジョブごとに異なるランナーイメージを使用していないか
- キャッシュされた古いツールを再利用していないか
- 管理端末と実際の解析ランナーで確認結果が異なっていないか
確認時は、可能であれば絶対パスで実行します。
/path/to/new-codeql/codeql/codeql version「管理者の端末では2.26.2だが、CIランナーでは2.25系だった」という状態を防げます。
CodeQL CLIを2.26.2以降へ更新する手順
外部CIやローカル環境では、CLI実行ファイルだけではなく、CodeQL bundle全体を更新するのが安全です。
CodeQL bundleには次の要素が含まれます。
- CodeQL CLI本体
- CLIと互換性のあるクエリおよびライブラリ
- コンパイル済みの標準クエリ
GitHubは、CLI単体と任意のクエリソースを組み合わせるのではなく、互換性と解析性能を確保するためにCodeQL bundleの使用を推奨しています。(GitHub Docs)
更新手順
- 現在の
codeql versionを記録する - CodeQL 2.26.2以降を含む公式bundleを取得する
- 既存環境とは別のディレクトリへ展開する
- CIランナーの参照先を新しいbundleへ変更する
codeql versionを再実行する- 対応言語とクエリパックを確認する
- 新しいCodeQLデータベースを作成して解析を実行する
- 旧版とのアラート差分を確認する
- 問題がなければ全ランナーへ展開する
対応言語の確認には、次のコマンドを使用できます。
codeql resolve languagesクエリパックの配置確認には、次のコマンドを使用します。
codeql resolve packscodeql resolve languagesでは、現在のCLI packageでデータベースを作成できる言語を確認できます。codeql resolve packsでは、SwiftやJava/Kotlinのクエリパックが正しいbundle内から読み込まれているかを確認できます。(GitHub Docs)
ただし、resolve languagesにswiftやjava-kotlinが表示されるだけでは、Swift 6.3.3やKotlin 2.4.10への対応までは確認できません。最終的な対応バージョンは、codeql versionと公式変更履歴を組み合わせて判断します。
古いGHESでCodeQLを更新するときの注意点
GHESでは、アプライアンス本体のバージョンとCodeQL bundleのバージョンが必ずしも一致しません。
GHESのバージョン番号だけを見て「十分に新しい」と判断せず、次の情報を確認してください。
- GHESに同梱されているCodeQL CLIのバージョン
- GitHub Actionsランナーが実際に取得したbundle
- 独自に同期しているCodeQL Actionのバージョン
- 外部CI側で使用しているCLIのバージョン
- インターネット接続の有無
特に、インターネットへ接続できないGHESでは、CodeQL Action sync toolを使ってGitHub.comからCodeQL Actionと解析bundleを同期できます。公式ドキュメントでは、この同期ツールによって最新リリースのCodeQL Actionと関連bundleをローカルへ同期できると説明されています。(GitHub Docs)
本番環境へ直接入れ替えるのではなく、まず検証用ランナーで次の項目を確認してください。
- Swift 6.3.3のプロジェクトがビルドできるか
- Kotlin 2.4.10のプロジェクトがビルドできるか
- カスタムクエリが正常に動くか
- 既存アラートが維持されているか
- 新規アラートが大量発生していないか
- 解析時間やメモリ使用量が許容範囲か
Kotlin 2.4.10ではbuild-modeの設定を確認する
CodeQL 2.26.2へ更新しても、Kotlinが解析されない代表的な原因がbuild-mode: noneです。
CodeQLではJavaをビルドせずに解析できますが、Java解析でbuild-mode: noneを選択した状態でKotlinファイルが存在しても、KotlinコードはCodeQLデータベースへ含まれません。GitHubも、この場合はKotlinコードが解析されず警告が表示されると案内しています。(GitHub Docs)
次のような設定になっている場合は注意してください。
build-mode: noneKotlinを含むリポジトリでは、原則として次のいずれかを使用します。
autobuild- 手動ビルド
- Kotlinを含む実際のGradleまたはMavenビルド
Kotlin 2.4.10対応を確認するときは、「CodeQLが2.26.2以上か」だけでなく、次の点も確認します。
- 解析言語に
java-kotlinが含まれている - Kotlinコンパイラ2.4.10を使用したビルドがCI上で成功する
build-mode: noneになっていない- Gradle WrapperやMaven Wrapperが実行可能になっている
- private registryや社内リポジトリへアクセスできる
- コード生成処理が解析時にも実行されている
Swift 6.3.3ではビルド環境も必要
CodeQL 2.26.2はSwift 6.3.3でビルドされたアプリの解析に対応していますが、CodeQLが対応していることと、CI上でプロジェクトをビルドできることは別問題です。
Swiftはコンパイル言語であり、CodeQLデータベースを作成する際には、通常、autobuildまたは手動ビルドが使用されます。Kotlinについても同様に、ビルドを通じて必要なデータを抽出します。(GitHub Docs)
Swiftの解析が失敗する場合は、次の順番で切り分けてください。
codeql versionが2.26.2以上か確認する- ランナーに目的のSwiftツールチェーンがあるか確認する
- CodeQLを介さず通常のビルドが成功するか確認する
- Xcode、Swift Package Manager、依存パッケージの取得状況を確認する
autobuildで失敗する場合は手動ビルドへ切り替える- ビルド対象のschemeやconfigurationを明示する
- CodeQLワークフローを再実行する
バージョン更新後にエラーが出た場合でも、すぐに「CodeQL 2.26.2がSwift 6.3.3へ対応していない」と判断してはいけません。通常ビルドも失敗するのであれば、CodeQLではなくツールチェーンや依存関係が原因です。
SwiftとKotlinを含むモノレポでは言語を明示する
iOSアプリとAndroidアプリを同じリポジトリで管理している場合、SwiftとKotlinの両方を明示的に解析対象へ含めることが重要です。
高度なセットアップで解析言語を明示しない場合、複数のコンパイル言語が存在していても、ソースファイル数が最も多い言語だけが暗黙的に選ばれることがあります。GitHubは、必要な言語をワークフローのmatrixへ追加するよう案内しています。(GitHub Docs)
たとえば、次の2つを別ジョブとして設定する構成が分かりやすいでしょう。
| 対象 | CodeQLの言語指定 | 推奨ランナーの考え方 |
|---|---|---|
| iOSアプリ | swift | Swiftプロジェクトをビルドできる環境 |
| Androidアプリ | java-kotlin | GradleやJDKを利用できる環境 |
「CodeQL 2.26.2へ更新したのにKotlinだけ解析されない」という場合、バージョンではなく、言語matrixからjava-kotlinが漏れている可能性もあります。
更新後にアラートが増えても不具合とは限らない
CodeQL 2.26.2では、言語バージョン対応だけでなく、既存クエリの精度改善も行われています。
Java/Kotlinでは、java.io.File.getName()がパストラバーサル要素の..を除去しないことから、パスインジェクションに対する完全なサニタイザーとして扱われなくなりました。そのため、CodeQLの更新後にjava/path-injection関連のアラートが新しく検出される可能性があります。(CodeQL)
たとえば、次のような処理です。
String name = new File(userInput).getName();
File target = new File(uploadDirectory, name);getName()を通しただけで安全と判断せず、..や想定外のパス要素が残っていないか確認する必要があります。
更新前後でソースコードを変更していなくても、クエリやデータフローモデルが改善されればアラート数は変化します。新規アラートを一括で誤検知扱いにせず、次の分類を行ってください。
- 実際に修正が必要な脆弱性
- 新しいモデルによって可視化された既存問題
- ビルド条件の変化による解析範囲の拡大
- 重複アラート
- 業務上許容できるリスク
- 誤検知として根拠を記録できるもの
カスタムクエリのメッセージ記法にも変更がある
CodeQL 2.26.2では、アラートメッセージ内の[[形式によるリンク記法が廃止されました。
独自のCodeQLクエリでリンクを埋め込んでいる場合は、$@のプレースホルダーペアを使用する形式へ変更する必要があります。これはドキュメント化されていなかった旧式機能に対する破壊的変更です。(The GitHub Blog)
標準クエリだけを使用している一般利用者への影響は限定的ですが、社内クエリパックを運用している組織は事前検証が必要です。
解析できないときの切り分け表
| 症状 | 考えられる原因 | 最初に確認すること |
|---|---|---|
| Swift 6.3.3を認識できない | CodeQLが古い | codeql version |
| Kotlin 2.4.10を認識できない | CodeQLが古い | 2.26.2以上か |
| Kotlinファイルが解析対象に入らない | build-mode: none | autobuildまたは手動ビルドへ変更 |
| Swiftだけ解析されない | ビルド環境不足 | 通常のSwiftビルドが成功するか |
| Kotlinだけ解析されない | 言語指定漏れ | java-kotlinが設定されているか |
| モノレポの片方しか解析されない | 暗黙の言語検出 | SwiftとJava/Kotlinを明示する |
| 更新後にアラートが増えた | クエリ精度の改善 | 新旧アラートの差分を確認する |
| 更新後も古い版が使われる | PATHやキャッシュ | 実行ファイルの絶対パスを確認する |
| カスタムクエリの表示が変わった | 旧リンク記法 | [[形式を見直す |
| GHESだけ対応しない | 同梱bundleが古い | GHES管理者にCLI版を確認する |
CodeQL 2.26.2への対応で次に行うこと
Swift 6.3.3とKotlin 2.4.10への対応開始版はCodeQL 2.26.2です。GitHub.comの標準的なcode scanning環境では自動反映されるため、まず次回のワークフロー結果を確認します。
GHES、外部CI、ローカルCLIでは、次の順番で対応してください。
codeql versionを実行する- 2.26.1以前ならCodeQL bundleを更新する
codeql resolve languagesで対象言語を確認する- Kotlinでは
build-mode: noneを使用しない - SwiftとKotlinの通常ビルドが成功することを確認する
- モノレポでは
swiftとjava-kotlinを明示する - 更新後の新規アラートを差分確認する
- 検証後に本番ランナーへ展開する
重要なのは、CodeQL 2.26.2への更新だけで完了と考えないことです。バージョン、言語指定、ビルドモード、ランナー環境の4点をセットで確認することで、Swift 6.3.3とKotlin 2.4.10を安定して解析できます。
コメント