GitHub CodeQL Action 4.35.3更新の確認ポイント｜Dependabot PRの影響と対応手順

GitHub documentation update: ci(deps): bump github/codeql-action from 4.35.2 to 4.35.3 in the all group は、GitHub Actionsで使われている github/codeql-action を 4.35.2から4.35.3へ更新するDependabotのパッチ更新です。結論として、多くのリポジトリではCIとCode scanningのSARIFアップロードが正常に完了すれば、そのまま取り込める可能性が高い更新です。

ただし、今回の変更は「単なるバージョン番号の更新」と見て終わらせない方が安全です。対象PRでは .github/workflows/scorecard.yml の github/codeql-action/upload-sarif が、v4.35.2相当のコミットSHAからv4.35.3相当のコミットSHAへ差し替えられています。つまり、確認すべき中心はCodeQLの解析そのものだけでなく、SARIFファイルをGitHub code scanningへアップロードする処理が従来通り動くかです。(GitHub)

GitHub CodeQL Action 4.35.3への更新で何が変わったのか

今回のDependabot PRは、github/codeql-action を 4.35.2 から 4.35.3 に上げる更新です。PR本文では、更新対象は1件、依存関係は github/codeql-action、更新タイプは version-update:semver-patch、依存関係グループは all と示されています。(GitHub)

実際の差分では、次のように upload-sarif アクションの参照先が更新されています。

- name: Upload to code-scanning
  uses: github/codeql-action/upload-sarif@e46ed2cbd01164d986452f91f178727624ae40d7 # v4.35.3
  with:
    sarif_file: results.sarif

ここで重要なのは、今回の変更が github/codeql-action/init や github/codeql-action/analyze ではなく、github/codeql-action/upload-sarif の更新である点です。upload-sarif は、外部ツールやCIで生成したSARIFファイルをGitHubのcode scanningへアップロードするためのアクションです。GitHub Docsでも、SARIF互換ツールの結果をGitHub Actionsからアップロードする場合は github/codeql-action/upload-sarif を使うと説明されています。(GitHub Docs)

今回の更新は誰が対応すべきか

この更新に対応すべきなのは、主に次のようなリポジトリやチームです。

対象	対応の優先度	確認すべきこと
`github/codeql-action/upload-sarif` を使っているリポジトリ	高	SARIFアップロードが成功するか
Scorecard、ESLint、独自SASTなどの結果をSARIFでアップロードしているチーム	高	`sarif_file` のパス、権限、category設定
CodeQL ActionをコミットSHAで固定しているリポジトリ	中〜高	更新後のSHAとコメントの整合性
GitHub Enterprise Serverや古いCodeQLバンドルを使う組織	高	CodeQL 2.19.3以前を使っていないか
Dependabotのグループ更新を運用しているチーム	中	`all` グループの意味、ラベル設定、レビュー体制
Code scanningを使っていないリポジトリ	低	対象外の可能性が高い

all group という表現は「すべての依存関係が更新された」という意味ではありません。Dependabotのグループ設定により、条件に一致した更新が1つのPRにまとめられているという意味です。GitHub Docsでは、groups を使うと一致する依存関係の更新が1つのpull requestに結合されると説明されています。(GitHub Docs)

CodeQL Action v4.35.3の主な変更点

CodeQL Action v4.35.3のリリースノートでは、主に次の変更が示されています。リリース日は2026年5月1日です。(GitHub)

変更点	実務での意味	確認ポイント
CodeQL 2.19.3以前の利用者に非推奨警告を追加	古いCodeQL環境では次のマイナーリリース以降に影響が出る可能性	`tools` で古いCodeQL bundleを固定していないか
CloudsmithやGCP OIDCを使うprivate registry設定を受け入れる	プライベートなCodeQL packやregistry構成の互換性が改善	`registries` 設定、OIDC設定、認証トークン
private registryの接続テストが `HEAD` から `GET` へ変更	`HEAD` に対応しないregistryとの相性が改善	NuGet feedや独自registryでの接続エラー
同一ミリ秒内の診断情報が上書きされる不具合を修正	診断ログやtool statusの欠落が減る可能性	Code scanningの診断情報が正しく表示されるか
既定のCodeQL bundleを2.25.3へ更新	CodeQL解析やSARIF処理に使われる既定ツールが更新	解析結果、警告数、処理時間の変化

今回のPR自体は upload-sarif の参照更新ですが、同じ github/codeql-action リポジトリのリリースであるため、チーム内でCodeQL Action全体を使っている場合は init、analyze、upload-sarif のすべてをまとめて確認すると安全です。

まず確認すべき差分は「1行だけ」か

今回のPRでは、変更ファイルは .github/workflows/scorecard.yml の1ファイルで、差分は1行の追加・1行の削除です。具体的には、github/codeql-action/upload-sarif のコミットSHAが v4.35.2 から v4.35.3 に対応するSHAへ変更されています。(GitHub)

