security-research

セキュリティリサーチ - チームモードの脆弱性監査

このスキルを使用すると、実際の悪用可能性と一般的な懸念を切り分けながら、並行してセキュリティ監査を実行できます。チームには、脆弱性ハンターが3名、PoC エンジニアが2名います。

必須の前提条件

開始前に、次の項目を確認してください。

1. team_* ツールが利用可能であること。利用できない場合は、作業を中止してユーザーに次のように伝えてください。 security-research requires team-mode. Set team_mode.enabled: true in your oh-my-openagent config, restart opencode, then retry.
2. バックグラウンドのサブエージェントではなく、メインセッションであること。
3. 具体的な対象があること：リポジトリ、差分範囲、PR、リリース候補、パス一覧、または脅威となる攻撃面。

ユーザーが対象を指定していない場合は、現在のリポジトリと現在のブランチの差分を、アップストリームまたはマージベースと比較して監査してください。差分がない場合は、作業ツリー内のセキュリティ上重要な攻撃面を監査してください。

深刻度の基準

スコアリングには、次の資料を参照してください。

• 根本原因の弱点分類には CWE：https://cwe.mitre.org/
• テスト手法には OWASP WSTG：https://devguide.owasp.org/en/06-verification/01-guides/01-wstg/
• コントロールの検証には OWASP ASVS：https://owasp.org/www-project-application-security-verification-standard/
• 悪用可能性と影響のスコアリングには CVSS v4.0：https://www.first.org/cvss/v4.0/specification-document

ルール：

• 攻撃経路がない場合、深刻度を付与しないでください。
• 具体的な悪用の前提条件と影響がない場合、重大または高の指摘をしないでください。
• CWE カテゴリーと深刻度は分けてください。
• 理論的な説明より、再現可能な小規模な PoC を優先してください。
• 実在するサービスやサードパーティーのシステムに対して、破壊的なエクスプロイトを決して実行しないでください。
• 実際の実行が危険な場合は、ローカルのフィクスチャ、テスト用のペイロード、ドライラン、または静的な証明を使用してください。

チーム編成

次の5名で Team Mode を1回実行してください。

メンバー	種別	カテゴリー	役割
surface-hunter	category	deep-low	エントリーポイント、信頼境界、到達可能な攻撃面を特定します。
auth-data-hunter	category	ultrabrain	認証、認可、データ分離、インジェクション、シークレット処理の不備を探します。
runtime-supply-hunter	category	unspecified-high	ファイルシステム、サブプロセス、アーカイブ、依存関係、フック、MCP、設定のリスクを探します。
poc-engineer-a	category	unspecified-high	最も有力な候補となる指摘に対して、最小限の PoC を作成します。
poc-engineer-b	category	deep-high	候補となる指摘を独立して再現、反証、または格下げします。

インライン仕様を指定して team_create を呼び出してください。

team_create({
  inline_spec: {
    name: "security-research",
    description: "Parallel exploitability-driven security research team.",
    members: [
      {
        name: "surface-hunter",
        kind: "category",
        category: "deep-low",
        prompt: "You map attack surface. Enumerate entry points, trust boundaries, attacker-controlled inputs, data sinks, privilege transitions, and sensitive assets. Return evidence with file paths and exact functions. Do not assign severity unless you can name an attack path."
      },
      {
        name: "auth-data-hunter",
        kind: "category",
        category: "ultrabrain",
        prompt: "You hunt auth, authorization, tenant/data isolation, injection, SSRF, credential exposure, and confused-deputy flaws. Reason from attacker capability to impact. Return only findings with concrete exploit preconditions, CWE candidates, and verification steps."
      },
      {
        name: "runtime-supply-hunter",
        kind: "category",
        category: "unspecified-high",
        prompt: "You hunt filesystem, subprocess, archive extraction, dependency, hook execution, MCP, config, and environment-variable risks. Check path traversal, command injection, unsafe downloads, permission boundaries, and supply-chain assumptions. Cite file paths and commands used."
      },
      {
        name: "poc-engineer-a",
        kind: "category",
        category: "unspecified-high",
        prompt: "You build minimal safe PoCs for candidate findings. Use toy inputs and local-only execution. Your job is to prove or disprove exploitability, not to broaden scope. Report exact reproduction steps and expected output."
      },
      {
        name: "poc-engineer-b",
        kind: "category",
        category: "deep-high",
        prompt: "You independently reproduce candidate findings and try to falsify them. Downgrade anything without a working path. If a PoC is unsafe to run, design a safe static or dry-run proof and explain the limit."
      }
    ]
  }
})

カテゴリーが利用できない場合は、そのカテゴリーのみを unspecified-high に置き換えて一度だけ再試行してください。チームを5名未満にしないでください。

ワークフロー

フェーズ0：範囲とベースライン

次の情報を収集してください。

• 監査対象の範囲と監査の理由。
• 変更レビューの場合は、ブランチ、ベース参照、差分、変更ファイル。
• リポジトリ全体の監査の場合は、セキュリティ上重要なディレクトリとファイル。
• 関連する攻撃面を検証する既存のテストとコマンド。
• ネットワーク呼び出しの禁止や破壊的なテストの禁止など、ユーザーが指定した制約。

作業を割り当てる前に、rg、git diff、git log、LSP、既存のテストを使用してください。

フェーズ1：ハンターによる独立調査

3名のハンターに、次のプロンプトを1件送信してください。

Audit target:
{target summary}

Context:
{diff, file list, security-sensitive paths, known constraints}

Task:
Find candidate vulnerabilities in your assigned role. For each candidate include:
- title
- affected file/function
- attacker capability
- attack path
- impact
- CWE candidate
- exact evidence
- safe verification idea

Reject generic hardening advice. Return only candidates with a plausible path.

ハンター全員の回答を待ってください。

フェーズ2：PoC の作成

ハンターが見つけた候補の重複を取り除いてください。最も有力な候補を両方の PoC エンジニアに送ってください。

各 PoC エンジニアは、次の情報を返す必要があります。

• 再現、反証、または実行不可。
• 正確なコマンド、フィクスチャ、または静的な証明。
• 観測された出力、または失敗する理由。
• 悪用可能性と影響に基づく深刻度の推奨。
• 再現されなかったものを格下げする理由。

フェーズ3：相互確認

PoC の結果を5名全員に返してください。

各メンバーに、次の点を尋ねてください。

• どの指摘が妥当なままですか？
• どの指摘を格下げまたは削除すべきですか？
• 最小限で具体的な修正方法は何ですか？
• 再発を防ぐには、どの回帰テストが必要ですか？

フェーズ4：最終レポート

次のレポートを作成してください。

## Security Research Result

### Verdict
PASS | PASS WITH FINDINGS | BLOCK

### Scope
- Target:
- Base/diff:
- Commands run:

### Findings
| Severity | Title | CWE | Exploitability | Impact | PoC | Fix |
|----------|-------|-----|----------------|--------|-----|-----|

### Finding Details
For each finding:
- Evidence:
- Attack path:
- PoC:
- Severity rationale:
- Minimal fix:
- Regression check:

### Downgraded or Rejected Candidates
| Candidate | Reason |
|-----------|--------|

### Residual Risk
- What was not tested and why.

出力ルール

• 最初に判定を示してください。
• 重大な問題を後回しにしないでください。
• 推測に基づく指摘を脆弱性として報告しないでください。
• 実際に指標を採点していない限り、CVSS の精度を主張しないでください。
• 採用した指摘ごとに、正確なファイルパスとコマンドを記載してください。
• PoC で確認できた指摘がない場合は、その旨を明確に述べ、残存リスクを列挙してください。