pentest-validation

ペネトレーションテストの検証

<default_to_action> セキュリティ上の指摘を検証する際は、次の手順に従います。

1. 対象 URL について明示的な許可を必須とします
2. qe-security-scanner でスキャンします（SAST ＋ 依存関係 ＋ シークレット）
3. qe-security-reviewer ＋ qe-security-auditor で並行して分析します
4. qe-pentest-validator で検証します（段階的なエクスプロイトを実施し、脆弱性の種類ごとに並行処理）
5. PoC の証拠で確認できた指摘のみ報告します（「エクスプロイトがなければ、報告しない」）
6. 新しいパターンをエクスプロイトのプレイブックに反映します

品質ゲート：

• いかなるエクスプロイトの前にも、許可を確認します
• 対象 URL はステージング／開発環境とします（本番環境は対象外）
• 予算上限を適用します（デフォルトは $15）
• 時間上限を適用します（デフォルトは 30 分）
• すべてのエクスプロイト試行をログに記録します </default_to_action>

クイックリファレンスカード

4 フェーズのパイプライン

フェーズ	エージェント	目的	並列処理
1. 偵察	qe-security-scanner	SAST、DAST、依存関係スキャン、シークレット	内部で並行処理
2. 分析	qe-security-reviewer ＋ qe-security-auditor	コードレビュー ＋ コンプライアンスチェック	両方を並行処理
3. 検証	qe-pentest-validator	段階的なエクスプロイト検証	脆弱性の種類ごとに並行処理
4. レポート	qe-quality-gate	「エクスプロイトがなければ、報告しない」フィルター	順次処理

段階的なエクスプロイトのティア

ティア	ハンドラー	コスト	レイテンシ	使用する状況
1	Agent Booster (WASM)	$0	<1ms	コードパターンから結論を出せる場合（eval、innerHTML、ハードコードされた認証情報）
2	Haiku	$0.0002	~500ms	稼働中の対象に対するペイロードテストが必要な場合
3	Sonnet/Opus	$0.003-$0.015	2-5s	データの証拠を伴う完全なエクスプロイトチェーンが必要な場合

このスキルを使用する状況

シナリオ	ティア	推定コスト
PR のセキュリティレビュー（ソースのみ）	1	$0
リリース前の検証（ステージング）	1-2	$1-5
完全なペネトレーションテストの検証	1-3	$5-15
コンプライアンス監査の証拠	1-3	$5-15

---

設定

pentest:
  target_url: https://staging.app.com    # REQUIRED for Tier 2-3
  source_repo: ./src                      # REQUIRED for Tier 1+
  exploitation_tier: 2                    # 1=pattern-only, 2=payload-test, 3=full-exploit
  vuln_types:                             # Which pipelines to run
    - injection                           # SQL, NoSQL, command injection
    - xss                                 # Reflected, stored, DOM XSS
    - auth                                # Auth bypass, session, JWT
    - ssrf                                # URL scheme abuse, metadata
  max_cost_usd: 15                        # Budget cap per run
  timeout_minutes: 30                     # Time cap per run
  require_authorization: true             # MUST confirm target ownership
  no_production: true                     # Block production URLs
  production_patterns:                    # URL patterns to block
    - "*.prod.*"
    - "api.*"
    - "www.*"

---

セーフガード（必須）

許可ゲート

ペネトレーションテストの検証を実行するたびに、必ず次の手順を行います。

1. 対象 URL とエクスプロイトのティアをユーザーに表示します
2. 明示的な確認を必須とします：「私はこの対象を所有している／テストの許可を得ています」
3. タイムスタンプとともに許可をログに記録します
4. 対象 URL が本番環境のパターンに一致する場合はブロックします

このスキルで行わないこと

• 完全な自律型偵察（Nmap、Subfinder）
• ゼロデイエクスプロイトの開発
• 明示的な許可のない対象への攻撃
• 本番システムのテスト
• 実際に流出したデータの保存（アクセスの証拠のみを保存）
• ソーシャルエンジニアリングまたはフィッシングのシミュレーション
• ポートスキャンまたはサービス検出

---

検証パイプライン

インジェクションパイプライン

攻撃	ティア 1（パターン）	ティア 2（ペイロード）	ティア 3（完全）
SQL インジェクション	クエリ内の文字列連結	' OR '1'='1 に対するレスポンスの差分	UNION SELECT によるデータ抽出
NoSQL インジェクション	クエリ内の $where、$gt	演算子インジェクションのテスト	コレクションの列挙
コマンドインジェクション	exec()、system() の呼び出し	コマンド区切り文字のテスト	リバースシェルの証明
LDAP インジェクション	フィルター内の文字列連結	ワイルドカードインジェクション	ディレクトリの列挙

XSS パイプライン

攻撃	ティア 1（パターン）	ティア 2（ペイロード）	ティア 3（完全）
反射型 XSS	出力エンコーディングなし	<img onerror> の反射	qe-browser (Vibium) を介したブラウザーでの JS 実行
格納型 XSS	innerHTML への代入	ペイロードの格納と取得	Cookie 窃取の PoC
DOM XSS	document.write(location)	フラグメントインジェクション	DOM 操作の証明

認証パイプライン

