gha-security-review

GitHub Actions セキュリティレビュー

GitHub Actions のワークフローに悪用可能な脆弱性がないか調査します。報告する指摘には、必ず具体的な悪用シナリオを含めてください。攻撃を組み立てられない場合は、報告しないでください。

このスキルには、一般的な CI/CD の理論ではなく、実際の GitHub Actions の悪用事例に基づく攻撃パターンがまとめられています。

対象範囲

提示されたワークフロー（ファイル、差分、またはリポジトリ）をレビューします。報告する前に、必要に応じてコードベースを調査し、攻撃経路全体を追跡してください。

レビュー対象ファイル

• .github/workflows/*.yml — すべてのワークフロー定義
• action.yml / action.yaml — リポジトリ内のコンポジットアクション
• .github/actions/*/action.yml — ローカルの再利用可能なアクション
• ワークフローが読み込む設定ファイル：CLAUDE.md、AGENTS.md、Makefile、.github/ 内のシェルスクリプト

対象外

• 他のリポジトリのワークフロー（依存関係としてのみ記載）
• GitHub App のインストール権限（関連する場合は記載）

脅威モデル

外部の攻撃者、つまりリポジトリへの書き込み権限を持たない人物が悪用できる脆弱性のみ報告してください。攻撃者はフォークから PR を作成し、Issue を作成し、コメントを投稿できます。ブランチへのプッシュ、workflow_dispatch のトリガー、手動ワークフローのトリガーはできません。

書き込み権限が必要な脆弱性は報告しないでください。

• workflow_dispatch の入力インジェクション — トリガーには書き込み権限が必要
• 保護されたブランチでの push のみをトリガーとするワークフローにおける式インジェクション
• 呼び出し元がすべて内部の workflow_call 入力インジェクション
• workflow_dispatch／schedule のみをトリガーとするワークフロー内のシークレット

信頼度

HIGH と MEDIUM の指摘のみ報告してください。理論上の問題は報告しないでください。

信頼度	基準	対応
HIGH	攻撃経路全体を追跡し、悪用可能であることを確認済み	悪用シナリオと修正方法を添えて報告
MEDIUM	攻撃経路の一部を確認済みだが、つながりに不確実性がある	要検証として報告
LOW	理論上の問題、または別の対策で緩和済み	報告しない

HIGH の指摘ごとに、次の5項目をすべて記載してください。

1. 侵入経路 — 攻撃者はどのように侵入するか（フォーク PR、Issue コメント、ブランチ名など）。
2. ペイロード — 攻撃者は何を送信するか（実際のコード、YAML、入力など）。
3. 実行メカニズム — ペイロードはどのように実行されるか（式の展開、チェックアウトとスクリプトの実行など）。
4. 影響 — 攻撃者は何を得るか（トークン窃取、コード実行、リポジトリへの書き込み権限など）。
5. PoC の概要 — 攻撃者が実行する具体的な手順。

5項目をすべて構成できない場合は、要検証として MEDIUM で報告してください。

---

ステップ 1：トリガーを分類してリファレンスを読み込む

各ワークフローのトリガーを特定し、適切なリファレンスを読み込みます。

トリガー／パターン	読み込むリファレンス
pull_request_target	references/pwn-request.md
コマンド解析を行う issue_comment	references/comment-triggered-commands.md
run: ブロック内の ${{ }}	references/expression-injection.md
PAT／デプロイキー／高権限の認証情報	references/credential-escalation.md
PR コードのチェックアウトと設定ファイルの読み込み	references/ai-prompt-injection-via-ci.md
サードパーティ製アクション（特に固定されていないもの）	references/supply-chain.md
permissions: ブロックまたはシークレットの使用	references/permissions-and-secrets.md
セルフホストランナー、キャッシュ／アーティファクトの使用	references/runner-infrastructure.md
確認済みの指摘全般	references/real-world-attacks.md

リファレンスは選択的に読み込み、見つかったトリガーに関連するものだけを対象にしてください。

ステップ 2：脆弱性の分類を確認する

確認 1：Pwn Request

ワークフローは pull_request_target を使用し、フォークのコードをチェックアウトしていますか？

• ref: が PR の head を指す actions/checkout を探します。
• フォーク由来となるローカルアクション（./.github/actions/）を探します。
• run: ステップがチェックアウトした PR のコードを実行するか確認します。

チェック 2：式インジェクション

外部からトリガー可能なワークフローの run: ブロック内で ${{ }} 式が使われていますか？

• すべての run: ステップで、各 ${{ }} 式を特定します
• 値が攻撃者によって制御可能か確認します（PR タイトル、ブランチ名、コメント本文など。数値 ID、SHA、リポジトリ名は該当しません）
• 式が if:、with:、ジョブレベルの env: ではなく、run: ブロック内にあることを確認します

チェック 3：不正なコマンド実行

