customize

vuln-pipeline をカスタマイズする

このパイプラインは、見解を明確にした C/C++ + AddressSanitizer のデモとして提供されています。実際の仕組みはもっと汎用的です。エージェントが入力を作成し、サンドボックス内でターゲットを実行し、検出器が作動し、2 つ目のエージェントが検証し、3 つ目のエージェントが悪用可能性を分析します。 この文に含まれる名詞はすべて置き換えられます。ユーザーにヒアリングし、どの名詞を置き換えたいのかを把握して、関連するファイルを書き換えてください。

既存の C/C++ コードは実例です。ドメインごとの手引きを用意する必要はありません。現状の内容を読み、汎用的な部分と ASAN 固有の部分を理解して、適応してください。

STEP 1 — パイプラインを読む（質問する前に行ってください）

質問の根拠を得るため、次のファイルに目を通してください。

• README.md — パイプラインの概要（偵察 → 発見 → 評価 → 判定 → レポート）
• harness/cli.py — オーケストレーション。各ステージの連携方法とディスクに保存される内容が分かります
• harness/find.py、harness/grade.py、harness/report.py — 3 つのコンテナーエージェントのループ。ほとんどが汎用的な基盤処理です
• harness/prompts/find_prompt.py、harness/prompts/grade_prompt.py — C/C++ 固有の部分。バグの分類、品質の段階、評価基準
• harness/prompts/report_prompt.py、harness/prompts/report_grader_prompt.py — こちらも C/C++ 固有です。悪用可能性のセクション（プリミティブ、ヒープ配置、権限昇格の経路）と、それらを採点する評価基準
• harness/prompts/judge_prompt.py — トリアージ用プロンプト。ASAN の抜粋とメモリー安全性に関するクラッシュの分類を基準にします
• harness/prompts/system_prompt.py — 認可ブロック。「C/C++ target」と「sanitizer output」が固定されています
• harness/asan.py — 重複排除／判定用のシグネチャを作るスタックトレースパーサー。ASAN 固有の正規表現を使います
• harness/artifacts.py — CrashArtifact、GraderVerdict、JudgeVerdict、ReportVerdict のデータ契約
• harness/config.py、targets/drlibs/config.yaml — ターゲット設定のスキーマ
• targets/README.md — ターゲットディレクトリの構成（Dockerfile + config.yaml + エントリーラッパー）

agent.py、docker_ops.py、recon.py、judge.py、novelty.py の詳細を把握する必要はありません。これらは汎用的な基盤処理です（判定／新規性のドメイン固有の要素は、フローではなくプロンプトと ASAN パーサーにあります）。ただし、注意点が 1 つあります。harness/ の一部は共有インフラストラクチャも兼ねています。dnr_harness/（検出・対応パイプライン）は、agent.py、sandbox.py、docker_ops.py、agent_image.py の build／ensure_base、auth.py、cli.py の resolve_target_dir／terminate_subprocesses、および prompts/system_prompt.py の load_engagement_context をインポートします。ドメインを移植する場合は、ドメイン固有のファイル（プロンプト、asan.py、artifacts.py、ターゲットの Dockerfile）のみを変更してください。共有ファイルを変更する場合は、両方のパイプラインに影響する変更として扱ってください。

STEP 2 — ユーザーにヒアリングする

要件を集めるには、AskUserQuestion を使用してください。まず全体的な背景を尋ね、回答に応じて技術的な詳細へと質問を絞り込んでください。

ラウンド 1 — コンテキスト（まずは必ず、まとめて質問）

相手が誰で、何を求めているのかを理解するための、自由回答形式の質問が 2 つあります。回答の多くは、自由記述の その他 から得られると想定してください。選択肢は考えるきっかけとして用意しているもので、回答を限定するためのものではありません。

質問 A — 運用コンテキスト

• header: Context
• question: What's your operating environment? Who will run this pipeline and why?
• options: 考えるためのいくつかの典型例 — 例：「ペネトレーションテスト企業 — クライアントの案件に対応し、報告可能な検出結果が必要」「社内のアプリケーションセキュリティチーム — CI で自社サービスをスキャン」「スマートコントラクト監査担当者 — デプロイ前のレビュー」「セキュリティ研究者 — 新たなバグの種類を探索」。これにより、重要となる出力形式、評価の厳密さ、ワークフローとの統合がわかります。

質問 B — 目標

• header: Goal
• question: Describe in your own words what you want this pipeline to find. What kind of target, what kind of bugs?
• options: 具体例を 2〜3 個（例：「HTTP サービスの SQLi/XSS のような Web の脆弱性」「Solidity コントラクトのリエントランシーやアクセス制御のバグ」「Java マイクロサービスのデシリアライゼーションによる RCE」）。

コンテキストに関する回答をもとに、追加質問を調整します。ペネトレーションテスト企業なら CVSS によるスコアリングや SARIF 出力を重視するでしょう。研究者なら差分テストや新たな検出シグナルを求めるかもしれません。社内チームなら CI 統合や誤検知率の低さを重視するでしょう。

