MENU

CodeQL 2.25.3がSwift 6.3対応、GitHub code scanningの変更点と確認ポイント

WEBサービス

CodeQL 2.25.3は、GitHubのcode scanningで使われる静的解析エンジンCodeQLの更新版です。今回の最大のポイントは、Swift 6.3でビルドされたアプリの解析に対応したことです。SwiftプロジェクトをGitHubでセキュリティスキャンしている開発者は、まずCodeQLの実行環境、GitHub Actionsのワークフロー、GHES利用時のCodeQLバンドル更新状況を確認しましょう。

GitHubの公式Changelogでは、CodeQL 2.25.3について、Swift 6.3対応に加えて、C/C++向けクエリ5件のdefault code scanning query suiteへの追加、Python、Java/Kotlin、JavaScript/TypeScript、GitHub Actions関連クエリの精度改善などが案内されています。GitHub.comのcode scanning利用者には新しいCodeQLバージョンが自動展開され、GHESでは3.22リリースに含まれる予定です。(The GitHub Blog)

目次

CodeQL 2.25.3で何が変わったのか

CodeQL 2.25.3は、単に「Swift 6.3に対応した」だけの小さな更新ではありません。Swift対応は目立つ変更点ですが、実務上はC/C++の検出範囲拡大や、既存クエリの誤検知削減もあわせて確認する必要があります。

GitHubのcode scanningは、リポジトリ内の脆弱性やエラーを検出し、その結果をGitHub上のcode scanning alertsとして表示する仕組みです。CodeQLはその解析エンジンとして使われ、CodeQLデータベースを作成し、クエリを実行し、結果をアラートとして表示します。(GitHub Docs)

今回の主な変更は次の通りです。

対象変更内容実務上の影響
SwiftSwift 6.3でビルドされたアプリの解析に対応Swift 6.3へ移行したiOS/macOSアプリでもCodeQL解析を継続しやすくなる
C/C++5件のクエリがhigh precisionとなり、default query suiteに追加既存リポジトリで新しいcode scanning alertsが出る可能性がある
PythonPython 3.15に含まれる予定のlazy import ...構文に対応新しいPython構文を使うコードで解析の失敗や取りこぼしを避けやすくなる
Java/KotlinWoodstox StAXライブラリのXXE関連sink検出を強化XML処理を含むJava/Kotlinアプリで検出範囲が広がる可能性がある
JavaScript/TypeScriptFastifyのルート単位rate limitingを考慮Fastify利用時のrate limiting関連アラートがより実態に近づく
GitHub Actionsartifact poisoning関連のメッセージ改善、誤検知削減CI/CDワークフローのアラート内容が読み取りやすくなる

Swift 6.3対応の意味

CodeQL 2.25.3では、Swift 6.3でビルドされたアプリを解析できるようになりました。CodeQL公式Changelogでも、Swiftについて「Swift 6.3の解析を可能にするアップグレード」と説明されています。(CodeQL)

Swiftプロジェクトでは、コンパイラやXcodeの更新に伴って、静的解析ツール側が新しい構文やビルド環境に追従できないことがあります。解析ツールが対応していない場合、ビルド自体は通ってもCodeQLのデータベース作成や解析ステップで失敗することがあります。

今回の更新により、Swift 6.3へ移行したプロジェクトでも、GitHub code scanningによる継続的なセキュリティチェックを実施しやすくなります。

Swift開発者が確認すべきポイント

Swift 6.3対応を活かすには、CodeQLのバージョンだけでなく、解析時に実際に使われるビルド環境も確認が必要です。

特に確認したいのは次の項目です。

確認項目見るべき場所判断基準
CodeQLが新しいバージョンで動いているかGitHub Actionsの実行ログ、CodeQL init/analyzeステップCodeQL 2.25.3以降が使われているか
Swift 6.3のビルドがCI上で成功しているかGitHub ActionsのbuildステップローカルだけでなくCIでも同じSwift/Xcode環境でビルドできるか
手動ビルド手順が正しいか.github/workflows/codeql-analysis.ymlxcodebuildなどのビルド対象が解析したいソースを含んでいるか
アラートが急増していないかSecurity > Code scanning alerts新規検出か、解析条件変更による差分かを切り分ける

