finding-discovery

セキュリティ上の問題の発見

脅威モデルと適用されるセキュリティポリシーに基づき、許可されたソース内で技術的に妥当なセキュリティ脆弱性を特定します。発見フェーズでは、後続の検証に備えて証拠を保持します。最終的な深刻度の判定は行いません。

出力を保存する前に ../../references/artifact-storage.md を読み、ソースのレビューを始める前に ../../references/security-guidance.md を読んでください。委任された割り当ても含め、レビュー対象となるパスごとに適用されるポリシーを確認してください。明示された入力パスと出力パスを尊重してください。明示的に必須とされる入力がなく、そのために依頼された分析を実行できない場合に限り、その入力を求めてください。

ワークフローの選択

Standard と Deep のワーカーは、このフェーズのスキルではなく、コーディネーターが用意した自己完結型のプロンプトを使用します。

• コンパクトな差分を処理する場合： list_codex_security_review_items を使って提供されたインベントリを読み込み、割り当てられた変更ファイルをすべてレビューし、record_codex_security_discovery_candidates を使って候補を一度だけ記録します。優先順位付き作業リスト、検出事項ごとの台帳、受領記録、発見レポートは作成しないでください。
• コンパクトなインベントリがない単独の差分レビュー： 変更ファイルの作業リストと保持するフェーズ成果物について、../security-scan/references/scan-artifacts-and-ledger.md を使用します。
• 単独のリポジトリ内の発見作業： 許可されたソースを対象に、以下の証拠基準を適用し、候補とカバレッジ上の制約を提示します。スキャンを開始したり、差分の作業リスト処理を実行したりしないでください。

差分をレビューする場合は、ベースラインのリビジョンで削除されたファイルも含め、実際に変更された動作を調査してください。影響を受ける境界を理解できる範囲まで関連コードを追跡し、変更された共通制御が他の呼び出し元にも影響する場合は、同類の呼び出し元にも調査を広げてください。無関係なリポジトリ全体の監査にまで範囲を広げないでください。

証拠基準

• 攻撃者が制御できる入力または特権操作を、最も関連性の高い制御からシンク、そしてセキュリティ上の影響まで追跡してください。制御が存在しない、回避可能、または誤った値や境界に適用されている理由を説明してください。
• 実行時に到達可能かどうか、およびデプロイメント上の前提を確認してください。実際に有効なガードと封じ込めを反証材料として記録してください。安全な同種の実装があるからといって、候補となるパスも安全だとは限りません。
• 主張の根拠となる制御の場所に加え、エントリーポイント、ラッパー、具体的な実装、シンクを保持してください。主張が複数の実装を対象とする場合は、すべてに影響すると断言するのではなく、それぞれの実装を調査してください。
• 独立して到達可能な脆弱なインスタンスは、個別に追跡できる状態にしてください。同一のソース／制御／シンク／影響に関する重複した観察は、見た目だけの違いで分割せず、統合してください。統合時も、影響を受ける場所と元の候補 ID をすべて保持してください。
• ユーザーまたはアドバイザリが明示したシードを、該当するソースと制御まで追跡してください。シードを裏付ける、否定する、または未解決のままにする証拠を記録してください。同じ種類の近接した問題だけでシードの確認を完了したことにはなりません。許可されたソース資料のみを使用し、許可なくアドバイザリのリンク先を取得しないでください。
• 具体的なセキュリティ上の影響と、保守性または堅牢性の懸念を区別してください。クラッシュ、危険な API、オプション機能、チェックの欠如は調査の手掛かりであり、それだけでは検出事項になりません。証明に不足がある候補も、証拠を捏造したり、実行可能な再現がないことを理由に除外したりせず、明示したうえで検証に引き継いでください。

有用な場合は、対象、範囲、関連するポリシー／モデル、および必須の結果フィールドを示して、独立したレビュー作業を利用可能なワーカー間で分担してください。親は未割り当ての作業をレビューし、重複を調整します。発見フェーズ内で、検証フェーズや攻撃経路の分析を繰り返さないでください。

候補の出力

各候補について、以下を保持してください。

• 安定した候補 ID とタイトル。提供されたシード ID または台帳 ID、および助言への参照を保持します。
• 影響を受けるファイル／行の位置。必要に応じて、entrypoint/wrapper、root_control、sink、concrete_implementation とラベル付けします。
• 攻撃者が制御するソース、最も近い制御、シンクまたは破損した制御、想定される影響、およびそれらを結び付けるソース上の証拠。
• 反証、デプロイの前提条件、未解決の質問、および検証で確認すべき事項。
• 判明している場合は CWE ID。判明していない場合は空のリスト。
• リポジトリまたはスコープ指定パスのインスタンスでは、呼び出し元が要求する場合にインスタンスキー <family>:<file>:<line>。
• 差分に関する所見では、関連する脆弱な動作が差分と重なる場合に限り relevant_lines。

呼び出し元が指定する構造化候補の契約に従ってください。レガシー差分の場合は、発見レポートと発見時の記録を ../../references/scan-artifacts.md に記載されたパスに保存してください。後続フェーズでは、それぞれの証拠と記録を管理します。割り当てられたソースレビューと具体的な追加確認をすべて処理したら完了です。未完了のレビューは正直に記録してください。もっともらしい候補が残っていない場合は、実際にレビューした範囲と制限事項を添えて、その結果を返してください。