ラウンド 2 — 技術的な追加質問（適応型 — ラウンド 1 の回答から導きます）

ラウンド 1 の回答を、以下の変動軸に照らして分析します。各軸に曖昧さが残る場合は、対象を絞った追加質問をしてください。AskUserQuestion の呼び出し 1 回につき、最大 4 問をまとめて質問できます。よくある追加質問は以下のとおりです。

• 検出シグナル — 「パイプラインは、何を検出したら問題を見つけたと判断しますか？」（クラッシュ、例外、カナリアファイルの出現、DNS コールバック、差分の不一致、不変条件への違反）
• PoC の形式 — 「概念実証はどのような形式ですか？」（単一ファイル、HTTP リクエストのシーケンス、トランザクションのリスト、テストパイプラインのコード）
• 分離 — 「ターゲットはどこで実行されますか？」（Docker、VM、テストネット、リモートサンドボックス、または実行なし — 静的解析のみ）
• 評価基準 — 「この分野では、どのような検出結果を高品質、または低品質とみなしますか？」
• 悪用可能性の分析 — 「レポートにはどのようなセクションを含めるべきですか？」C/C++ のレポートには、プリミティブ・到達可能性・ヒープレイアウト・権限昇格の経路・制約事項が含まれます。Web 脆弱性のレポートでは、インジェクションベクター・認証の回避・データの露出・脆弱性の連鎖の可能性が必要になるかもしれません。必要な内容、またはレポートの工程自体が必要かどうかを確認してください。
• 新規性／アップストリームの確認 — 「検出結果がアップストリームですでに修正済みか、パイプラインで確認しますか？」C/C++ 版では、ターゲットの GitHub リポジトリを浅くクローンし、git log <commit>..HEAD -- <crash_file> を確認します。正規のアップストリームがあり、キーとして使う妥当な「クラッシュしたファイル」があるターゲットにのみ適用されます。多くの分野には当てはまりません。
• スコープ — 「C/C++ のサポートを完全に置き換えますか？それともプロファイルシステムを介して、新しい分野と並行して維持しますか？」

STEP 3 のアーキテクチャマップの全行を埋められるまで続けてください。回答が曖昧な場合は、推測するのではなく、さらに絞り込んだ質問をしてください。

背景 — 変化の軸（追加質問の作成に役立つコンテキスト）

これらは、顧客が C/C++ のデモから変更したいと考える可能性のある観点です。このリストを使ってユーザーの説明に不足している点を見つけ、追加質問を作成してください。メニューとして提示してはいけません。

脆弱性の種類： メモリ安全性 · Web/API（SQLi、XSS、SSRF、XXE、パストラバーサル、IDOR） · デシリアライズによる RCE · ロジック／競合（TOCTOU、権限昇格） · 暗号（弱い RNG、タイミング、ノンス再利用） · DoS（ReDoS、ハッシュフラッディング） · スマートコントラクト（リエントランシー、アクセス制御、フロントランニング） · ML/AI（プロンプトインジェクション、ジェイルブレイク、データ抽出） · プロトコルの解析

ターゲットの形態： CLI バイナリ＋ファイル · HTTP サービス · テストハーネス経由のライブラリ · ネットワークデーモン · スマートコントラクト · ブラウザー拡張機能 · モバイルアプリ

検出メカニズム： クラッシュ／中断 · 未捕捉例外 · サニタイザーフック（Jazzer/Atheris） · 結果ベース（カナリアファイル、DNS コールバック、シェルの起動） · 差分テスト · 不変条件違反 · 汚染追跡

入力形式： 単一ファイル · HTTP リクエストチェーン · 複数ファイルのアーカイブ · stdin ストリーム · 引数＋環境変数＋設定の組み合わせ · トランザクションシーケンス

隔離境界： Docker コンテナ · 完全な VM · リモートサンドボックス · ローカルテストネット · なし（静的解析）

重複排除シグネチャ： (crash_type, top_frame) · (vuln_type, endpoint, param) · (function, state_transition) · (component, precondition)

レポートの構成： プリミティブ／ヒープ／権限昇格（メモリ安全性） · ベクトル／認証／露出（Web） · 不変条件／パス／影響（コントラクト） · または、検出と評価が成果物であればレポートの段階自体を省略

出力形式： result.json + poc.bin · SARIF · Nuclei テンプレート · 文章形式のレポート

パッチ検証シグナル： ASAN で問題なく終了 · 未捕捉例外なし · サニタイザーフックが無反応（Jazzer/Atheris） · カナリアファイルに変更なし · 不変条件のアサーションが成立 · 差分出力が参照と一致。これが patch_grade.py の _t1_passes() で定義されている、新しいドメインにおける「バグがなくなった」という判定です。

背景 — アーキテクチャマップ（変更するものと変更しないもの）

