security-testing

セキュリティテスト（オーケストレーター）

概要

防御的なセキュリティ作業の入り口です。認可ゲートを適用したうえで、次のライフサイクルに沿って進めます。PLAN → FIND → EXPLOIT → FIX。攻撃者の視点で自分自身の弱点を見つけ、修正します。

**基本原則：**攻撃者は経路で考え、防御側はリストで考えます。防御側はあらゆる箇所で正しく対処する必要がありますが、攻撃者に必要なのは弱点が一つだけです。経路を探してください。

このオーケストレーターの実行方法（必須 — 最初に読むこと）

このスキルはルーターであり、名前が挙がっているスキルの代わりにはなりません。以下の表は各フェーズでどのスキルを開くべきかを示しています。Skill ツールを使って、必ず実際に開いてください。

**ルール：**各フェーズの作業を始める前に、そのフェーズのスキルを呼び出し、チェックリストに従ってください。ルーティング表にある1行の説明を読むだけでは、スキルを実行したことにも、対象範囲を確認したことにもなりません。スキルを呼び出さず、自分の専門知識だけで作業することは、このセクションが防ごうとしている失敗です。

• RECON → recon-and-osint · PLAN → threat-modeling
• FIND/EXPLOIT → 対象領域のテスト前に、該当する各専門スキル（access-control-testing、 authentication-testing、injection-testing、file-upload-and-ssrf、api-security-testing、 client-side-exploitation、business-logic-testing、secrets-management-audit）をすべて呼び出します。これに加えて、 security-code-audit（静的）と active-pentest（動的）も呼び出します。
• CHAIN → vulnerability-chaining · FIX → security-hardening · REPORT → pentest-reporting

**対象範囲の報告は正確に：**対象範囲のレポートでは、Skill ツール経由で呼び出した場合に限り、そのスキルに ✓ を付けてください。呼び出さず、記憶に基づいて手法を適用した場合は「methodology-only」と記載してください。対象に該当しない場合は「N/A — <理由>」と記載してください。「同様の作業を行った」という意味で ✓ を付けてはいけません。

危険信号 — 作業を止め、続行する前にスキルを呼び出してください：

• 「これは何をカバーしているか、もう分かっている／この分野には非常に詳しい」
• 「ルーティング表の概要だけで十分だ」
• 「最も効果が高そうな対象から始めて、直接作業しよう」
• 「専門スキルは後で参照しよう」
• 「このスキルは大げさだ — こうしたバグは何百回も見つけている」
• 時間的なプレッシャー：「ユーザーは早く結果を求めている。読み込み手順は省略しよう」

これらはどれも、気づかないまま抜け漏れを生む典型的な言い訳です。地図は現地そのものではありません。作業を始める前に、各扉（Skill の呼び出し）を開いてください。

認可ゲート（毎回、最初に実施）

テストを始める前に、ユーザーに次の点を声に出して確認してください。

1. 所有権／認可 — このアプリの所有者ですか。それとも、テストするための書面による許可を得ていますか。
2. 対象環境 — テスト対象はラボ／ステージング／ローカル環境に限定されていますか（第三者の本番環境ではありませんか）。
3. 対象範囲外 — 破壊的な操作、DoS、実際のユーザーデータの持ち出しは行わないことを確認してください。

いずれかの回答が不明確、または「いいえ」の場合は、停止し、ユーザーが管理するコードのコード監査のみを行ってください。 書面による許可なしに、第三者のシステムをテストしてはいけません。

ルーティング

digraph route {
  "What do you need?" [shape=diamond];
  "recon-and-osint" [shape=box];
  "threat-modeling" [shape=box];
  "FIND/EXPLOIT skills" [shape=box];
  "security-hardening" [shape=box];
  "pentest-reporting" [shape=box];

  "What do you need?" -> "recon-and-osint" [label="discover the attack surface"];
  "What do you need?" -> "threat-modeling" [label="plan / prioritize"];
  "What do you need?" -> "FIND/EXPLOIT skills" [label="find & validate bugs"];
  "What do you need?" -> "security-hardening" [label="fix findings"];
  "What do you need?" -> "pentest-reporting" [label="report & track closure"];
  "recon-and-osint" -> "threat-modeling" -> "FIND/EXPLOIT skills";
  "FIND/EXPLOIT skills" -> "security-hardening" -> "pentest-reporting";
}

ライフサイクルのフェーズ（全体を評価する場合は順番に実行します）：

フェーズ	スキル	実行するタイミング
RECON	recon-and-osint	攻撃対象領域を把握する前に、実際の攻撃対象領域を特定します。
PLAN	threat-modeling	何を優先して警戒し、最初にテストするかを決めます。
FIND/EXPLOIT	詳細調査の専門スキル（以下）	脆弱性を発見し、検証します。
FIX	security-hardening	適切な修正を行い、検証します。
REPORT	pentest-reporting	発見事項を評価、文書化し、解決まで追跡します。

