GMO Flatt Security Blog

GMO Flatt Security株式会社の公式ブログです。プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

GMO Flatt Security株式会社の公式ブログです。
プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

GitHub Actionsの脆弱な構成の検知ツール、任せられる範囲と人が見極めるべきリスク

はじめに

こんにちは、GMO Flatt Security株式会社 セキュリティエンジニアの佐藤(@Nick_nick310)です。

これまで公開した記事にて、GitHub Actionsにおける攻撃手法や防御策、緩和策を解説してきました。

一方で、個々の脆弱性パターンと対策を把握できたとしても、管理しているリポジトリのワークフローを継続的・横断的に確認し続けるのは現実的ではなく、その負荷を下げる手段としてワークフローの脆弱な構成を自動で検知するツールが近年整備されてきました。

本記事では、まず主要な検知ツールを取り上げ、過去の侵害事例を検知ツールがどこまでカバーできたかを考察し、ツールに任せる範囲とツール外で対応する範囲を切り分けます。 記事の最後では、こうしたツール外の確認を弊社がどう支援しているかも簡単に触れます。

なお、本記事で扱う「検知ツール」は、AIを使用せずにルールベースで検知するものを表しています。

1. 主要な検知ツールと使用方法

本記事で取り上げるツールを簡単に紹介します。検知ツールの観点は大きく2種類に分かれます。

GitHub Actionsワークフローの記述を見る観点と、リポジトリ設定を見る観点です。 前者は静的解析が多く用いられ、後者はGitHub APIから取得した設定値を分析する形が主流です。

各検知ツールの特徴

まずは各種ツールの全体像を示します。詳細はそれぞれの章をご確認ください。

ツール 検知範囲の中心 ワークフロー記述観点 リポジトリ設定観点 無償で使える条件 本記事で使用したバージョン
CodeQL Script Injection、信頼できないartifact、GITHUB_ENV 等 ◎ × オープンソースのみ 2.20.5 (codeql-bundle)
zizmor 危険なトリガー、過剰な権限、ピン留め、Self-hosted runner等 ◎ × 制限なし 1.25.2
OpenSSF Scorecard ブランチ保護、レビュー、依存関係、ピン留め等 △ ◯ 制限なし 5.1.1
poutine LOTP、Script Injection、危険なトリガー等 ◯ × 制限なし 1.1.4
checkov Script Injection、過剰な権限 (一部) △ ◯ 制限なし 3.2.524

CodeQL

CodeQL1はGitHubが提供するコード解析エンジンで、2024年からGitHub Actionsのワークフローも解析対象に加わりました。Script Injectionや信頼できないartifactの使用など幅広く検知することが可能です。

CodeQLの強みはワークフローの記述を見る観点に特化していることです。ルールは約26項目用意され、様々なパターンに対応できるようになっています。また、コード解析エンジンという特徴から、APIにアクセスしてリポジトリ設定を見る機能は用意されていません。

なお、CodeQLが無償で使用できるのは、オープンソースのコードに限られます2。法人環境などで、クローズドソースに対して使用する場合は、有償ライセンスが必要なことには注意してください。

検知ルールの詳細は以下URLをご確認ください。
https://codeql.github.com/codeql-query-help/actions/

zizmor

zizmor3は、GitHub Actionsワークフローに特化した静的解析ツールです。Script Injectionや過剰な権限設定といったYAMLの記述から判定可能な問題を幅広く検知できます。一方で、リポジトリ設定を監査する機能は持っていません。

検知ルールの詳細は以下URLをご確認ください。
https://docs.zizmor.sh/audits/

OpenSSF Scorecard

OpenSSF Scorecard4は、Open Source Security Foundation（OpenSSF）が提供するリポジトリ全体のセキュリティプラクティス評価ツールです。ブランチ保護、コードレビュー、依存関係管理など、リポジトリの運用全般を約20項目のチェックで採点します。結果は各チェック0〜10点のスコアと総合スコアで表示されます。
ワークフローの記述観点については、特にリスクが高い「信頼できないpull requestのcheckout」「Script Injection」「過剰なワークフロー権限」「依存関係のピン留め」のみを評価します。

検知ルールの詳細は以下URLをご確認ください。
https://github.com/ossf/scorecard/blob/main/docs/checks.md