SwiftのCodeQL解析では、ビルドされたソースが解析対象になります。GitHub Docsでも、C/C++、C#、Go、Java、Kotlin、Swiftでは、手動ビルド手順でビルドされたソースコードがCodeQLの解析対象になると説明されています。(GitHub Docs)

そのため、Swift 6.3対応後に「解析は成功しているが期待したコードが検出対象になっていない」という状態を避けるには、CI上のビルドコマンドを見直すことが重要です。

たとえば、iOSアプリで一部のターゲットだけをビルドしている場合、未ビルドのモジュールは十分に解析されない可能性があります。xcodebuildのscheme、configuration、destination、workspace/projectの指定を確認し、セキュリティ上重要なコードがビルド対象に含まれているかをチェックしましょう。

GitHub.com利用者への影響

GitHub.comでcode scanningを使っている場合、多くの利用者はCodeQL 2.25.3を手動で導入する必要はありません。GitHubの公式Changelogでは、GitHub.comのcode scanning利用者にはCodeQLの新バージョンが自動的に展開されると説明されています。(The GitHub Blog)

ただし、「自動展開される」ことと「何も確認しなくてよい」ことは同じではありません。新しいクエリがdefault suiteに追加されると、これまで出ていなかったアラートが表示されることがあります。

特にC/C++リポジトリでは、今回5件のクエリがhigh precisionに昇格し、default code scanning query suiteに追加されました。対象クエリは、型幅の比較、整数乗算結果のキャスト、sizeofを使った疑わしい加算、フォーマット関数の引数型不一致、暗黙的な関数宣言です。(The GitHub Blog)

GitHub.com利用者がやるべきこと

GitHub.comでCodeQLを使っている管理者や開発者は、次の順番で確認すると効率的です。

手順作業目的
1直近のCodeQL workflow実行ログを確認CodeQL 2.25.3以降で解析されているか確認する
2code scanning alertsの新規発生を確認更新後に増えたアラートを把握する
3C/C++、Swift、GitHub Actions関連のアラートを優先確認今回の変更影響を受けやすい領域を先に見る
4誤検知と実修正が必要なものを分類開発チームが無駄な対応に時間を使わないようにする
5必要に応じてブランチ保護やアラート運用ルールを調整新規アラートでリリースフローが止まるのを防ぐ

CodeQLのdefault query suiteは、GitHub code scanningで標準的に実行されるクエリ群です。GitHub Docsでは、default suiteは高精度で誤検知が少ないクエリ群として説明されています。一方、security-extended suiteはdefault suiteに追加のクエリを含むため、より広く検出できますが、低信頼度の結果や誤検知が増える可能性があります。(GitHub Docs)

今回C/C++の一部クエリがdefault suiteに追加されたため、default setupのリポジトリでも新しいアラートが出る可能性があります。これは「問題が突然増えた」というより、「検出できる範囲が広がった」と捉えるべきです。

GHES利用者が注意すべき点

GitHub Enterprise Server、つまりGHESを利用している組織では、GitHub.com利用者とは確認ポイントが異なります。

GitHubの公式Changelogでは、CodeQL 2.25.3の新機能はGHES 3.22リリースに含まれる予定とされています。また、古いGHESを利用している場合はCodeQLバージョンを手動でアップグレードできると案内されています。(The GitHub Blog)

GHES環境では、CodeQL Action、CodeQLバンドル、セルフホステッドランナー、インターネット接続可否が絡むため、「GitHub.comでは自動だから同じように反映される」と考えると見落としが起きます。

GHES管理者の確認ポイント

確認項目なぜ重要か
利用中のGHESバージョンCodeQL 2.25.3が標準で含まれるか、手動対応が必要かを判断するため
CodeQL analysis bundleの同期状況オフライン環境では最新バンドルが取り込まれていない可能性があるため
GitHub Connectの設定GitHub.com上のActionsや関連リソースを利用できるかに影響するため
セルフホステッドランナーの環境Swift 6.3、Xcode、Python、Gitなど解析に必要なツールが揃っているかを確認するため
CodeQL Actionのバージョンワークフローが古いActionを参照していると、期待した解析環境にならない可能性があるため