レビュー時は、次の3点を確認してください。

確認1: 変更ファイルが想定通り .github/workflows/scorecard.yml のみか
確認2: uses の参照先が github/codeql-action/upload-sarif のままか
確認3: コメントのバージョン表記とコミットSHAが一致しているか

特に、GitHub ActionsをコミットSHAで固定しているリポジトリでは、コメントだけ更新されてSHAが古いまま、またはSHAだけ更新されてコメントが古いままになると、後から監査しづらくなります。Dependabotの自動更新でも、レビュー時に「どのアクションを、どのバージョン相当に上げたのか」を明確にしておくことが大切です。

`upload-sarif` 更新後に確認するGitHub Actionsの設定

upload-sarif は、SARIFファイルをGitHub code scanningへアップロードするステップです。GitHub Docsでは、主な入力として sarif_file と任意の category が説明されており、複数の解析結果を同じコミットにアップロードする場合は、結果セットを一意に識別する必要があります。(GitHub Docs)

最低限、次の設定を確認してください。

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

steps:
  - name: Upload to code-scanning
    uses: github/codeql-action/upload-sarif@e46ed2cbd01164d986452f91f178727624ae40d7 # v4.35.3
    with:
      sarif_file: results.sarif

security-events: write は、code scanningへ結果をアップロードするうえで重要な権限です。GitHub Docsのサンプルワークフローでも、SARIFアップロード時の権限として security-events: write が示されています。(GitHub Docs)

複数のSARIF結果を扱う場合はcategoryを確認する

1つのリポジトリで複数の解析ツールを使う場合や、モノレポで複数領域を別々に解析する場合は、category を明示した方が管理しやすくなります。

- name: Upload SARIF file
  uses: github/codeql-action/upload-sarif@e46ed2cbd01164d986452f91f178727624ae40d7 # v4.35.3
  with:
    sarif_file: results.sarif
    category: scorecard

同じコミットに複数のSARIFファイルをアップロードする場合、GitHub Docsでは各分析にcategoryを指定する必要があると説明されています。categoryが曖昧だと、結果が上書きされたり、設定不備として扱われたりすることがあります。(GitHub Docs)

古いCodeQL環境を使っている場合の注意点

CodeQL Action v4.35.3では、CodeQL 2.19.3以前を使っている利用者に対して、今後の破壊的変更に向けた非推奨警告が追加されています。リリースノートでは、CodeQL 2.19.3以前はGitHub Enterprise Server 3.15とともに2026年4月9日に終了し、次のCodeQL Actionのマイナーリリースではサポート対象外になると説明されています。(GitHub)

特に確認すべきなのは、次のような設定です。

- uses: github/codeql-action/init@v4
  with:
    tools: https://example.com/codeql-bundle-old.tar.gz

CodeQL Actionの init には tools 入力があり、既定では推奨されるCodeQL Bundleを使いますが、ローカルパスやURLでCodeQL Bundleを明示的に指定することもできます。古いbundleを固定している場合は、今回の警告対象になる可能性があります。(GitHub)

実務では、次の順で確認すると判断しやすくなります。

確認項目	見る場所	判断基準
`tools:` を指定しているか	`.github/workflows/*.yml`	指定がなければ既定bundle利用の可能性が高い
CodeQL bundleのバージョン	Actionsログ、bundle URL、内部配布名	2.19.3以前なら更新を検討
GHESのバージョン	管理画面、運用ドキュメント	旧バージョン運用ならCodeQL対応状況を確認
CodeQL Actionの警告	Actionsログ	deprecation warningが出ていないか
解析結果の変化	Securityタブ、code scanning alerts	急な増減や欠落がないか

private registryやNuGet feedを使っている場合の影響

v4.35.3では、CloudsmithやGCP OIDCを使うprivate registry設定が受け入れられるようになり、private registryの接続テストでは HEAD ではなく GET が使われるようになりました。NuGet feedについては、接続テストがサービスインデックスに対して実行されるようになっています。(GitHub)

この変更は、CodeQL packやprivate registryを使っているチームにとってはプラスに働く可能性があります。たとえば、以前はregistry側が HEAD リクエストにうまく対応せず、接続確認だけで失敗していたケースでは、v4.35.3で改善する可能性があります。

一方で、次のような構成では更新後のActionsログを必ず確認してください。

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

GitHub Docsでは、GitHub Enterprise Server上に公開されたCodeQL packを使う場合、github/codeql-action/init@v4 の registries 入力でregistryのURL、packages、tokenを指定できると説明されています。(GitHub Docs)

Dependabot PRとして確認すべき運用上のポイント