poutine

poutine5は、BoostSecurityが開発したCI/CDパイプラインのセキュリティスキャナです。他のツールにはない特徴として、LOTP（Living Off The Pipeline）の検知があります。LOTPとは、設定ファイルや入力を介して任意コード実行が成立する仕様を持つコマンドを悪用する攻撃手法です。poutineはその原因となるコマンド呼び出しを検知します。たとえば、eslintのように一見RCEと結びつかないコマンドでも、設定ファイル経由で任意コードを実行しうるため検知対象になります。
なお、リポジトリ設定を監査する機能は持っていません。

検知ルールの詳細は以下URLをご確認ください。
https://github.com/boostsecurityio/poutine/tree/main/docs/content/en/rules

checkov

checkov6は、Prisma Cloudが提供するIaC向けのポリシースキャナです。
特徴的なのは、APIを経由してリポジトリの設定を検査できることです。約28項目のルールを持っており、「ブランチ保護ルールによるpush制限の有無」や「2FA設定の有無」などを検査することができます。
また、ワークフローの記述も一部検査することができ、「Script Injection」「過剰なワークフロー権限」を検知可能です。

検知ルールの詳細は以下URLをご確認ください。
https://www.checkov.io/5.Policy%20Index/github_actions.html
https://www.checkov.io/5.Policy%20Index/github_configuration.html

検知ツールをワークフローに組み込む

ここで紹介したツールは、いずれもSARIF(静的解析結果の標準フォーマット)出力に対応しています。
GitHub Actionsでは、security-events: write権限を付与したジョブからSARIFファイルをアップロードすると、結果がCode scanning alertsに表示されます。検知結果はツールごとに別の画面を開かなくてもCode scanning alertsで横断的に確認できます。

一部の検知ツールは公式がActionsを提供しており、簡単に組み込むことができます。
例えばzizmorをPRごとに動かす最小構成は次のようになります。

name: zizmor

on:
  pull_request:

permissions:
  contents: read
  security-events: write

jobs:
  zizmor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: zizmorcore/zizmor-action@5f14fd08f7cf1cb1609c1e344975f152c7ee938d #v0.5.6

なお、privateリポジトリでCode scanningを使用するには、Teamプラン以上が必要なことには注意してください。

Code scanningの検知画面は以下のようになります。

2. 侵害事例で脆弱だった構成をツールは検知できたか

これまでに発生した代表的な侵害事例を取り上げ、本記事で扱った検知ツールがどこまで見えていたか、どこから見えなかったかを整理します。

取り上げるのは tj-actions、nx、cline、trivy の4事例です。それぞれ脆弱だったポイントが異なり、検知ツールがどの起点に対応できているのかを横並びで整理するために、この4事例を順に見ていきます。

tj-actions/changed-files (2025年3月)

GitHub Action tj-actions/changed-files の事例です。tj-actions/changed-filesが使用している外部Actionの侵害で影響範囲が広がり、23,000以上のリポジトリに影響しました。

侵害は以下の4ステップで行われました。

  1. reviewdog 組織のメンテナの Classic PAT が窃取される
  2. reviewdog 提供 Action のタグが悪意あるコミットに付け替えられる
  3. tj-actions/changed-files のワークフローが改竄されたActionを実行し、tj-actions 側の PAT も窃取
  4. tj-actions/changed-files のタグが悪意あるコミットに付け替えられる

以下の表に、検知ツールごとのカバレッジを示します。

tj-actions/changed-filesリポジトリが使用する外部Actionの脆弱だったポイント

脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
Classic PATの使用 × × × × ×
Immutable Releasesの未使用 × × × × ×

tj-actions/changed-filesリポジトリの脆弱だったポイント

脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
外部Actionのピン留め未使用 ○ ○ ○ × ×
Classic PATの使用 × × × × ×
Immutable Releasesの未使用 × × × × ×

tj-actions/changed-filesを使用する各リポジトリの脆弱だったポイント

脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
外部Actionのピン留め未使用 ○ ○ ○ × ×

この侵害は、タグが悪意あるコミットに付け替えられることの恐ろしさを世に広めた事例となりました。
この事例から数ヶ月後に、GitHub公式がImmutable Releasesをリリースしたことからもその重要性が見て取れます。

nx (2025年8月)

