gha-security-review

同梱された上流サポートファイル

サポートファイルはスキルからの相対パスに含まれています。固定されたソース、ライセンス、ハッシュ、インポート時の変更については、UPSTREAM-NOTICE.md を参照してください。

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

GitHub Actions ワークフローに悪用可能な脆弱性がないか調査します。報告する各指摘には、具体的な悪用シナリオを必ず含めてください。攻撃経路をたどれない場合は、確認済みの脆弱性として報告しないでください。無害な PoC の概要のみを使用し、明示的なテスト許可がない限り、ワークフローの実行、シークレットの持ち出し、攻撃者のコンテンツの投稿は行わないでください。

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

使用するタイミング

• GitHub Actions ワークフローに悪用可能なセキュリティ問題がないかレビューする場合。
• 外部の攻撃者からワークフローの実行またはシークレットの漏えいに至る具体的な攻撃経路をたどる必要がある場合。
• ワークフローファイル、複合アクション、またはワークフロー関連スクリプトを、証拠に基づく指摘のみでセキュリティレビューする必要がある場合。

対象範囲

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

レビュー対象ファイル

• .github/workflows/*.yml — すべてのワークフロー定義
• action.yml / action.yaml — リポジトリ内の複合アクション
• .github/actions/*/action.yml — ローカルの再利用可能なアクション
• ワークフローによって読み込まれる設定ファイル：CLAUDE.md、AGENTS.md、Makefile、.github/ 配下のシェルスクリプト

対象外

• 他のリポジトリのワークフロー（依存関係として言及するにとどめます）
• GitHub App のインストール権限（関連する場合は言及してください）

脅威モデル

リポジトリへの書き込み権限を持たない外部の攻撃者が悪用できる脆弱性のみ報告してください。攻撃者はフォークからプルリクエストを作成し、issue を作成し、コメントを投稿できます。ブランチへの push、workflow_dispatch の実行、手動ワークフローの起動はできません。

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

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

信頼度

HIGH および MEDIUM の信頼度の指摘のみ報告してください。理論上の問題は報告しないでください。

信頼度	基準	対応
HIGH	完全な攻撃経路をたどり、悪用可能であることを確認済み	悪用シナリオと修正方法を添えて報告する
MEDIUM	攻撃経路の一部は確認済みだが、不確かな箇所がある	要確認として報告する
LOW	理論上の問題、または他の対策で軽減されている	報告しない

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

1. 侵入口 — 攻撃者はどのように侵入するか（フォークからの PR、issue コメント、ブランチ名など）。
2. ペイロード — 攻撃者は何を送るか（実際のコード、YAML、入力など）。
3. 実行メカニズム — ペイロードはどのように実行されるか（式の展開、checkout とスクリプトの実行など）。
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 を使用し、かつフォークのコードをチェックアウトしていますか？

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

確認 2：式のインジェクション

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

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

確認 3：不正なコマンド実行

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

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

確認 4：認証情報の昇格

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

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

確認 5：設定ファイルのポイズニング

ワークフローは PR から提供されたファイルを設定として読み込んでいますか？

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

確認 6：サプライチェーン

サードパーティ製アクションのバージョンは安全に固定されていますか？

確認 7：権限とシークレット

ワークフローの権限は最小限ですか？シークレットのスコープは適切ですか？

確認 8：ランナーのインフラストラクチャ

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

安全なパターン（報告しない）

報告する前に、そのパターンが実際に安全かどうかを確認します。

パターン	安全な理由
フォークのコードをチェックアウトしない pull_request_target	メタデータのインジェクション、アクション、アーティファクト、その他の信頼されていない入力も引き続き調べてください
run: 内の ${{ github.event.pull_request.number }}	数値のみであり、インジェクションできません
${{ github.repository }}／github.repository_owner	リポジトリの所有者が制御します
${{ secrets.* }}	式のインジェクション経路ではありません
if: 条件内の ${{ }}	シェルではなく、Actions のランタイムによって評価されます
with: 入力内の ${{ }}	ここでは自動的なシェル展開は行われません。アクションが入力をどう処理するかを追跡してください
完全な SHA に固定されたアクション	アクションのソースを固定しますが、安全なコードや不変のランタイムダウンロードを保証するものではありません
pull_request トリガー（_target ではないもの）	通常、フォークではトークン／シークレットが制限されます。ただし、同一リポジトリ内の PR、設定、セルフホストのインフラストラクチャは引き続き確認が必要です
保護されたブランチを対象とする workflow_dispatch／schedule／push 内の任意の式	書き込み権限が必要となるため、脅威モデルの対象外です

重要な違い： ${{ }} は run: ブロック内では危険です（シェル展開）。一方、if:、with:、env: ではこの直接的な置換先を回避できます。ただし、後続処理での eval、シェルコマンドの組み立て、JavaScript の実行、安全でないアクション入力によって、インジェクションが再び可能になることがあります。

ステップ 3：報告前に検証する

問題を報告する前に、実際のワークフロー YAML を読み、攻撃経路全体をたどってください。

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

つながりが一つでも欠けている場合は、MEDIUM（検証が必要）とするか、問題の報告を見送ってください。

いずれのチェックでも問題が見つからなかった場合は、問題がゼロであると報告してください。問題を捏造しないでください。

ステップ 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]

問題がない場合：「レビュー対象の範囲と明示された前提の下では、悪用可能な脆弱性は特定されませんでした。」未読のワークフロー、アクセスできない設定、未検証のランタイムリンクを列挙してください。すべてのワークフローが安全だと認定しないでください。

制限事項

• タスクが上記の対象範囲に明確に一致する場合に限り、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。