GitHub Docsでは、GHESでcode scanningを使うには、Code SecurityまたはAdvanced Securityのライセンス、管理コンソールでのcode scanning有効化、解析を実行するVMまたはコンテナが必要とされています。さらに、GitHub ActionsでCodeQLを実行する場合は、セルフホステッドランナーの準備やCodeQL analysis bundleの扱いも重要です。(GitHub Docs)

インターネットに接続できないGHES環境では、CodeQL action sync toolを使ってGitHub.comからCodeQL analysis bundleをコピーする必要があります。同期ツールを構成すると、CodeQL Actionと関連するCodeQL analysis bundleの最新リリースを同期できます。(GitHub Docs)

Advanced setupを使っている場合の確認ポイント

CodeQLには、default setup、advanced setup、外部CIからのSARIFアップロードという複数の運用形態があります。GitHub Docsでは、default setupは言語、query suite、スキャンイベントを自動選択し、advanced setupはワークフローを追加してCodeQL Actionを使うカスタマイズ可能な方式として説明されています。(GitHub Docs)

CodeQL 2.25.3の影響を正しく確認するには、自社リポジトリがどの方式でcode scanningを実行しているかを把握する必要があります。

default setupとadvanced setupの違い

項目default setupadvanced setup
向いているケース標準設定で素早くCodeQLを有効化したい言語、ビルド手順、クエリ、実行条件を細かく制御したい
設定場所GitHub UI中心.github/workflows/codeql-analysis.ymlなど
query suiteUI上で選択可能ワークフローや設定ファイルで指定
Swiftなどのビルド制御自動構成に依存手動ビルドやカスタム手順を組み込みやすい
注意点細かい制御には不向きワークフローの保守が必要

Advanced setupでは、ワークフローを編集してCodeQLの実行条件を制御できます。GitHub Docsでは、advanced setupを使う場合、通常.github/workflows/codeql-analysis.ymlに定義されたCodeQL analysis workflowを編集し、スキャン頻度、OS、解析言語、非デフォルトクエリ、カスタム設定ファイルなどを調整できるとされています。(GitHub Docs)

ワークフローで確認したい設定例

Advanced setupを使っている場合は、次のような設定を確認しましょう。

name: "CodeQL"

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  schedule:
    - cron: '30 2 * * 1'

jobs:
  analyze:
    name: Analyze Swift
    runs-on: macos-latest

    permissions:
      security-events: write
      packages: read
      contents: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v4
        with:
          languages: swift

      - name: Build
        run: |
          xcodebuild \
            -workspace YourApp.xcworkspace \
            -scheme YourApp \
            -configuration Debug \
            -destination 'generic/platform=iOS'

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v4

この例で重要なのは、languages: swiftを指定するだけで満足しないことです。Swiftアプリでは、実際にどのworkspace、scheme、configurationをビルドするかによって解析対象が変わります。

また、CodeQL Actionのinitには、利用するCodeQL Bundleを指定するtools入力があります。CodeQL Actionはデフォルトで推奨バージョンのCodeQL Bundleを使いますが、toolsでローカルパスやURLなどを指定して上書きできます。(GitHub)

組織で独自にCodeQL Bundleを固定している場合、CodeQL 2.25.3が自動的に使われない可能性があります。tools:を指定しているワークフローは、必ずバンドルの取得元とバージョンを確認してください。

C/C++リポジトリでは新規アラートに備える

CodeQL 2.25.3では、C/C++で5件のクエリがhigh precisionに昇格し、default code scanning query suiteに追加されました。CodeQL公式Changelogでも、これらのクエリが今後default suiteで実行されると説明されています。(CodeQL)

対象となるクエリは次の通りです。

クエリ検出する問題の例確認ポイント
cpp/comparison-with-wider-typeループ条件で狭い型と広い型を比較変数の型変換で無限ループや境界ミスが起きないか
cpp/integer-multiplication-cast-to-long乗算後に大きい型へキャストキャスト前にオーバーフローしていないか
cpp/suspicious-add-sizeofsizeofを使った不自然な加算ポインタ演算やメモリサイズ計算の誤りがないか
cpp/wrong-type-format-argumentフォーマット関数の引数型不一致printf系関数で型とフォーマット指定子が一致しているか
cpp/implicit-function-declaration暗黙的な関数宣言ヘッダー不足や古いCコードの危険な呼び出しがないか