モノレポ管理ツール nx が侵害された事例です。 nxの侵害は5ステップで構成されていました7。

  1. PR検証ワークフローでPRタイトルからScript Injectionが成立
  2. 窃取されたGITHUB_TOKENで新規ブランチを作成
  3. そのブランチにpublish.ymlを悪意ある内容に差し替えた状態で配置
  4. workflow_dispatch経由でAPIから起動
  5. 起動されたpublish.ymlがNPM_TOKENを持ったまま悪意あるスクリプトを実行し、トークンを外部に送信
脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
Script Injection ○ ○ ○ ○ ○
ワークフローのデフォルト権限の使用 ○ ○ ○ ○ ○
ワークフローのデフォルト権限がwriteである × × ○ × ×
Environments保護ルールの欠如 × × × × ×
静的なnpmトークンの使用 × ○ × × ×

nxの事例で特徴的なのは、masterブランチに対してはブランチ保護があったことです。
そのため攻撃者は、masterブランチに直接pushすることができず、新規ブランチを作って悪意あるワークフローを実行する必要がありました。こうしたケースでsecretsへのアクセスを絞る手段が「Environments保護ルール」ですが、Environments保護ルールが設定されていないことはどのツールも検知しませんでした。
nxは侵害対応の一環としてCodeQLを導入し、npm trusted publishingを使用するようになりました8。

cline (2026年2月)

AIエージェントであるclineが侵害された事例です。 clineの侵害は5ステップで構成されていました。

  1. AIトリアージワークフローのanthropics/claude-code-actionにallowed_non_write_users: "*"が設定されており、GitHubアカウントを持つ任意のユーザーが起動できる状態
  2. 攻撃者がIssueタイトルにprompt injectionを仕込み、AIエージェントを起動
  3. AIエージェントがBashツール経由で任意コマンドを実行
  4. キャッシュポイズニングを経由してNightlyリリースワークフローに横移動
  5. VSCE_PAT・OVSX_PAT・NPM_RELEASE_TOKENが窃取される
脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
AIエージェントへの過剰な権限付与 × × × × ×
任意のユーザーがAIエージェントをトリガー可能 × × × × ×
キャッシュポイズニング ○ ○ × × ×
静的なnpmトークンの使用 × ○ × × ×

「キャッシュポイズニング」と「静的なnpmトークンの使用」だけが検知できることが見て取れます。

clineの事例で特徴的なのは、「ツール側のルールがまだ追いついていない範囲」が侵害の起点になっている点です。
AIエージェント特有の設定はワークフローに書かれているにもかかわらず、現状どのツールも検知しません。

trivy (2026年2月、3月)

脆弱性スキャナ trivy が侵害された事例です。 trivyへの侵害は2段階あり、それぞれ性質の違うものでした。

2月の第1次攻撃は2ステップで構成されていました。

  1. 自動探索を行うAI bot「hackerbot-claw」が apidiff.yaml の pull_request_target を悪用
  2. 組織スコープの ORG_REPO_TOKEN を窃取

3月の第2次攻撃は2ステップで構成されていました。

  1. Imposter Commits（fork由来のorphan commit）の手法を使用
  2. aquasecurity/trivy-action のほぼ全てのタグが悪意あるコミットに付け替え

1度目の侵害対応が完全ではなく、攻撃者の足がかりが組織内に残った状態のまま、2度目の侵害が成立した形です。

■ trivyリポジトリの脆弱だったポイント

脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
信頼できないcheckout（pwn request） ○ ○ ○ ○ ×
Classic PATの使用 × × × × ×
Immutable Releasesの未使用 × × × × ×

■ trivyを使用する各リポジトリの脆弱だったポイント

脆弱だったポイント CodeQL zizmor Scorecard poutine checkov
外部Actionのピン留め未使用 ○ ○ ○ × ×

起点となる「信頼できないcheckout」はcheckovを除く4ツールが検知可能でした。そこから先の権限面や、侵害された際の防御であるImmutable Releasesは検知できないことが読み取れます。

trivyの事例で特筆すべきは、対策機能に対する検知ツール側の追従の遅れです。タグ書き換え攻撃を構造的に防ぐ機能としてImmutable Releasesが2025年8月にリリースされましたが、2026年6月19日時点では、本記事で取り扱う5ツールは対応していません(2026年5月26日にLaravelが提供したツールを使用することで検知が可能です9)。

