誤検知チェック

使用する場合

• 「このバグは本当か？」または「これは真の脆弱性か？」
• 「これは誤検知か？」または「この発見を検証する」
• 「この脆弱性が実際に利用可能か確認する」
• 疑われている特定のバグを検証・確認するすべてのリクエスト

使用しない場合

• バグの発見・探索（「バグを見つける」、「セキュリティ分析」、「コード監査」）
• スタイル、パフォーマンス、保守性に関する一般的なコードレビュー
• 機能開発、リファクタリング、またはセキュリティ以外のタスク
• ユーザーが検証なしの簡易スキャンを明確に要求する場合

拒否すべき言い訳

これらのいずれかの思考に気づいたら、STOP してください。

言い訳	何が間違っているのか	必要なアクション
「残りのバグを迅速に分析する」	すべてのバグは完全な検証が必要	タスクリストに戻り、すべてのフェーズを通じて次のバグを検証
「このパターンは危険そうだから脆弱性だ」	パターン認識は分析ではない	結論の前にデータフロー全体をトレース
「効率のために完全な検証をスキップする」	部分的な分析は許可されない	選択した検証パスに従ってすべてのステップを実行
「コードが安全でなく見えるから、データフロー追跡なしで報告する」	安全でなく見えるコードも、上流の検証を持つかもしれない	ソースからシンクまでの完全なパスをトレース
「同じコードが別の場所で脆弱だった」	各コンテキストは異なる検証、呼び出し元、保護を持つ	この特定のインスタンスを独立して検証
「これは明らかに重大だ」	LLMはバグが見える傾向にあり、重大度を過大評価する	悪魔の代弁人レビューを完了; 証拠で証明する

---

ステップ 0: 請求と背景を理解する

分析の前に、バグを自分の言葉で言い直してください。明確にできない場合は、AskUserQuestion を使ってユーザーに明確化を求めてください。誤検知の半分はこのステップで崩れます — 請求が正確に言い直されると、一貫性のある意味を持たなくなるからです。

以下を文書化してください：

• 正確な脆弱性請求は何か？ (例：「content_length が 4096 を超える場合の parse_header() のヒープバッファオーバーフロー」)
• 主張される根本原因は何か？ (例：「142 行目の memcpy の前にある境界チェックの欠落」)
• 想定されるトリガーは何か？ (例：「攻撃者が Content-Length ヘッダが大きすぎる HTTP リクエストを送信」)
• 請求される影響は何か？ (例：「制御されたヒープ破損を通じたリモートコード実行」)
• 脅威モデルは何か？ このコードはどの特権レベルで動作しますか？サンドボックス内ですか？攻撃者はこのバグをトリガーする前に既に何ができますか？ (例：「認証されていないリモート攻撃者対特権ローカルユーザー」; 「Chrome レンダラーサンドボックス内で実行」対「サンドボックスなしで root として実行」)
• バグクラスは何か？ バグを分類し、クラス固有の検証要件について bug-class-verification.md を参照してください。これは下記の一般的なフェーズを補完します。
• 実行コンテキスト: 正常実行中、このコードパスはいつどのように到達されますか？
• 呼び出し元分析: このコードを呼び出す関数は何で、どのような入力制約を課しますか？
• アーキテクチャコンテキスト: これは複数の保護層を持つ大きなセキュリティシステムの一部ですか？
• 歴史的背景: このコード領域の最近の変更、既知の問題、または以前のセキュリティレビューはありますか？

ルート: 標準検証対深度検証

ステップ 0 の後、検証パスを選択してください。

標準検証

これらすべてが成立する場合に使用：

• 明確で具体的な脆弱性請求（曖昧でない）
• 単一コンポーネント — バグパスにおいてクロスコンポーネント相互作用がない
• よく理解されたバグクラス（バッファオーバーフロー、SQL インジェクション、XSS、整数オーバーフロー等）
• トリガーに関与する並行処理や非同期処理がない
• ソースからシンクへの単純なデータフロー

standard-verification.md に従ってください。タスク作成なし — 線形チェックリストを通じて作業し、インラインで結果を文書化してください。

深度検証

これらのいずれかが成立する場合に使用：

• 複数の方法で解釈できる曖昧な請求
• クロスコンポーネントバグパス（データが 3 つ以上のモジュールまたはサービスを通じてフロー）
• トリガーメカニズムにおけるレースコンディション、TOCTOU、または並行処理
• 明確な仕様がないロジックバグ
• 標準検証が決定的でなかったか段階的に進みました
• ユーザーが完全な検証を明確に要求する

deep-verification.md に従ってください。完全なタスク依存グラフを作成し、プラグインのエージェントとともにフェーズを実行してください。

デフォルト

標準から始めてください。標準検証には 2 つの組み込み段階的進行チェックポイントがあり、複雑性が線形チェックリストを超えると深度検証にルーティングします。

バッチトリアージ

複数のバグを一度に検証する場合：

1. すべてのバグに対してまずステップ 0 を実行 — 各請求を言い直すことは、しばしば明らかな誤検知をすぐに崩します
2. 各バグを独立してルート（一部は標準、他は深度かもしれません）
3. すべての標準ルートバグを最初に処理し、その後深度ルートバグを処理
4. すべてのバグが検証された後、エクスプロイトチェーン を確認 — 個別にゲートレビューに失敗した発見が組み合わさって実行可能な攻撃を形成するかもしれません

最終サマリー

疑われているすべてのバグを処理した後、以下を提供してください：

1. カウント: X つの真陽性、Y つの偽陽性
2. 真陽性リスト: 各々、簡潔な脆弱性説明付き
3. 偽陽性リスト: 各々、拒否の簡潔な理由付き

参照資料

• 標準検証 — 直線的でシンプルなバグ用の線形単一パスチェックリスト
• 深度検証 — 複雑なバグ用の完全なタスクベース調整
• ゲートレビュー — 6 つの必須ゲートと判定形式
• バグクラス検証 — メモリ破損、ロジックバグ、レースコンディション、整数問題、暗号、インジェクション、情報開示、DoS、および逆直列化に対するクラス固有の検証要件
• 誤検知パターン — 一般的な誤検知パターン用の 13 項目チェックリストと赤旗
• 証拠テンプレート — データフロー、数学的証明、攻撃者制御、および悪魔の代弁人レビューに関する文書化テンプレート