特に注意したいのは、cpp/implicit-function-declarationです。今回の更新では、build-mode: noneのデータベースに対しては、このクエリが結果を出さないように変更されています。理由は、そのモードでの結果がノイズが多く不正確だったためです。(The GitHub Blog)

つまり、C/C++でbuild-mode: noneを使っている場合、すべてのC/C++検出が増えるとは限りません。むしろ一部のアラートは出なくなる可能性があります。アラート数だけを見て「安全になった」と判断せず、build modeと解析対象をあわせて確認しましょう。

Python、Java/Kotlin、JavaScript/TypeScriptの変更点

SwiftやC/C++以外の開発チームにも影響があります。今回の更新では、複数言語でクエリや抽出器の改善が入っています。

Python

Python extractorは、Python 3.15に含まれる予定のlazy import ...とlazy from ... import ...構文に対応しました。(The GitHub Blog)

Python 3.15をすぐに本番利用する組織は多くないかもしれませんが、先行検証やライブラリ開発では新構文への対応が重要です。将来のPythonバージョンを見据えてCIを更新しているチームは、CodeQL解析が新構文で失敗しないか確認しておくと安心です。

また、py/bind-socket-all-network-interfacesクエリでは、global data-flow libraryを使うようになり、精度向上と検出増加が見込まれます。eventletやgeventのsocket.socketラッパーもsocket binding操作として認識されるようになりました。(CodeQL)

この変更により、0.0.0.0など全ネットワークインターフェースへのバインドに関するアラートが増える可能性があります。Webアプリや社内ツールでは、意図した公開範囲なのか、設定ミスなのかを確認しましょう。

Java/Kotlin

Java/Kotlinでは、java/xxeとjava/xxe-localがWoodstox StAXライブラリのsinkを検出するようになりました。具体的には、com.ctc.wstx.stax.WstxInputFactoryやorg.codehaus.stax2.XMLInputFactory2の直接利用が対象になります。(The GitHub Blog)

XML外部実体、いわゆるXXEは、設定次第でファイル読み取りやSSRFにつながるリスクがあります。Woodstoxを利用してXMLを処理しているアプリでは、新しいアラートが出た場合に優先度高めで確認する価値があります。

JavaScript/TypeScript

JavaScript/TypeScriptでは、js/missing-rate-limitingクエリがFastifyのルート単位rate limitingを考慮するようになりました。(The GitHub Blog)

Fastifyを使っているAPIで、すでにルート単位のrate limitingを設定しているにもかかわらずアラートが出ていた場合、CodeQL 2.25.3以降では誤検知が減る可能性があります。一方で、設定が抜けているエンドポイントは引き続き検出対象になります。

GitHub Actionsのアラートは読みやすくなる

CodeQL 2.25.3では、GitHub Actionsワークフローを対象とするクエリにも改善があります。

actions/artifact-poisoning/criticalとactions/artifact-poisoning/mediumでは、アラートメッセージとソース位置が改善されました。また、actions/missing-workflow-permissionsは、すべての呼び出し元がpermissionsを設定しているreusable workflowsで誤検知を出さないようになりました。(The GitHub Blog)

CI/CDのセキュリティアラートは、開発者が「どのworkflowのどの行を直せばよいか」をすぐ理解できることが重要です。アラート文が分かりやすくなると、セキュリティ担当者と開発チームのやり取りも短くできます。

ただし、メッセージが改善されても、ワークフローの権限設定が安全になるわけではありません。特に次の設定は、更新後に改めて見直しましょう。

permissions:
  contents: read
  security-events: write

必要以上にwrite-allや広い権限を与えているworkflowは、CodeQLの結果に関係なく見直す価値があります。再利用workflowを使っている場合は、呼び出し元と呼び出し先の両方でpermissionsの設計を確認してください。

管理者・開発者別の確認チェックリスト

CodeQL 2.25.3への対応は、管理者と開発者で見るべき観点が少し異なります。

管理者向けチェックリスト