もっとも、trivy自身は侵害対応の一環として設定の有効化を進めており、リポジトリを確認すると侵害後にリリースされたタグはImmutableになっていることが確認できます。Immutable Releasesの導入は始まりつつありますが、リポジトリ単位で有効化されているかを汎用ツールで検知する手段は整っていません。

3. 検知ツールに任せられること

2章では、過去の侵害事例に対して検知ツールがどの観点に対して有効かを見てきました。2章の観察から、検知ツールに安心して任せられる領域が2点見えてきました。本章ではそれぞれを整理します。

確実に脆弱となる構成を検知できる

検知ツールは、「確実に脆弱となる構成」を検知できます。その代表がScript Injectionです。

たとえば${{ github.event.issue.title }}のような外部コンテキストをrun:内で直接展開しているケースは、5つのツール全てが検知します。

Script Injection以外にも、permissions:未設定や外部Actionのピン留め未使用といった構成は、複数のツールが揃って検知します。これらはYAMLの文面だけで判定できるため、ツール側の認識が揺れにくく、信頼度が高い検知となります。

潜在的に脆弱な構成を一部検知できる

検知ツールは、明確に脆弱ではなくても、潜在的に脆弱となりうる構成を一部検知できます。
たとえばzizmorのdangerous-triggersは、pull_request_targetやworkflow_runを使っているだけでアラートを出します。
そのワークフローが本番リリース用なのかlintだけなのかは判定しないため、同じ警告でも実リスクはワークフローの中身次第で変わります。

このタイプの検知は「リスク候補」のリストとして扱うのが現実的です。dangerous-triggersが出た時点で即対応するのではなく、該当ワークフローが本番リリースに関与するか・書き込み権限を持つかを確認した上で優先度を決めます。トリアージの難しさは5章で扱います。

4. 検知ツール外で確認すべきこと

3章を見ると、検知ツールで実施可能な範囲は意外と狭いことがわかります。そのため、不足している点を確認するには検知ツール外で別途確認する必要があります。この章では、それらの代表的な3つを紹介します。

権限は最小限にできているか

権限が最小限に設定されているかどうかは、ツールでは検知することができません。

事例で振り返ると、tj-actionsの侵害ではreviewdog組織のメンテナのClassic PATが起点となり、tj-actions/changed-filesまで横移動が広がりました。
trivyの侵害では組織全体をスコープとしたトークンが窃取され、Aqua Security組織内の33以上のワークフローに影響しています。Fine-grained PATであればリポジトリ単位・権限単位で範囲を絞れるため、これらの事例では、影響範囲は大きく抑えられた可能性があります。Fine-grained PATの設計についてはVol.2で扱っているので、合わせて参照してください。

デプロイ時に使用するWorkload Identity Federationにおいても、信頼ポリシー側で制限しなければ、Organization配下のどのワークフローからでもロールを引き受けられる状態になる可能性があります。
これはVol.3で扱っているので、こちらも合わせて参照してください。

Environments保護ルールとブランチ保護は設計通りか

ブランチ保護と Environments保護は、Vol.3で取り上げたように、同時に設定することで有効度が上がります。
検知ツールでは、checkovが「ブランチ保護ルールに対してこれらの制限がされているか」といった内容を報告します。しかし、その設定が設計上の意図と合っているか(有効性、範囲、目的など)までは、ツールでは考慮できません。

nxの侵害では、masterブランチには保護が設定されていましたが、それ以外のブランチには保護がなく、攻撃者は新規ブランチ上に作成した悪意あるワークフロー経由でnpmトークンを取得しました。
Scorecardはデフォルトブランチとリリースブランチしか見ないため、masterに保護があったnxのケースでは「保護は問題ない」と評価してしまい、新規ブランチが起点となる攻撃を検知できません。

Environments保護ルールについても同様で、ワークフローYAMLに environment:が指定されているかは検知できても、「承認者が設定されているか」「許可ブランチが絞られているか」まで踏み込むツールは現状ありません。検知だけを信頼するのではなく、リポジトリ設定の画面で実際の運用が設計通りになっているかを確認する必要があります。

使用しているActionのパラメータは安全な値になっているか