issue_comment でトリガーされるワークフローが、認可なしでコマンドを実行しますか？

• author_association のチェックはありますか？
• GitHub ユーザーなら誰でもコマンドをトリガーできますか？
• コマンドハンドラーでもインジェクション可能な式を使用していますか？

チェック 4：認証情報の昇格

権限の強い認証情報（PAT、デプロイキー）に、信頼されていないコードからアクセスできますか？

• 各シークレットの影響範囲はどの程度ですか？
• ワークフローが侵害された場合、長期間有効なトークンを盗まれる可能性はありますか？

チェック 5：設定ファイルのポイズニング

ワークフローは PR から提供されたファイルの設定を読み込みますか？

• AI エージェントの指示：CLAUDE.md、AGENTS.md、.cursorrules
• ビルド設定：Makefile、シェルスクリプト

チェック 6：サプライチェーン

サードパーティアクションは、完全な SHA で安全に固定されていますか？

• サードパーティ／外部アクションと再利用可能なワークフローのみ固定します
• バージョンタグを使用したファーストパーティの actions/* または github/* は指摘しないでください
• 同一リポジトリ内／ベンダー提供のもの（./.github/actions/...）を、サプライチェーンの固定に関する問題として指摘しないでください
• ジョブにシークレット、OIDC、書き込みトークン、リリース、デプロイ、パッケージ、署名の権限がある場合にのみ報告します。権限のない読み取り専用 CI は指摘対象ではありません

チェック 7：権限とシークレット

ワークフローの権限は最小限ですか？シークレットは適切にスコープ設定されていますか？

チェック 8：ランナーのインフラストラクチャ

セルフホストランナー、キャッシュ、アーティファクトは安全に使用されていますか？

安全なパターン（指摘しない）

報告する前に、そのパターンが実際に安全かどうか確認してください。

パターン	安全な理由
フォークコードをチェックアウトしない pull_request_target	攻撃者のコードを実行しません
run: 内の ${{ github.event.pull_request.number }}	数値のみのため、インジェクションできません
${{ github.repository }} ／ github.repository_owner	リポジトリの所有者が制御しています
${{ secrets.* }}	式インジェクションの経路ではありません
if: 条件内の ${{ }}	シェルではなく、Actions ランタイムによって評価されます
with: 入力内の ${{ }}	シェルで評価されず、文字列パラメーターとして渡されます
完全な SHA で固定されたサードパーティアクション	不変の参照です
バージョンタグを使用したファーストパーティの actions/* ／ github/*	サードパーティの固定ポリシーの対象外です。指摘しないでください
同一リポジトリ内／ベンダー提供のローカルアクション	サードパーティのサプライチェーンではありません（pwn-request は別途確認してください）
pull_request トリガー（_target ではないもの）	フォークのコンテキストで、読み取り専用トークンを使って実行されます
保護されたブランチへの workflow_dispatch／schedule／push における任意の式	書き込みアクセスが必要なため、脅威モデルの対象外です

重要な違い： ${{ }} は run: ブロック内では危険です（シェル展開）。一方、ジョブ／ステップレベルの if:、with:、env: 内では安全です（Actions ランタイムによる評価）。

ステップ 3：報告前の検証

指摘事項を含める前に、実際のワークフロー YAML を読み、攻撃経路全体を追跡してください。

1. ワークフロー全体を読む — grep の出力だけに頼らないでください
2. トリガーを追跡する — イベントを確認し、実行を制御する if: 条件を調べます
3. 式／チェックアウトを追跡する — run: ブロック内にあるか、フォークのコードを実際に参照しているか確認します
4. 攻撃者が制御できることを確認する — 値が外部の攻撃者によって設定されるものに対応するか検証します
5. 既存の緩和策を確認する — 環境変数によるラップ、author_association チェック、制限付き権限、SHA の固定

いずれかのつながりが途切れている場合は、MEDIUM（検証が必要）とするか、指摘事項から除外してください。

いずれのチェックでも指摘事項が見つからなかった場合は、指摘件数を 0 と報告してください。問題を作り上げてはいけません。

ステップ 4：指摘事項の報告

## GitHub Actions Security Review

### Findings

#### [GHA-001] [Title] (Severity: Critical/High/Medium)
- **Workflow**: `.github/workflows/release.yml:15`
- **Trigger**: `pull_request_target`
- **Confidence**: HIGH — confirmed through attack path tracing
- **Exploitation Scenario**:
  1. [Step-by-step attack]
- **Impact**: [What attacker gains]
- **Fix**: [Code that fixes the issue]

### Needs Verification
[MEDIUM confidence items with explanation of what to verify]

### Reviewed and Cleared
[Workflows reviewed and confirmed safe]

指摘事項がない場合：「悪用可能な脆弱性は特定されませんでした。すべてのワークフローを確認し、問題がないことを確認しました。」