FIND/EXPLOIT の詳細調査専門スキル（テスト対象に応じて選択）：

対象	スキル
アクセス制御／IDOR／権限昇格（OWASP #1）	access-control-testing
ログイン／セッション／OAuth／JWT／MFA（アカウント乗っ取り）	authentication-testing
ワークフロー／価格設定／競合状態／不正利用	business-logic-testing
REST／GraphQL／gRPC／WebSocket（OWASP API Top 10）	api-security-testing
ブラウザー／HTTP 層（DOM XSS、CSP/CORS、プロトタイプ汚染、リクエストスマグリング）	client-side-exploitation
インタープリターに渡される入力（SQLi/NoSQLi、コマンド、SSTI、XXE）	injection-testing
ファイルアップロード、SSRF、安全でないデシリアライゼーション	file-upload-and-ssrf
漏えいしたキー／トークン（コード、git 履歴、ログ、設定）	secrets-management-audit

その後、統合します： vulnerability-chaining は、上記の発見事項をエンドツーエンドの攻撃経路にまとめます。これは最も影響の大きいステップであり、複数の中程度の問題が重大な問題へとつながる場合があります。

専門スキルが使用する、分野横断的な補助スキル：

• security-code-audit — 静的（ホワイトボックス）レビュー：ソースコードを読み、脆弱性のパターンを検索します。
• active-pentest — 実行ハーネス：ラボ／プロキシ／スキャナーのセットアップ、安全な実行、PoC の取得を行います。 専門スキルが攻撃手順を提供し、active-pentest を使って稼働中のアプリで実行します。

推奨フロー： 偵察 → 脅威モデリング → 詳細な発見／悪用（実環境で最もリスクが高い #1 のため、access-control-testing から開始）→ 強化 → 報告。各フェーズの結果を次のフェーズに引き継ぎます。

サーフェスに基づくルーティング（適用可否とギャップ）

すべてのスキルを実行するのではなく、対象に存在するものに対応するスキルを実行します。recon-and-osint と threat-modeling を使ってサーフェス一覧を作成し、存在するサーフェスを専門スキルに対応付けます。

サーフェスが存在するか？	対応するスキル	存在しない場合
ブラウザー UI／クライアント側 JS	client-side-exploitation	スキップ（該当なし）
ログイン／アカウント／トークン	authentication-testing	スキップ
認証済み／複数ユーザーのデータ	access-control-testing	スキップ
API（REST/GraphQL/gRPC/WS）	api-security-testing	スキップ
DB／シェル／テンプレート／XML のシンク	injection-testing	スキップ（シンクごと）
ファイルアップロード／URL フェッチ／デシリアライゼーション	file-upload-and-ssrf	スキップ（機能ごと）
ワークフロー／金銭／クォータ	business-logic-testing	スキップ
コード／リポジトリ／設定（ほぼ常に存在）	secrets-management-audit	—

各専門スキルは、独自の適用する場合／スキップする場合のブロックを使って適用可否を自己確認します。たとえば、ヘッドレス API にフロントエンド向けスキルを適用すると、「該当なし」と報告して停止するため、不要な情報は出力されません。

ギャップの確認（逆の確認 — 専門スキルが対応していないサーフェス）： 一覧にあるサーフェスのうち、どの専門スキルも対応していないもの（カスタムバイナリプロトコル、メッセージバス、IoT／ファームウェアのエンドポイントなど）については、次の手順を実行します。

1. 明示的に指摘します —「対応済み」として決して見過ごさないでください。
2. 汎用の security-code-audit（静的）と active-pentest（動的）の手法にフォールバックします。
3. その領域を対象とする新しい専門スキルを推奨します。

何を実行し、何をスキップしたのか、その理由、および対応範囲に含まれないものを明確にするため、必ずカバレッジレポートを出力してください：

Frontend ...... none  → client-side-exploitation: N/A (skipped)
API (REST) .... yes   → api-security-testing, access-control-testing ✓
Uploads ....... none  → file-upload-and-ssrf: N/A (skipped)
gRPC stream ... yes   → ⚠ GAP: generic methodology + consider a new specialist

全工程の実行結果

• 優先順位付きの脅威モデル（最も重要な項目）
• 発見事項一覧：深刻度 · file:line · 悪用可能な理由 · ステータス
• 深刻度の高い項目について、検証済みの PoC
• 適用した修正と、それぞれの問題が解決したことを確認する再テスト

よくある間違い

• ルーティングするスキルを実行せず、ルーティングテーブルを読む → 要約は地図であり、現地そのものではありません。作業を始める前に各扉を開き（Skill ツールを呼び出し）、「このオーケストレーターの実行方法」を参照して、実際に呼び出した場合にのみ ✓ を付けてください。
• 脅威モデルを省略する → 手当たり次第にテストし、最も重要な資産を見逃します。
• 稼働中のシステムをテストする許可なしに監査する → コード監査のみにとどめてください。
• 発見した問題を修正・再テストしない → 誰も対応しない報告は、セキュリティとは言えません。