検知ツールは、サードパーティが提供するActionに固有のパラメータ全てを網羅することができません。Actionの数が多く、新しく登場するActionに対するルール整備はどうしても後手に回るためです。

例外として、よく使われるActionについては一部のツールが対応しています。例えばzizmorは、キャッシュポイズニング(actions/cache)を誘発しうる設定を検知できます。

直近でいうとAIエージェント(anthropics/claude-code-action)が該当します。
2026年6月19日時点で筆者が確認した範囲では、AIエージェントを使用するワークフローの設定を検知するツールはありませんでした10。
しかし、現実にはAIエージェントを経由した侵害が発生しています。clineの侵害では allowed_non_write_users: "*" によって任意のユーザーがAIエージェントをトリガー可能な状態でした。

導入するActionが増えるほど、それぞれのドキュメントを確認し、危険な値になっていないかは人間が確認するしかありません。

AIエージェント関連で具体的に確認すべき観点（許可ツール / 許可ユーザー範囲 / トリガーが渡すコンテキスト）はVol.1で扱っているので、合わせて参照してください。

5. 検知事項をトリアージするうえでの実運用上の課題

ここまでは検知ツールができることや検知ツール外で確認することを整理してきました。この章では、筆者が実際のリポジトリで試して判明した運用上の具体例を3つ紹介します。

検知数が積み上がりやすい

GitHub Actionsの検知では数百件単位の検知事項が溜まりやすいです。実際にこの記事の検証用に動かしただけでも、以下の図のように数百件規模の検知事項が溜まりました。

運用上許容するものもあると思いますが、ツールは構成依存のリスク判断を行わず検知事項を出します。
組織に合わせた明確なトリアージルールが無い場合、「ただただ検知だけする」という状況になってしまうことも考えられます。

検知数が積み上がる背景にはツール側の構造的な事情があります。zizmorはコメントによる個別抑制が可能11ですが、Code scanning alerts側の一括dismissとは連動しません。複数のツールを併用していると同じScript Injectionを別ルール名で報告するため、検知が重複します。実際の検証では、zizmorのtemplate-injectionとCodeQLのactions/code-injectionが同じpull_request.titleの展開箇所を別々に報告していました。

Severityをそのまま使えない例がある

検知結果にはSeverity(深刻度)が含まれます。ただし、これはカテゴリごとに固定された値であり、組織の文脈は反映されていません。Severityが示すのはツール側の標準的なリスク評価であって、組織にとっての実リスクとは別の指標です。

具体的には、zizmorが報告する dangerous-triggersは、pull_request_target や workflow_run トリガーが使用されている場合に検知し、SeverityはHighです。
しかし、そのワークフローでどのような処理がされているかまでは仕組み上報告できません。書き込み権限を持つジョブを実行しているのか、lintだけを走らせているのかで、現実のリスクは大きく変わります。

そのため、Severityを自組織のリスクに変換するには、各検知事項がどのワークフロー文脈で出ているかを踏まえたトリアージが必要になります。ツールのアラートだけでは、「この検知事項は即座に対処すべきか、後回しにしてよいか」を判断するのに必要な文脈が足りません。

ツールが返す対策が具体的でないことがある

ツールが提示する対策は一般論に留まるものが多いです。しかし、一部のツールはかなり具体的な対策を提示してくれます。たとえばpoutineはRemediationとして、対策の方針やアンチパターンを丁寧に記載しています。

ただし、poutineの検知範囲はそれほど広くありません。検知範囲が広いツールでも、過剰な権限設定に対して「権限はジョブごとに分離してください」という抽象的な記述にとどまることが多く、対象のワークフローを具体的にどう書き換えるかまでは踏み込みません。修正方針を組み立てる段階では、ワークフローや組織の文脈を理解した人間の判断がもう一度必要になります。

6. 現実に沿ったリスクを評価して対策に繋げるためには

ここまでで「単体の脆弱性をいかに確認するか」という点を見てきました。実際の運用フローでは、検知した脆弱性のリスクを評価し、対応する必要があります。この章では、実際に確認された脆弱性をどのようにリスク評価して対策に繋げていくかを見ていきます。

組織全体を見てリスクを評価する

これまで確認してきたものは脆弱性単独の評価でした。現実に即したリスクにするためには、組織全体を見て評価する必要があります。