ファイル	C/C++ 固有？	内容
harness/prompts/find_prompt.py	はい — 書き換え	バグの分類、品質ティア、ASAN 出力形式、終了コードの例
harness/prompts/grade_prompt.py	はい — 書き換え	5 つの基準から成る評価基準は、ASAN トレースと Unix のシグナル終了コードを前提としています
harness/prompts/report_prompt.py	はい — 書き換え	悪用可能性のセクション：プリミティブ、ヒープレイアウト、エスカレーション経路 — メモリ安全性に特化しています
harness/prompts/report_grader_prompt.py	はい — 書き換え	上記のセクションを評価します。評価基準はセクション構成に結び付いています
harness/prompts/judge_prompt.py	はい — 書き換え	ASAN の抜粋とクラッシュ分類を基にトリアージします
harness/prompts/patch_prompt.py	はい — 書き換え	git diff -- '*.c' '*.h' を求め、ASAN トレースと memcpy 形式の根本原因に関するガイダンスを前提としています
harness/prompts/system_prompt.py	はい — 書き換え	認可ブロックに「C/C++ ターゲット」「サニタイザー出力」と記載されています
harness/asan.py	はい — 書き換え	#N 0xHEX in func /path:line フレーム用の正規表現です。重複排除、判定、新規性評価に使用されます
targets/README.md + Dockerfile テンプレート	はい — 書き換え	gcc -fsanitize=address、entry.c ラッパーパターン
harness/patch_grade.py	軽微な編集	_t1_passes() は AddressSanitizer: の部分文字列をチェックします。検証の残りの手順は汎用的です
harness/report.py	軽微な編集	_SECTIONS タプルとトークンリストを新しいレポート構成に合わせる必要があります。処理の流れは汎用的です
harness/novelty.py	軽微な編集	crash_file_from_frame() は ASAN 固有です。git-log のロジックは汎用的です。上流がなければファイル全体を削除します
harness/config.py	軽微な編集	新しいフィールド（profile、binary_path の代わりの run_command）が必要になる可能性があります。attack_surface はそのまま使えそうです
harness/artifacts.py	軽微な編集	crash_type／exit_code の意味合いが変わる可能性があります。ReportVerdict.section_scores のキーは新しいセクションと一致させる必要があります
harness/dedup.py	軽微な編集	シグネチャ関数には新しいパーサーが必要です。グループ化ロジックは汎用的です
harness/prompts/recon_prompt.py	軽微な編集	ほぼ言語に依存しません。C 固有の慣用表現を取り除きます
harness/cli.py	変更なし	オーケストレーションはドメインに依存しません
harness/agent.py	変更なし	エージェントランナーは汎用的です
harness/docker_ops.py	変更なし	コンテナーの制御は汎用的です（分離方式が Docker 以外の場合は変更が必要になる可能性があります）
harness/find.py、grade.py、recon.py、judge.py、patch.py	変更なし	処理の流れは汎用的です。変更するのは注入するプロンプトだけです

ステップ 3 — 計画を提示して確認を得る

編集を始める前に、以下の内容をユーザーに要約して伝えます。

1. 理解したこと — ユーザーの目標を 1 文で言い換えます
2. 変更するもの — 編集するファイルと、それぞれの変更理由を 1 行で列挙します
3. 変更しないもの — オーケストレーションのコアには手を加えないことを伝えます。上記の共有ファイル（dnr_harness/ でも使用されています）に計画が及ぶ場合は、その旨と理由を明示します
4. 未解決の質問 — まだ不明な点があれば記載します

明示的な承認を待ちます。計画に修正があった場合は反映し、再度確認を得ます。

ステップ 4 — 実行

承認された計画に従ってファイルを編集します。依存関係の順に進めます。まずプロンプトとパーサー（これらは単独で扱えます）、次に設定とアーティファクト、その後にターゲットテンプレート、最後に README を編集します。ユーザーがチェックポイントを希望する場合は、段階的にコミットします。

STEP 5 — 検証

1. 新しいクラスのバグを2～3個仕込んだcanaryターゲットをtargets/<domain>-canary/の下に追加します
2. 次を実行します：bin/vp-sandboxed run <domain>-canary --model <model-id> --runs 3 --parallel --stream --max-turns 50（ユーザーが別のモデルを指定しない限り、Claude Opusを使用します）。サンドボックスがまだセットアップされていない場合は、最初に./scripts/setup_sandbox.shを1回実行します。
3. 仕込んだバグがすべて見つかり、PASSと判定されることを確認します
4. ジャッジによるトリアージが機能したことを確認します：cat results/<domain>-canary/<ts>/reports/judge_log.jsonl — バグごとにNEWが1件、重複にはDUP_SKIPが記録されることを確認します
5. レポートが出力されたことを確認します：ls results/<domain>-canary/<ts>/reports/bug_*/report.jsonを実行し、セクションスコアを抜き取り確認します
6. vuln-pipeline dedup results/<domain>-canary/を実行し、シグネチャが正しくグループ化されることを確認します