fp-check

誤検知の確認

使用する場面

• 「このバグは実在しますか？」または「これは真陽性ですか？」
• 「これは誤検知ですか？」または「この指摘を検証してください」
• 「この脆弱性が悪用可能か確認してください」
• 特定のバグの疑いを検証または確認する依頼全般

使用しない場面

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

退けるべき合理化

次のいずれかを考えていることに気づいたら、すぐに中止してください。

合理化	誤りである理由	必須の対応
「残りのバグを迅速に分析する」	すべてのバグを十分に検証する必要があります	タスクリストに戻り、次のバグをすべてのフェーズに沿って検証する
「このパターンは危険そうなので、脆弱性だ」	パターン認識は分析ではありません	結論を出す前に、データフローを最後まで追跡する
「効率化のために完全な検証を省略する」	部分的な分析は認められません	選択した検証パスの手順をすべて実行する
「コードが安全でなさそうなので、データフローを追わずに報告する」	安全でないように見えるコードでも、上流で検証されている可能性があります	ソースからシンクまでの完全な経路を追跡する
「似たコードが別の場所で脆弱だった」	検証や呼び出し元、保護策はコンテキストごとに異なります	この箇所を個別に検証する
「これは明らかに重大だ」	LLM はバグを見つけやすく、深刻度を過大評価する傾向があります	デビルズアドボケイトレビューを完了し、証拠に基づいて立証する

---

ステップ 0：主張とコンテキストを理解する

分析を始める前に、バグについて自分の言葉で言い換えてください。明確に言い換えられない場合は、ユーザーに説明を求めてください。誤検知の半数はこの段階で解消されます。主張を正確に言い換えると、筋が通らないことがわかるためです。

次の事項を記録してください。

• 脆弱性についての具体的な主張は何ですか？（例：「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項目のチェックリストと警告サイン
• エビデンステンプレート — データフロー、数学的証明、攻撃者による制御、悪魔の代弁者レビューのためのドキュメントテンプレート