例えば、「pull_request_targetトリガーの誤用により任意コードが実行可能」という脆弱性単体では、直接的なリスクは発生しません。ここから実際のリスクに繋げるためには、「ワークフローのデフォルト権限が強い」や「他ワークフローにキャッシュポイズニングの脆弱性がある」などが存在する必要があります。

このように、実際のリスクを考えるためには、組織全体を見て脆弱性が連鎖するかどうかや構成次第で脆弱性がリスクとなりうるかを考慮する必要があります。

実際の侵害事例を元に、具体的に見ていきましょう。

nxの侵害は5ステップで成立しましたが、各ステップは単体ではよくある構成です。pull_request_targetトリガーを使用していることによる検知と、contents: write権限を使用していることによる検知は、それぞれ個別の検知事項として並びます。
しかし、その2つの検知事項が「pull_request_targetトリガー経由で、contents: write権限を持つジョブのワークフローのGITHUB_TOKENを奪う」という連鎖になることは、ツールからは報告できません。構成によっては、「contents: write権限を持つGITHUB_TOKENを使用して新規ブランチを作成し、secretsを奪取する」まで連鎖します。連鎖として認識するためには、リポジトリ全体の権限・トリガー・secretsの配置を横断する必要があります。

多層防御の観点で対策を行う

個別の脆弱性を一つひとつ潰しても、「多層防御が機能していない」という構造的な課題が残ることが多くあります。
GitHub Actionsにおける脆弱性の対策は単体で完結するものが少なく、複数の対策が組み合わさって初めて防御として機能するものが多いためです。

そこで、検出された脆弱性に対する対応方針を「侵害の抑止」「被害の局所化」「追跡可能性」の3つの軸で整理してみます。

「侵害の抑止」は、GitHub Actionsに対する初期侵入の経路を防ぐことを表します。主にVol.1で取り上げた対策を行うことで実現可能です。

「被害の局所化」は、侵害後の影響を最小限にとどめることを表します。主にVol.2やVol.3で取り上げた対策を行うことで実現可能です。

「追跡可能性」は、侵害が事後に判明したとき、どのリリースのどのバージョンが影響を受けたかを検証できることを表します。対策にはrunner上の挙動記録をすることが有効です。通信先、実行されたコマンド、アクセスされたファイル、起動されたプロセスを記録しておくことで、事後の調査を詳細に行うことができます。この記録は、GitHub公式が発表したロードマップにて実装が予告されていますが、2026年6月19日段階ではまだ実装されていません12。そのため、弊社が提供するTakumi Runnerのようなツールを用いて記録を取得する必要があります。

これら3つは、単体では対策として十分に機能しません。「侵害の抑止」を徹底したとしても、侵入経路を0にすることはできないため、侵害自体も完全に防ぐことはできません。侵害を前提とした時に、被害を抑えるためには文字通り「被害の局所化」を実施する必要があります。局所化ができていても、侵害された時点で一定の被害は避けられないため、「追跡可能性」も重要になります。
そのため、3つを全て組み合わせて、初めて対策として機能します。

7. GitHub Actions セキュリティのシリーズのまとめ

シリーズ全体を振り返って

これまで公開した記事と本記事をもって、GitHub Actionsセキュリティのシリーズは完結となります。
シリーズ全体を振り返ってみると、記事のボリュームが多くなっていることがわかります。筆者自身、当初は4本に分かれるほどとは考えていませんでした。
最初は1記事に収める予定でしたが、「この攻撃を防ぐには、複数の対策が必要となる」「デフォルトの構成が自由で難しすぎる」と芋づる式に膨らみ、結果4本に分かれてしまいました。

シリーズを通して感じたことは、「GitHub Actionsを守るのは、アプリケーションの脆弱性を潰すのと同じくらい難しい」ということです。

これまでのシリーズで、攻撃手法やそれに対する対策・緩和策を紹介してきました。継続して検知する方法も紹介しました。

これらを自社で実施することが難しい場合の選択肢として、弊社は「ソフトウェアサプライチェーン診断」の提供を開始しました。

では、攻撃手法に対する対策を継続的に対応し続けることは果たして現実的なのでしょうか。
この問いに答えるべく、既にリリースされている「Takumi Guard」や「Takumi Runner」も合わせて簡単に紹介します。

