github/codeql-action 4.35.3更新の影響と確認ポイント｜CodeQL Action移行チェック

github/codeql-action 4.35.3 への更新は、単なるパッチ更新に見えても、CodeQL CLIを古いバージョンで固定している環境、プライベートレジストリを使う環境、SARIFアップロードをSHA固定しているワークフローでは確認が必要です。結論から言えば、github/codeql-action/*@v4 のようにメジャーバージョン指定している場合は多くのケースで自動的に取り込まれます。一方、v4.35.2 やコミットSHAで固定している場合は、4.35.3相当へ更新し、CodeQLの実行ログとコードスキャン結果を確認してください。

今回の更新は、Microsoftの agent-governance-toolkit リポジトリで2026年5月5日にマージされたDependabot PRで、github/codeql-action を 4.35.2 から 4.35.3 へ上げる内容です。対象はCodeQL解析だけでなく、upload-sarif を使ったSARIFアップロードにも及ぶため、セキュリティスキャン結果をGitHub Code Scanningに送っているリポジトリでは見落とさないようにしましょう。(GitHub)

github/codeql-action 4.35.3で確認すべき変更点

CodeQL Actionは、GitHub上のリポジトリに対してCodeQLによるコード解析を実行し、その結果をPull RequestやリポジトリのSecurityタブに表示するためのGitHub Actionsです。init、autobuild、analyze、upload-sarif など複数のActionで構成されており、通常のCodeQL解析だけでなく、外部ツールが生成したSARIFファイルのアップロードにも使われます。(GitHub)

4.35.3のリリースノートでは、主に次の変更が示されています。特に重要なのは、古いCodeQL CLIへの非推奨警告、プライベートレジストリ設定の改善、デフォルトCodeQL Bundleの更新です。(GitHub)

変更点	実務上の意味	確認すべき環境
CodeQL 2.19.3以前への非推奨警告	次のマイナーリリースで古いCodeQLがサポート対象外になる可能性がある	`tools` 入力などでCodeQL CLIを固定している環境
Cloudsmith / GCP OIDCを使うプライベートレジストリ設定を受け付け	これまで設定検証で弾かれていた構成が通る可能性がある	社内CodeQL pack、Private package、OIDC認証を使う環境
プライベートレジストリの接続テストが `HEAD` から `GET` に変更	`HEAD` を拒否するレジストリで接続確認が通りやすくなる	独自レジストリ、NuGetフィード、プロキシ配下の環境
同一ミリ秒に生成された診断結果が上書きされる不具合を修正	一部の診断が失われる可能性が低下する	CodeQLログや診断ファイルを詳細確認している環境
デフォルトCodeQL Bundleを2.25.3へ更新	クエリや言語パックの更新により、検出結果が変わる可能性がある	デフォルトBundleを使う通常のCodeQL解析環境

今回のPRで実際に更新されたワークフロー

PR #1731では、github/codeql-action の参照先が 4.35.2 のコミットSHAから 4.35.3 のコミットSHAへ置き換えられています。変更されたファイルは .github/workflows/ci.yml、.github/workflows/codeql.yml、.github/workflows/scorecard.yml の3つです。(GitHub)

ファイル	更新されたAction	影響する処理
`.github/workflows/ci.yml`	`github/codeql-action/upload-sarif`	BinSkimなど外部スキャン結果のSARIFアップロード
`.github/workflows/codeql.yml`	`init`、`autobuild`、`analyze`	CodeQLによるコード解析本体
`.github/workflows/scorecard.yml`	`upload-sarif`	OpenSSF Scorecardなどの結果アップロード

ここで重要なのは、CodeQL Actionの更新対象が「CodeQL解析ワークフローだけ」とは限らない点です。upload-sarif はサードパーティ製SASTツールやScorecardの結果をGitHub Code Scanningへ送る用途でも使われます。リポジトリ内で github/codeql-action を検索し、CodeQL専用ファイル以外のワークフローも確認してください。

対応が必要な人と不要な人

今回の github/codeql-action 4.35.3 更新で対応が必要かどうかは、ワークフローの指定方法で変わります。GitHubはAdvanced setupでCodeQL Actionを使う場合、@v4 のようなメジャーバージョンタグを参照すると、同じメジャーバージョン内の修正やCodeQL CLI更新を自動的に取り込めると説明しています。一方、パッチバージョンやコミットSHAで固定している場合は、Dependabotなどで継続的に更新する必要があります。(GitHub)

利用状況	対応要否	取るべき行動
CodeQLのDefault setupを使っている	低い	通常はワークフロー編集不要。Code scanningの警告だけ確認
Advanced setupで `@v4` を使っている	低〜中	手動更新は原則不要。ただし実行ログと警告は確認
`@v4.35.2` を使っている	高い	`@v4.35.3` または `@v4` へ更新
コミットSHAで固定している	高い	4.35.3のSHAへ更新し、Dependabot運用を確認
`@v3` を使っている	別途対応	v4移行計画を立てる。GHESのバージョン制約に注意
プライベートレジストリやNuGetフィードを使っている	中〜高	`registries` 設定、認証、CodeQL packの取得を再テスト
CodeQL CLIを独自に固定している	高い	2.19.3以前を使っていないか確認し、更新する

@v3 から @v4 への移行は、今回の4.35.3更新そのものとは別のテーマですが、放置しないほうがよい項目です。GitHubはCodeQL Action v4をNode.js 24ランタイムで提供しており、v3はGHES 3.19の非推奨時期に合わせて2026年12月に非推奨化予定としています。GitHub Enterprise Server 3.18以前はNode.js 24のActionを実行できないため、v4へ変える前にGHES側のアップグレードが必要です。(The GitHub Blog)

まず行うべき設定確認手順

最初に、リポジトリ内で github/codeql-action の利用箇所を洗い出します。CodeQL専用の codeql.yml だけでなく、CI、Scorecard、外部SAST、SARIFアップロード用ワークフローに含まれていることがあります。

grep -R "github/codeql-action" .github/workflows

ripgrep が使える環境なら、次のコマンドのほうが見やすくなります。

rg "github/codeql-action" .github/workflows

次に、参照形式を確認します。

参照形式	例	判断
メジャータグ	`github/codeql-action/analyze@v4`	更新を自動取得しやすい
パッチタグ	`github/codeql-action/[email protected]`	4.35.3へ手動更新が必要
コミットSHA	`github/codeql-action/analyze@95e58e9...`	4.35.3のSHAへ更新が必要
古いメジャー	`github/codeql-action/analyze@v3`	v4移行計画が必要

今回のPRでは、4.35.2相当のSHAから4.35.3相当の e46ed2cbd01164d986452f91f178727624ae40d7 へ更新されています。組織のセキュリティポリシーでSHA固定が必須の場合は、このようにSHAを明示的に差し替えます。運用負荷を下げたい場合は @v4 指定も選択肢ですが、サプライチェーン対策としてSHA固定を求める組織では、Dependabotとレビュー手順をセットで運用するのが現実的です。(GitHub)

# SHA固定を続ける場合の例
- uses: github/codeql-action/init@e46ed2cbd01164d986452f91f178727624ae40d7
  with:
    languages: ${{ matrix.language }}

- uses: github/codeql-action/autobuild@e46ed2cbd01164d986452f91f178727624ae40d7

- uses: github/codeql-action/analyze@e46ed2cbd01164d986452f91f178727624ae40d7

SARIFアップロードだけで使っている場合も同様です。

- uses: github/codeql-action/upload-sarif@e46ed2cbd01164d986452f91f178727624ae40d7
  with:
    sarif_file: results.sarif

CodeQL CLIを固定している環境は最優先で確認する

4.35.3で最も注意したいのは、CodeQL CLI 2.19.3以前を使っている利用者に対する非推奨警告です。リリースノートでは、これらのCodeQLバージョンは2026年4月9日にGHES 3.15とともに終了扱いとなり、次のCodeQL Actionのマイナーリリースではサポートされなくなると説明されています。(GitHub)

通常、github/codeql-action/init@v4 を使い、CodeQL CLIを明示的に固定していなければ、デフォルトBundleが使われます。4.35.3ではデフォルトCodeQL Bundleが2.25.3に更新されています。(GitHub)

確認すべきなのは、次のようなケースです。

確認項目	見る場所	対応
`tools:` 入力でCodeQL CLIを固定していないか	CodeQLワークフロー	古いCLIなら更新、不要なら指定を外す
独自DockerイメージにCodeQL CLIを同梱していないか	Dockerfile、CIイメージ	CLIのバージョンを更新
GHES環境で古いCodeQL Bundleを使っていないか	GHES管理画面、Actionsログ	GHESの対応バージョン表と照合
ログにCodeQLの非推奨警告が出ていないか	GitHub Actionsの実行ログ	次のマイナー更新前に解消

GitHub Enterprise Serverでは、GHESのバージョンによって利用できるCodeQL ActionやCodeQL Bundleが変わります。GitHubのREADMEにはGHESごとの最小CodeQL ActionとBundleの表が掲載されているため、クラウド版GitHubと同じ感覚で @v4 に変えるだけでは不十分な場合があります。(GitHub)

プライベートレジストリ利用時の確認ポイント

4.35.3では、CloudsmithやGCP OIDCを使うプライベートレジストリ設定が受け付けられるようになり、プライベートレジストリの接続テストも HEAD ではなく GET を使うように変更されています。NuGetフィードでは、接続テストが常にサービスインデックスに対して行われる点も押さえておきましょう。(GitHub)

GitHub Docsでは、CodeQL packをGitHub Enterprise Serverなどのレジストリから取得する場合、github/codeql-action/init@v4 の registries 入力に url、packages、token を指定する方法が示されています。パッケージパターンは上から順に評価されるため、より具体的なパターンを先に置くのが基本です。また、トークンには read:packages 権限を持つPersonal Access Tokenが必要です。(GitHub Docs)

- uses: github/codeql-action/init@v4
  with:
    languages: ${{ matrix.language }}
    registries: |
      - url: https://containers.example.com/v2/
        packages:
          - my-company/*
        token: ${{ secrets.CODEQL_REGISTRY_TOKEN }}

プライベートレジストリを使っている場合は、更新後に次の観点でログを確認してください。

症状	原因の例	対応
CodeQL packの取得に失敗する	URL、認証、パッケージパターンの不一致	`registries` の順序と `token` 権限を確認
更新前は接続確認で失敗していた	レジストリが `HEAD` を拒否していた	4.35.3で再実行し、`GET` で通るか確認
NuGetフィードだけ失敗する	サービスインデックスのURLや認証が不適切	NuGetのサービスインデックスに到達できるか確認
OIDC構成が通らない	Cloudsmith / GCP OIDC設定の不足	OIDCのaudience、issuer、権限設定を確認

この変更は「すべての認証エラーを自動で解決する」ものではありません。接続テストの互換性が上がったと捉え、実際のpack取得、クエリ実行、SARIFアップロードまで通るかを確認することが大切です。

更新後に見るべきGitHub Actionsログ

github/codeql-action 4.35.3 へ更新した後は、ワークフローが成功したかだけでなく、ログの警告も確認してください。特にCodeQL関連の警告は、今すぐ失敗していなくても次回以降のマイナーアップデートでビルド停止につながる可能性があります。

確認するログは、主に次のステップです。

ステップ	確認内容
`github/codeql-action/init`	CodeQL CLIのバージョン、言語検出、レジストリ認証、非推奨警告
`github/codeql-action/autobuild`	ビルド失敗、依存関係取得、コンパイル対象の不足
`github/codeql-action/analyze`	解析完了、診断ファイル、生成されたSARIF
`github/codeql-action/upload-sarif`	SARIFファイルのパス、カテゴリ、Code Scanningへのアップロード結果
外部SASTツール実行後	生成されたSARIFが存在するか、空でないか

CodeQL Bundleが更新されると、検出されるアラートの数や内容がわずかに変わることがあります。アラート数が増えた場合も、すぐに「新しい脆弱性が混入した」と決めつけず、クエリや言語パックの更新によって検出可能になったものかを確認しましょう。反対に、アラート数が減った場合も、対象言語、ビルドモード、除外設定、SARIFアップロードのカテゴリが変わっていないかを見ます。

よくある失敗と回避策

失敗しやすいポイント	なぜ起きるか	回避策
`codeql.yml` だけ見て `upload-sarif` を見落とす	外部スキャン結果のアップロードにもCodeQL Actionが使われる	`.github/workflows` 全体を検索する
コメントだけ `v4.35.3` に変えて実体は古いSHAのまま	SHA固定ではコメントは動作に影響しない	`uses:` の右側にあるSHAを確認する
`@v4` とSHA固定が混在する	ワークフローごとに運用ルールが違う	組織として更新方針を統一する
CodeQL CLIの固定に気づかない	`tools` 入力や独自CIイメージに隠れている	ワークフローとDockerfileを両方確認する
GHESでv4へ変えて失敗する	GHESのバージョンがNode.js 24 Actionに対応していない	GHES 3.20以降か、GitHub Connect要件を確認する
プライベートレジストリの警告を無視する	解析対象packの取得失敗が後続で影響する	`init` のログを詳細に確認する

特にSHA固定運用では、コメントの # v4.35.3 だけを見て安心しないことが重要です。GitHub Actionsで実際に使われるのは uses: に指定されたタグまたはSHAです。レビュー時には、コメントではなく uses: の値を確認してください。

Dependabotで継続的に更新する

今回のPRはDependabotによるGitHub Actions依存関係の更新です。PR本文でも、更新対象は github/codeql-action、バージョンは4.35.3、更新種別はsemver patchとして示されています。(GitHub)

GitHub Actionsの依存関係を定期的に追従するなら、Dependabotの設定を用意しておくと更新漏れを減らせます。

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

SHA固定を採用している組織では、DependabotのPRを自動マージするのではなく、次の条件を満たしたら取り込む運用が安全です。

確認項目	判断基準
CodeQLワークフローが成功している	`init`、`analyze`、`upload-sarif` が失敗していない
警告が増えていない	古いCodeQL CLIやGHES制約の警告がない
SARIFがアップロードされている	SecurityタブやCode scanning alertsに結果が反映される
アラート差分を確認した	Bundle更新による検出差分をレビューした
外部ツールの結果も維持されている	BinSkim、ScorecardなどのSARIFカテゴリが消えていない

今回の更新で取るべき次の行動

github/codeql-action 4.35.3 への更新は、多くのリポジトリでは大きな移行作業を伴わないパッチ更新です。ただし、古いCodeQL CLIを固定している環境、プライベートレジストリを使っている環境、SARIFアップロードを複数ワークフローで使っている環境では、影響範囲が広がります。

まず .github/workflows 全体で github/codeql-action を検索し、@v4、@v4.35.2、SHA固定、@v3 のどれに該当するかを分類してください。次に、固定している場合は4.35.3へ更新し、CodeQL CLIのバージョン、プライベートレジストリ、SARIFアップロード、Code scanning alertsの差分を確認します。

対応の優先順位は、次の順番が実務的です。

優先度	対応
高	CodeQL CLI 2.19.3以前の固定を解消する
高	SHA固定または `v4.35.2` 固定を4.35.3へ更新する
中	`upload-sarif` を使う外部スキャンワークフローを確認する
中	Cloudsmith、GCP OIDC、NuGetなどのプライベートレジストリを再テストする
中	DependabotでGitHub Actions依存関係の継続更新を設定する
低〜中	`@v3` 利用リポジトリのv4移行計画を立てる

今回のようなパッチ更新は、見た目の変更量が小さいほど後回しにされがちです。しかし、CodeQL Actionはセキュリティ検出、SARIFアップロード、GHES互換性、プライベートレジストリ認証に関わる基盤です。ワークフローが成功するかだけでなく、「警告がないか」「古いCLIを固定していないか」「スキャン結果がSecurityタブに反映されているか」まで確認しておくと、次のマイナーアップデート時のトラブルを減らせます。

この記事を書いた人

佐藤健司

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