チェック項目対応の目安
GitHub.comかGHESかを確認GitHub.comは自動展開、GHESはバージョンとバンドル更新を確認
GHESのバージョンを確認GHES 3.22未満では手動アップグレードや同期が必要になる可能性
default setup / advanced setupの利用状況を棚卸し高度な設定のリポジトリほど個別確認が必要
CodeQL Actionの参照バージョンを確認古いActionや独自バンドル固定がないか確認
新規アラートの運用ルールを確認リリース直前にアラート急増で混乱しないよう優先度を決める

開発者向けチェックリスト

チェック項目対応の目安
Swift 6.3プロジェクトのCIビルドを確認CodeQL解析前のビルドがCI上で成功しているか確認
C/C++の新規アラートを確認型変換、メモリサイズ計算、フォーマット指定子を重点的に見る
Pythonのネットワークバインド関連アラートを確認意図せず全インターフェースで待ち受けていないか確認
Java/KotlinのXML処理を確認Woodstox利用箇所でXXE対策ができているか確認
GitHub Actionsのpermissionsを確認必要最小権限になっているか確認

失敗しやすいポイント

CodeQLの更新対応でよくある失敗は、「バージョンが上がったかどうか」だけを見て終わってしまうことです。実際には、アラート運用、ビルド環境、クエリ設定まで含めて確認する必要があります。

アラート増加をすべて誤検知扱いする

CodeQLの更新後にアラートが増えると、「ツールの更新で増えただけ」と考えて一括でdismissしたくなるかもしれません。しかし、今回default suiteに追加されたC/C++クエリのように、実際のバグや脆弱性につながる問題を新たに検出できるようになったケースもあります。

まずは、アラートの種類ごとに分類しましょう。

分類対応
実際に修正すべき問題通常のバグ修正・セキュリティ修正として対応
設計上許容している挙動理由を記録してdismiss
解析条件の問題ビルド手順やCodeQL設定を修正
明らかな誤検知dismiss理由を残し、必要なら設定やクエリの調整を検討

Swiftのビルド環境だけ古いままにする

CodeQLがSwift 6.3に対応しても、GitHub Actions runner上のXcodeやSwiftツールチェーンがプロジェクト要件を満たしていなければ解析は成功しません。

ローカル開発環境でSwift 6.3へ移行したら、CIでも同じ前提でビルドできるかを確認してください。特にmacOS runner、Xcode選択、scheme指定、依存関係の取得手順は見落とされがちです。

GHESでCodeQLバンドルの更新を忘れる

GHESでは、インターネット接続の有無やGitHub Connectの設定によってCodeQL関連リソースの取得方法が変わります。閉域環境では、CodeQL 2.25.3の機能を使うために、CodeQL analysis bundleの同期や手動更新が必要になる場合があります。

「GHESの画面上でcode scanningが有効だから最新CodeQLも使えている」とは限りません。実際のActionsログやバンドルのバージョンを確認しましょう。

まず取るべき次のアクション

CodeQL 2.25.3 adds Swift 6.3 supportの対応で、最初にやるべきことは大きく3つです。

1つ目は、GitHub Actionsの直近のCodeQL実行ログを確認し、CodeQL 2.25.3以降が使われているかを見ることです。GitHub.comのdefault setupでは自動展開されますが、advanced setupや独自バンドル指定がある場合は実際のログ確認が欠かせません。

2つ目は、Swift 6.3、C/C++、GitHub Actions関連の新規アラートを優先的に確認することです。Swiftでは解析継続性、C/C++では新規default queryによる検出、GitHub Actionsでは権限やartifact利用の安全性が主な確認ポイントです。

3つ目は、GHES利用組織ではGHESバージョン、CodeQL analysis bundle、セルフホステッドランナーの環境を確認することです。特にオフライン環境では、CodeQL Action sync toolやGitHub Connectの設定を見直して、最新の解析バンドルを利用できる状態にしておきましょう。

CodeQL 2.25.3は、Swift 6.3対応によって新しいSwift開発環境への追従を進める一方で、複数言語の検出精度も改善しています。単なるバージョンアップとして流すのではなく、リポジトリごとの解析設定と新規アラートを確認し、開発チームが安全に次のリリースへ進める状態を整えることが重要です。

WEBサービス
セキュリティ GitHub Swift CodeQL Code scanning

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次