今回のPRでは、Dependabotが「dependencies ラベルが見つからないため、PRに追加できない」というコメントも出しています。これは github/codeql-action の更新そのものとは別件ですが、Dependabot運用では見落としやすいポイントです。(GitHub)

dependabot.yml でラベルを明示している場合、リポジトリ側にそのラベルが存在しないと、PR作成後の分類やレビュー通知が期待通りに動かないことがあります。

確認例は次の通りです。

updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "dependencies"

このような設定があるなら、GitHubのリポジトリ設定またはIssue/PRラベル一覧で dependencies ラベルが存在するか確認してください。存在しない場合は、ラベルを作成するか、dependabot.yml から不要なラベル指定を削除します。

マージ前のチェックリスト

この更新はパッチ更新ですが、セキュリティ関連のGitHub Actionsであるため、次のチェックを済ませてからマージするのが安全です。

チェック項目	合格条件	問題がある場合の対応
差分確認	`upload-sarif` のSHA更新のみ	想定外のworkflow変更があれば保留
GitHub Actionsの実行	`scorecard.yml` のワークフローが成功	失敗ログの `upload-sarif` 周辺を確認
SARIFファイル	`results.sarif` が生成されている	生成ステップやパスを修正
権限	`security-events: write` がある	workflowのpermissionsを追加
Code scanning	Securityタブに結果が反映される	Code Security設定やSARIF形式を確認
古いCodeQL警告	CodeQL 2.19.3以前の警告がない	bundle固定やGHES環境を見直す
Dependabot設定	ラベルやグループ設定に不備がない	`dependabot.yml` とラベルを整理

よくある失敗と対処法

SARIFアップロードで権限エラーになる

upload-sarif で権限エラーが出る場合は、まずworkflowの permissions を確認します。特に security-events: write がないと、code scanningへのアップロードができません。

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

privateまたはinternalリポジトリでは、GitHub Code Securityの有効化も確認してください。GitHub Docsでは、private/internalリポジトリでcode scanningを使うには、GitHub Code Security機能が有効である必要があると説明されています。(GitHub Docs)

`sarif_file` のパスが実ファイルとずれている

今回の差分では sarif_file: results.sarif が使われています。これはリポジトリルートから見たパスとして扱われます。解析ツールが別ディレクトリにSARIFを出力している場合は、アップロード対象が見つからず失敗します。

with:
  sarif_file: ./artifacts/results.sarif

更新後に失敗した場合でも、Actionのバージョンが原因とは限りません。前段の解析ステップでSARIFが生成されているか、ActionsログとArtifactsを確認してください。

複数ツールの結果が上書きされる

Scorecard、ESLint、CodeQL CLI、独自SASTなど複数のSARIFを同じコミットへアップロードする場合、category が未設定だと結果管理が分かりづらくなります。

with:
  sarif_file: scorecard.sarif
  category: scorecard

with:
  sarif_file: eslint.sarif
  category: eslint

GitHub Docsでは、同じコミットに複数のSARIF結果をアップロードする場合、それぞれを一意に識別する必要があると説明されています。(GitHub Docs)

今回の更新を取り込む判断基準

今回の github/codeql-action 4.35.3更新は、基本的には取り込みを前向きに検討できるパッチ更新です。特に、SARIFアップロードやprivate registry周りの互換性改善、診断情報の欠落修正が含まれているため、code scanningを継続的に使っているチームにはメリットがあります。

一方で、次の条件に当てはまる場合は、すぐにマージせず検証環境や一部ブランチで確認してから進めるのが安全です。

GitHub Enterprise Serverを使っている
CodeQL bundleを tools で固定している
private registry、Cloudsmith、GCP OIDC、NuGet feedを使っている
複数のSARIFファイルを同じworkflowでアップロードしている
code scanningの結果をリリース判定や監査証跡に使っている

反対に、GitHub.com上の通常のリポジトリで、upload-sarif が1つの results.sarif をアップロードしているだけなら、CIの成功とSecurityタブへの反映を確認したうえでマージする判断がしやすい更新です。

次にやるべきこと

まず、Dependabot PRの差分が github/codeql-action/upload-sarif のSHA更新だけであることを確認してください。次に、PR上のGitHub Actionsを実行し、results.sarif のアップロード、code scanningへの反映、権限エラーの有無を見ます。

あわせて、古いCodeQL bundleを固定していないか、Dependabotの dependencies ラベルが存在するか、複数SARIFのcategory設定が適切かを確認しておくと、今回の更新だけでなく今後のCodeQL Action更新にも対応しやすくなります。

github/codeql-action の更新は、見た目は1行の差分でも、セキュリティ検査結果のアップロードや監査ログに関わる重要な変更です。パッチ更新だからと自動マージだけに任せず、Actionsログ、Code scanning結果、Dependabot設定の3点を確認してから取り込むのが実務上の安全な進め方です。

この記事を書いた人

佐藤健司

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