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. 件数：TRUE POSITIVES X件、FALSE POSITIVES Y件
2. TRUE POSITIVEの一覧：それぞれについて、脆弱性の概要を記載します
3. FALSE POSITIVEの一覧：それぞれについて、却下した簡単な理由を記載します

参考資料

• 標準検証 — 単純なバグ向けの、直線的な1回のチェックリスト
• 詳細検証 — 複雑なバグ向けの、タスクベースの完全なオーケストレーション
• ゲートレビュー — 必須の6つのゲートと判定形式
• バグクラス別検証 — メモリ破損、ロジックバグ、競合状態、整数の問題、暗号、インジェクション、情報漏えい、DoS、デシリアライゼーションに関する、クラス固有の検証要件
• 誤検知パターン — よくある誤検知パターンに関する、13項目のチェックリストと警告サイン
• 証拠テンプレート — データフロー、数学的証明、攻撃者による制御、悪魔の代弁者レビューのためのドキュメントテンプレート