攻撃	Tier 1（パターン）	Tier 2（ペイロード）	Tier 3（完全）
JWT none	アルゴリズムの検証なし	変更した JWT が受け入れられる	偽造トークンによる管理者アクセス
セッション固定化	セッションのローテーションなし	事前設定したセッションが再利用される	他ユーザーのセッション乗っ取り
クレデンシャルスタッフィング	レート制限なし	100 回の試行がブロックされない	有効な認証情報の特定
IDOR	認可チェックなし	他ユーザーのデータにアクセス	他者のリソースに対する完全な CRUD

SSRF パイプライン

攻撃	Tier 1（パターン）	Tier 2（ペイロード）	Tier 3（完全）
内部 URL	ユーザーが制御する URL の取得	http://169.254.169.254	クラウドメタデータの抽出
DNS リバインディング	URL 検証の回避	内部 IP に再バインド	内部サービスへのアクセス
プロトコルスマグリング	URL スキームが制限されていない	file:///etc/passwd	レスポンスにファイルの内容が含まれる

---

エージェントの連携

オーケストレーションパターン

// Phase 1: Recon (parallel scans)
await Task("Security Scan", {
  target: "./src",
  layers: { sast: true, dast: true, dependencies: true, secrets: true }
}, "qe-security-scanner");

// Phase 2: Analysis (parallel review)
await Promise.all([
  Task("Code Security Review", {
    findings: phase1Results,
    depth: "comprehensive"
  }, "qe-security-reviewer"),

  Task("Compliance Audit", {
    findings: phase1Results,
    frameworks: ["owasp-top-10"]
  }, "qe-security-auditor")
]);

// Phase 3: Validation (graduated exploitation)
await Task("Exploit Validation", {
  findings: [...phase1Results, ...phase2Results],
  target_url: "https://staging.app.com",
  exploitation_tier: 2,
  vuln_types: ["injection", "xss", "auth", "ssrf"],
  max_cost_usd: 15,
  timeout_minutes: 30
}, "qe-pentest-validator");

// Phase 4: Report ("No Exploit, No Report" gate)
await Task("Security Quality Gate", {
  findings: phase3Results.confirmedFindings,
  gate: "no-exploit-no-report",
  require_poc: true
}, "qe-quality-gate");

検出結果の分類

ステータス	意味	対応
confirmed-exploitable	PoC による悪用に成功	証拠を添えて報告
likely-exploitable	部分的な悪用に成功し、防御機構を検出	注意事項を添えて報告
not-exploitable	すべての悪用試行に失敗	レポートから除外
inconclusive	WAF／防御機構にブロックされ、脆弱性の有無が不明	手動レビュー用に報告

---

エクスプロイト・プレイブックのメモリ

名前空間の構造

aqe/pentest/
 playbook/
  exploit/{vuln_type}/{tech_stack}/{technique}
  bypass/{defense_type}/{technique}
  payload/{vuln_type}/{variant}
 results/
  validation-{timestamp}
 poc/
  {finding_id}-poc

学習ループ

1. 検証前：検出結果に一致する既知のパターンをプレイブックで照会します
2. 検証中：まず既知のペイロードを試します（成功率が高いため）
3. 検証後：新たに成功したパターンを信頼度スコアとともに保存します
4. 時間の経過とともに：エージェントは技術スタックごとに最も効果的なペイロードへと収束します

---

コスト最適化

シナリオ別の推定コスト

シナリオ	Tier の割合	検出数	推定コスト	推定時間
PR チェック（ソースのみ）	100% Tier 1	5	$0	<5s
スプリント検証	70% T1、30% T2	15	$2-5	5-10 min
リリース検証	40% T1、40% T2、20% T3	25	$8-15	15-30 min
完全なペンテスト	20% T1、30% T2、50% T3	40	$15-30	30-60 min

Shannon とのコスト比較

指標	Shannon	AQE ペンテスト検証
1 回あたりのコスト	~$50	$5-15（段階的な Tier）
実行時間	60-90 min	15-30 min（並列パイプライン）
誤検知率	低（エクスプロイトで実証）	低（同じ原則）
学習	なし（静的なプロンプト）	ReasoningBank プレイブック

---

成功指標

指標	目標	測定方法
誤検知の削減	検出結果の >60% を排除	検証前後の比較
エクスプロイト確認率	確認された検出結果の >80% が実際に悪用可能	手動での PoC 検証
1 回あたりのコスト	<$15 USD	パイプラインごとのトークン追跡
1 回あたりの時間	<30 分	実行時間の指標
プレイブックの拡充	6 か月後に 100+ パターン	メモリの名前空間数

---

関連スキル

• セキュリティテスト - OWASP 脆弱性スキャン、SAST／DAST の自動化
• コンプライアンステスト - 規制コンプライアンス
• API テストパターン - API セキュリティテスト
• カオスエンジニアリングのレジリエンス - カオス環境下でのセキュリティ

---

忘れないでください

「エクスプロイトなしに、報告なし。」 悪用を証明できない脆弱性スキャナーが提供する価値は不確かです。このスキルは、セキュリティ上の検出結果を、理論上のリスクから証拠を伴う実証済みの脆弱性へと変えます。確認された検出結果にはすべて、再現可能な概念実証（PoC）が付属します。すべての誤検知は、レポートに載る前に排除されます。

予測ではなく、証明を重視してください。 脆弱かもしれないものを報告しないでください。脆弱であるものを証明してください。