GitHub ActionsでCodeQLによるcode scanningを使っている場合、CodeQL 2.25.5のポイントは「ワークフローの実行仕様が変わる」ことではなく、「GitHub Actions関連の危険な書き方をより見つけやすくなる」ことです。特に、複合アクションのaction.yml/action.yaml内にある未固定のAction参照や、python -m、go runを使ったステップ周辺の検出強化に注意が必要です。GitHub.comのcode scanning利用者には新しいCodeQLが自動展開されますが、GitHub Enterprise ServerやCodeQL CLIを固定運用している環境では、バージョン確認と展開計画が必要になります。(The GitHub Blog)
GitHub Actions向けCodeQL 2.25.5の変更点を先に整理
CodeQL 2.25.5は、GitHub code scanningの静的解析エンジンであるCodeQLの更新です。公式Changelogでは、C/C++、Java/Kotlin、GitHub Actionsクエリの精度改善が案内されています。GitHub Actionsに絞ると、主な変更は次の3点です。(The GitHub Blog)
| 変更点 | 対象 | 実務上の影響 |
|---|---|---|
poisonable_stepsモデリングの拡張 | GitHub Actionsのステップ解析 | python -mで実行するスクリプトや、ディレクトリ指定のgo runなどが、注入リスクのある実行パターンとして追加で検出される可能性がある |
actions/unpinned-tagの検出範囲拡大 | ワークフロー、複合アクション | .github/workflowsだけでなく、action.yml/action.yaml内の未固定Action参照も検出対象になる |
| untrusted checkout系クエリの説明・名称の改善 | アラート確認画面、ヘルプ文書 | 「なぜ危険なのか」「どの部分が特権コンテキストなのか」を読み取りやすくなる |
管理者や開発者がまず見るべきなのは、新しく出たアラートが誤検知なのか、これまで見落としていたActionsサプライチェーンリスクなのかです。CodeQLの精度改善後は、アラート数が増えることがあります。これは必ずしも悪い変化ではなく、これまで検出できていなかった危険な構成が見えるようになった可能性があります。
CodeQL 2.25.5はGitHub Actionsの何を見ているのか
CodeQLは、コードや設定ファイルを解析して脆弱性やエラーを見つけ、GitHubのcode scanningアラートとして表示する仕組みです。GitHub Actions workflowsもCodeQLの解析対象に含まれており、言語識別子としてはactionsが使われます。(GitHub Docs)
GitHub Actionsのセキュリティでは、アプリケーションコードそのものとは別に、CI/CDパイプラインの設定が攻撃経路になります。たとえば、以下のようなケースです。
steps:
- uses: actions/checkout@v4
- run: python -m tools.release
- run: go run ./cmd/generatorこれらのコマンド自体が常に危険という意味ではありません。問題になるのは、信頼できないコードをチェックアウトした後に、権限の高いトークン、シークレット、キャッシュ、成果物、リリース権限などに触れるジョブで実行している場合です。
特にpull_request_target、外部コントリビューターのPull Request、フォーク由来のコード、共有セルフホストランナーを使うリポジトリでは、ワークフローの書き方がそのまま攻撃面になります。今回のCodeQL 2.25.5では、そのような危険な流れを見つけるためのモデルが広がっています。
poisonable_stepsの拡張で増える可能性があるアラート
CodeQL 2.25.5では、GitHub Actions向けのpoisonable_stepsモデリングが変更されました。公式変更ログでは、Pythonモジュールとして実行されるスクリプトや、ディレクトリに対するgo runが、追加のsinkとして検出されるようになったと説明されています。さらに、goと実際のサブコマンドの間にあるフラグを考慮するよう更新されています。(CodeQL)
この変更により、次のようなクエリで検出結果が増える可能性があります。
| 関連クエリ | 見るべき観点 |
|---|---|
actions/untrusted-checkout/high、actions/untrusted-checkout/critical | 信頼できないコードを、権限の高いコンテキストでチェックアウトしていないか |
actions/untrusted-checkout-toctou/high、actions/untrusted-checkout-toctou/critical | チェックアウト後にコードや参照がすり替わる余地がないか |
actions/cache-poisoning/poisonable-step、actions/cache-poisoning/direct-cache | キャッシュに信頼できない内容を混入させ、後続ジョブで実行していないか |
actions/artifact-poisoning/path-traversal | 成果物の展開先やパス処理により、意図しないファイル上書きが起きないか |
確認時は、アラートの有無だけでなく、該当ジョブが持つ権限を見ます。permissions: write-allのような広い権限、リリース作成、パッケージ公開、クラウド認証、署名、デプロイが絡むジョブは優先度を上げて確認してください。
よくある危険パターン
次のようなワークフローは、CodeQL 2.25.5以降の検出強化で見直し対象になりやすい構成です。
on:
pull_request_target:
jobs:
build:
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- run: python -m scripts.release_helper
- run: go run ./tools/publishこの例では、外部PR由来のコードをチェックアウトし、その後にPythonやGoのコードを実行しています。もし同じジョブ内で書き込み権限、シークレット、成果物アップロード、キャッシュ保存を扱っている場合、攻撃者がPR内のファイルを通じてCI/CDの実行経路に影響を与える余地が生まれます。
対策としては、次のように責務を分けるのが現実的です。
| 対策 | 実装の考え方 |
|---|---|
| 権限の低い検証ジョブと、権限の高い公開ジョブを分ける | PR検証ではcontents: readを基本にし、公開や書き込みは信頼済みブランチでのみ実行する |
| 信頼できないコードを実行する前提で設計する | PR由来コードの実行ジョブにはシークレットを渡さない |
| キャッシュキーと保存条件を見直す | 外部PRが生成したキャッシュを、mainブランチやリリースジョブで再利用しない |
| 成果物の展開先を固定する | アーティファクト展開時にパストラバーサルや上書きが起きないようにする |
actions/unpinned-tagが複合アクションのaction.ymlも解析
今回の変更で特に見落としやすいのが、actions/unpinned-tagの対象拡大です。CodeQL 2.25.5では、ワークフローファイルだけでなく、複合アクションのメタデータであるaction.yml/action.yamlも解析対象に加わりました。(The GitHub Blog)
これまで.github/workflows/*.ymlだけを確認していたチームは、次のようなファイルも確認する必要があります。
.github/actions/setup/action.yml
.github/actions/build/action.yaml
tools/github-actions/my-action/action.yml
社内で共有しているComposite Action用リポジトリのaction.ymlactions/unpinned-tagは、タグで参照された非イミュータブルなActionが、サプライチェーン攻撃によって信頼できないAction実行につながる可能性を指摘するクエリです。公式のQuery Helpでは、フル長のコミットSHAに固定することが、非イミュータブルなActionを固定リリースとして使う方法として説明されています。(CodeQL)
複合アクションで見つかりやすい例
たとえば、複合アクション内に次のような記述がある場合です。
name: setup-project
runs:
using: composite
steps:
- uses: tj-actions/changed-files@v44
- shell: bash
run: ./scripts/setup.shこのようなタグ参照は、見た目には分かりやすく、日常運用もしやすい書き方です。しかし、厳密なサプライチェーン対策では、タグが将来同じ内容を指し続ける保証が問題になります。
より堅牢にするなら、次のようにフル長のコミットSHAに固定し、コメントで元のバージョンを残します。
name: setup-project
runs:
using: composite
steps:
- uses: tj-actions/changed-files@c65cd883420fd2eb864698a825fc4162dd94482c # v44
- shell: bash
run: ./scripts/setup.shただし、すべてのActionを機械的にSHA固定すれば終わりではありません。固定後はDependabotや運用ルールで更新方法を決めておかないと、古いコミットを使い続ける別のリスクが生まれます。重要な判断基準は、そのActionがどの権限で、どのタイミングで、どのリポジトリ・成果物・シークレットに触れるかです。
影響を受けやすいリポジトリとチーム
CodeQL 2.25.5の影響は、GitHub Actionsを使うすべてのリポジトリで同じではありません。優先して確認すべきなのは、次のようなリポジトリです。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 外部コントリビューターのPRを受けるOSS、公開リポジトリ | 信頼できないコードがCIに入る機会が多い |
| 高 | リリース、パッケージ公開、デプロイをActionsで行うリポジトリ | ワークフロー侵害時の被害が大きい |
| 高 | 社内共通の複合アクションを提供しているリポジトリ | 1つのaction.ymlの問題が複数リポジトリに波及する |
| 中 | security-extendedまたはsecurity-and-qualityを有効にしているリポジトリ | actions/unpinned-tagなど追加クエリの影響を受けやすい |
| 中 | GitHub Enterprise Server、閉域網、セルフホストランナー利用環境 | CodeQLバンドルの同期やランナー要件を確認する必要がある |
GitHub Actions向けのCodeQLクエリは、defaultクエリスイートでは標準クエリが実行され、security-extendedを選ぶと追加クエリも実行されます。actions/unpinned-tagはQuery Help上でactions-security-extended.qlsとactions-security-and-quality.qlsに含まれるクエリとして示されています。(GitHub Docs)
そのため、「CodeQLを有効にしているのに未固定Actionのアラートが出ない」という場合は、GitHub Actionsの解析対象化、言語設定、クエリスイート設定を確認してください。
管理者が確認すべき設定
GitHub.comでは基本的に自動展開される
GitHub.comでGitHub code scanningを使っている場合、新しいCodeQLバージョンは自動的に展開されます。公式Changelogでも、github.com上のcode scanning利用者にはCodeQLの新バージョンが自動デプロイされると案内されています。(The GitHub Blog)
つまり、多くのGitHub.com利用者にとって、CodeQL 2.25.5のためだけにワークフローを書き換える必要はありません。ただし、次の確認は必要です。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| 新しいcode scanningアラート | RepositoryのSecurityタブ、OrganizationのSecurity overview | GitHub Actions関連の新規アラートが増えていないか |
解析対象にactionsが含まれているか | .github/workflows/codeql.yml | Advanced setupでactionsがmatrixに含まれているか |
| 追加クエリを使っているか | CodeQL workflowまたはCodeQL config | security-extended、security-and-quality、カスタムクエリの有無 |
| マージ保護への影響 | Rulesets、branch protection | 新規アラートでPRが止まる設定になっていないか |
GitHubのルールセットでは、必須ツールが指定した深刻度のcode scanningアラートを検出した場合や、解析が未完了の場合にPull Requestのマージを防ぐ設定ができます。CodeQL 2.25.5後にアラートが増えた場合、セキュリティ上は有益でも、リリース直前のPRが止まることがあります。(GitHub Docs)
Advanced setupではactions言語を確認する
CodeQLのAdvanced setupでは、ワークフローファイルで解析対象言語を指定します。GitHub Actions workflowsの言語識別子はactionsです。(GitHub Docs)
例として、Actionsも解析対象に含める場合は、matrixに次のような行が必要です。
strategy:
fail-fast: false
matrix:
include:
- language: actions
build-mode: none
- language: javascript-typescript
build-mode: noneリポジトリ作成時にはActionsワークフローが少なく、後からCI/CDが増えたケースでは、CodeQL設定にactionsが入っていないことがあります。GitHub Actionsのセキュリティを見たいなら、まずここを確認してください。
クエリスイートを確認する
未固定Action参照の検出を重視するなら、security-extendedまたはsecurity-and-qualityの利用を検討します。CodeQLのワークフローでは、github/codeql-action/initにqueriesを指定できます。公式ドキュメントでは、security-extendedはdefaultに加えて低 severity・低 precision のクエリも含み、security-and-qualityはさらに保守性・信頼性のクエリも含むと説明されています。(GitHub Docs)
- uses: github/codeql-action/init@v4
with:
languages: ${{ matrix.language }}
queries: security-extendedただし、security-and-qualityは検出範囲が広くなるぶん、運用チームが確認すべきアラートも増えます。最初から全リポジトリに広げるより、リリース権限を持つリポジトリや共通Actionsリポジトリで先に試すほうが安全です。
GitHub Enterprise Server利用者の注意点
GitHub Enterprise Serverでは、GitHub.comと同じタイミングで常にCodeQLが自動反映されるとは限りません。公式Changelogでは、CodeQL 2.25.5の新機能はGHES 3.22に含まれる予定で、古いGHESではCodeQLバージョンを手動アップグレードできると案内されています。(The GitHub Blog)
特に確認すべきなのは次の3点です。
| 確認項目 | 理由 |
|---|---|
| GHESのバージョン | CodeQL 2.25.5相当の解析が含まれるかを判断するため |
| CodeQLバンドルの取得方法 | インターネット接続あり、自動取得、同期ツール、手動配布で手順が変わるため |
| セルフホストランナーの要件 | CodeQL Action実行に必要なツールやPATH設定が不足すると解析が失敗するため |
GHES環境では、CodeQL Actionを使う場合にActionやCodeQL解析バンドルをアプライアンス側で利用可能にする必要があります。閉域網ではCodeQL Action sync toolでCodeQL解析バンドルをGitHub.comからサーバーへコピーする運用が案内されています。(GitHub Docs)
また、セルフホストランナーでCodeQL Actionsを実行する場合、GitがPATHに入っている必要があります。Python解析を行う場合にはPython 3の有無も確認対象です。(GitHub Docs)
開発者がすぐ確認できるチェック手順
ワークフローと複合アクションを検索する
まず、リポジトリ内でAction参照を洗い出します。GitHubのコード検索やローカルのripgrepで、次のファイルを確認します。
.github/workflows/*.yml
.github/workflows/*.yaml
**/action.yml
**/action.yamlローカルで確認する場合の例です。
rg "uses:" .github/workflows -g "*.yml" -g "*.yaml"
rg "uses:" . -g "action.yml" -g "action.yaml"見るべきポイントは、@v4、@main、@master、@latest、短いタグ名で外部Actionを参照していないかです。
# 見直し対象になりやすい例
- uses: some-org/some-action@v1
- uses: some-org/some-action@mainすぐに全件をSHA固定できない場合は、次の順で優先順位を付けます。
| 優先順位 | 対象 |
|---|---|
| 1 | シークレット、OIDC、クラウド認証、リリース、デプロイを扱うジョブ |
| 2 | 外部PRやフォーク由来のコードが関係するジョブ |
| 3 | 複数リポジトリから使われる社内共通の複合アクション |
| 4 | 読み取り専用のLint、テスト、ドキュメント生成ジョブ |
python -mとgo runの使い方を確認する
次に、CodeQL 2.25.5で検出強化されたパターンを探します。
rg "python\s+-m|go\s+run" .github/workflows -g "*.yml" -g "*.yaml"
rg "python\s+-m|go\s+run" . -g "action.yml" -g "action.yaml"見つけたら、次を確認します。
| 確認ポイント | 良い状態 |
|---|---|
| 実行されるコードの出所 | 信頼済みブランチ、固定済み依存、レビュー済みスクリプトのみ |
| ジョブの権限 | 必要最小限のpermissionsに絞られている |
| シークレットの有無 | PR由来コードを実行するジョブには渡さない |
| キャッシュ・成果物 | 外部PRが作った内容を特権ジョブで再利用しない |
| 実行タイミング | release/deploy/publish系ジョブとPR検証ジョブを分ける |
すぐにやりがちな失敗
アラート増加を「誤検知」と決めつける
CodeQLの更新後にアラートが増えると、開発現場では「急に壊れた」「ノイズが増えた」と受け止められがちです。しかし、今回のGitHub Actions向け変更は、見落とされていた実行経路や複合アクション内の未固定参照を見つけるための改善です。
まずは、アラートが指摘しているファイル、イベント、ジョブ権限、実行ステップを確認してください。除外やdismissは最後の手段です。
.github/workflowsだけを直して満足する
今回のactions/unpinned-tagの重要点は、複合アクションのaction.yml/action.yamlも対象になったことです。ワークフロー側がきれいでも、内部で呼んでいる社内Composite Actionがタグ固定の外部Actionを使っていれば、そこが指摘される可能性があります。
社内で「共通セットアップ」「共通ビルド」「共通デプロイ」用のComposite Actionを作っているチームは、各アプリケーションリポジトリよりも先に共通Action側を確認したほうが効率的です。
SHA固定後の更新ルールを決めない
Actionをフル長SHAに固定すると、タグのすり替えリスクは下がります。一方で、Actionの更新が手作業になり、セキュリティ修正を取り込み忘れる可能性があります。
運用では、次のようなルールを決めておくと破綻しにくくなります。
| ルール | 例 |
|---|---|
| SHA固定の対象 | 外部Action、特権ジョブで使うAction、社内共通Action |
| 更新頻度 | 月1回、または重要更新時 |
| レビュー観点 | 参照元リポジトリ、リリースノート、差分、権限変更 |
| 記録方法 | SHAの横に元タグや更新理由をコメントで残す |
CodeQL 2.25.5対応の実務チェックリスト
公開前・展開前の確認に使えるチェックリストです。
| チェック | 対応内容 |
|---|---|
CodeQLの解析対象にactionsが含まれている | Advanced setupのmatrixやlanguages設定を確認する |
| GitHub Actions関連の新規アラートを確認した | Code scanningアラートをactions/系Rule IDで絞り込む |
複合アクションのaction.yml/action.yamlを確認した | uses:で外部Actionをタグ参照していないか見る |
python -m、go runを使うステップを確認した | 信頼できないコードの実行や特権ジョブとの混在を避ける |
| マージ保護への影響を確認した | 新規アラートで重要PRが止まる場合の運用手順を決める |
| GHESや閉域網環境のCodeQLバンドルを確認した | GHESバージョン、同期ツール、CodeQL CLI固定有無を確認する |
| アラートのdismiss基準を決めた | 誤検知、受容リスク、修正予定を区別して記録する |
今回の変更で最初にやるべきこと
CodeQL 2.25.5のGitHub Actions向け改善では、ワークフロー構文の移行よりも、検出された結果をどう安全に運用へ落とし込むかが重要です。
まずは、CodeQLの解析対象にactionsが含まれているかを確認してください。次に、.github/workflowsだけでなくaction.yml/action.yamlを検索し、外部Actionのタグ参照、python -m、go run、権限の高いジョブを優先して見直します。GitHub.comではCodeQLの新バージョンが自動展開されるため、管理者は新規アラートとマージ保護への影響を確認するのが現実的な第一歩です。GHESや閉域網、CodeQL CLI固定運用の環境では、CodeQLバンドルのバージョンと展開方法を先に確認してください。
最終的には、「アラートを消す」ことではなく、「信頼できないコードが特権のあるCI/CD経路に入らない設計にする」ことが、今回のCodeQL 2.25.5対応で最も重要なゴールです。
コメント