ソフトウェアサプライチェーン診断の紹介

これまで記載してきたように、脆弱性を検知し、組織全体を見てリスク評価し、対策を考えることには多大な負荷がかかります。これをプロダクトの脆弱性対応と並行して進めるのは、運用負荷の点で現実的ではありません。

2章〜6章で見たように、検知ツールに任せられる範囲と、検知ツール外でやるべき範囲があります。ソフトウェアサプライチェーン診断は、後者を弊社のセキュリティエンジニアが担うサービスです。
具体的には、GitHub Actionsにとどまらず、組織内のCI/CDパイプラインから依存パッケージ、リポジトリ設定までを横断的に確認し、設計上のリスクを洗い出します。

詳細は以下のページをご確認いただけると幸いです。

運用を支えるTakumi GuardとTakumi Runner

ソフトウェアサプライチェーンへのセキュリティ対策は一時点の評価で完結するものではなく、継続的な仕組みと組み合わせて運用することが前提となります。ソフトウェアサプライチェーン診断で報告された脆弱性を修正したあとも、新規依存の追加やAction更新で同種の脆弱性は混入し得ます。

この継続性を支える仕組みとして、弊社ではTakumi Guard13とTakumi Runner14を提供しています。前者はパッケージマネージャーとレジストリの間に位置するセキュリティプロキシです。すべてのインストールリクエストを弊社独自の脅威データベースと照合し、悪性パッケージをブロックします。
後者はGitHub Actions runner上のプロセス起動・egress通信を記録し、runner内で行われた不審な挙動を事後に追跡できるようにします。

おわりに

本記事では、GitHub Actionsの脆弱な構成を検知する5つのツールを比較し、ツールに任せられることとツール外でやるべきことを整理しました。

ツールを組み合わせることで、Script Injectionや過剰な権限設定、外部Actionのピン留め漏れといったパターンベースの問題は効率的に検知できます。しかし、数百件の検知事項の中からどれが致命的でどれが後回しにできるかは、ワークフローの役割、secretsの配置、クラウドとの接続関係といった組織固有の文脈を踏まえなければ判断できません。

まずは無償でクローズドソースにも利用できて検知範囲も広いzizmorをCIに組み込み、Code scanning alertsで検知の量と性質を把握するところから始めるのが現実的です。あわせて、組織内で使われているPATを棚卸しし、Classic PATをFine-grained PATへ移行する計画を立てると、侵害されてしまったとしても影響範囲を狭めることが可能です。組織全体での経路評価や、検知ツールでは不足している領域の確認が必要な場合は、弊社のソフトウェアサプライチェーン診断を検討してください。

ツールによる自動検知で脆弱なパターンを洗い出し、ツール外で組織全体を踏まえたリスク評価と対策を行う。この役割分担が、ソフトウェアサプライチェーンを守るために必要なアプローチだと考えています。本記事がその一助となれば幸いです。

ここまでお読みいただきありがとうございました。

  1. https://codeql.github.com/↩
  2. https://github.com/github/codeql-cli-binaries/blob/main/LICENSE.md#use-rights-scope-of-license↩
  3. https://github.com/zizmorcore/zizmor↩
  4. https://scorecard.dev/↩
  5. https://github.com/boostsecurityio/poutine↩
  6. https://github.com/bridgecrewio/checkov↩
  7. https://nx.dev/blog/s1ngularity-postmortem↩
  8. https://github.com/nrwl/nx/commit/d81861d4aae070867c38efb9fb191ef0364c81dc↩
  9. https://laravel.com/blog/moat-a-security-review-for-your-github-account#what-moat-verifies↩
  10. 研究論文では、エージェント型ワークフローインジェクション (AWI) を体系化し、検知ツール TaintAWI を提案する論文(arXiv:2605.07135(https://arxiv.org/abs/2605.07135)) が 2026年5月に公開されています。2026年6月19日時点でツール本体は公開されておらず、CIに組み込んで継続的に運用できる段階には至っていません。↩
  11. https://docs.zizmor.sh/configuration/#rules-id-ignore↩
  12. https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/↩
  13. https://flatt.tech/takumi/features/guard↩
  14. https://flatt.tech/takumi/features/runner↩