fix-finding

検出事項の修正

パスを選択したり、保持する出力を保存したりする前に、../../references/artifact-storage.md を読み、その保存ポリシーに従ってください。

目的

現在のセキュリティ検出事項を、最小限で検証済みのコード変更に反映します。コードがすでに安全な場合は、そのことを証明し、変更が不要だったと報告してください。

証拠に基づいて現在の状態を分類し、破られているセキュリティ境界を閉じ、正当な動作を維持し、選択した検証モードで必要なチェックに合格してください。これらの要件を満たす、リポジトリー本来の方法による最小限の変更を優先してください。

検証モード

呼び出し元が verificationMode: static を明示的に選択していない限り、standard 検証を使用してください。選択したモードは、委任レビューやワークベンチの各段階を含め、このスキル全体に適用されます。すべての委任先エージェントにこのモードを渡してください。

static モードでは、ソースコードと差分の証拠のみを評価します。検証手順で要求されている場合でも、依存関係のインストール、ビルド、テスト、再現コードの実行、アプリケーションの実行は行わないでください。リポジトリーを調査するツールは引き続き使用できます。ランタイムチェックを実施していないことを明記し、それらを合格として扱ったり、この評価で必須としたりしないでください。ランタイムのツールが不足しているだけならブロッカーにはなりませんが、ソースコードの証拠に重大な不足がある場合は blocked としてください。

パッチの要件

編集する前に、影響を受ける実装、その直接の呼び出し元、近接するヘルパー、および関連する既存のテストを調査してください。リポジトリーの証拠に基づき、次の事項を確認してください。

• 攻撃者が制御できる入力と、具体的なソースからシンクへの経路、または破られている制御
• セキュリティ不変条件と、それを適用する最も狭い共通の境界
• 維持すべき正当な動作、API、エラーの意味、および互換性の制約
• 最も近い既存の実装、検証、およびエラー処理の先例

検出事項は、単に挙げられた入力例の問題としてではなく、データフローと境界の問題として扱ってください。同等のエンコーディング、パーサー形式、エイリアス、呼び出し元、シンク、および提案する変更を迂回し得るセキュリティ上重要な状態の表現やコピーをすべて確認してください。安全でない状態を明示的に処理し、黙って受け入れたり、切り詰めたり、到達可能な別の形式に再解釈したりしないでください。

実装ワークフロー

1. 報告された経路をたどり、実際に共有されている境界を特定するために必要なコンテキストだけを調べます。リポジトリの根拠から、報告された経路がすでに安全だと分かる場合は、推測で変更せず no_change を返します。
2. 標準モードでは、可能であれば、その境界を通る最小限で情報量の多い再現と、同じ経路を通る正当な入力の確認を実行します。
3. 共有境界に対して、リポジトリの慣例に沿った最小限の修正を実装します。近くにあるヘルパーや確立された API を優先します。無関係な再設計、クリーンアップ、類似する別の指摘に範囲を広げないでください。
4. 検証の前に、修正を擁護するのではなく、疑ってかかります。変更した各ヘルパーのすべての直接の呼び出し元と、変更した各条件の両方の結果を調べます。脆弱なシンクに到達する類似の経路、表現、またはコピーが残っていないか、また修正によって新たに拒否または解釈し直される通常または既定の入力がないかを確認します。どちらかがあれば、実装を見直します。
5. 標準モードでは、変更の結果を検証します。
   • 最終的な差分を確認し、関連する最小限の構文、インポート、ビルド、または型チェックを実行します。
   • セキュリティ上のトリガー、または最も有力な対象限定の代替テストを再実行し、別種の悪意ある入力も確認します。
   • 正当な入力の確認、最も関連性の高い既存テスト、対象パッケージに適用される必須チェックを再実行します。

静的モードでは、代わりに次の検証ゲートを使用します。最終的な差分を確認し、変更した制御を通して元の攻撃経路と関連する代替入力をたどります。その後、呼び出し元と既存テストをソースとして調べ、正当な動作と互換性が維持されていることを確認します。各ゲートについて、根拠となるソースを示し、確認できない点を明記します。

脆弱性が実在する可能性があり、安全な修正を責任を持って完了または検証するうえで不可欠な証拠、ツール、アクセス、あるいは製品や互換性に関する判断が不足している場合は、blocked を返します。

修正をレビューする

修正を回避する経路が残っていないか、正当な動作に回帰が生じていないかを慎重に検討します。複雑さ、不確実性、セキュリティへの影響に応じて、独立した調査またはレビューを行います。新しい読み取り専用のレビュー担当者には、指摘事項、リポジトリのルート、許可された範囲、リポジトリのポリシー、検証モード、候補となる差分を伝え、作成者の説明やテスト結果の主張に頼らず、ソースから評価してもらいます。委任できない場合は、別の手順として自らレビューを行います。

修正を変更する前に、レビューでの懸念をソース、または標準モードでは対象限定の実行によって確認します。確認できた問題だけを指摘事項と互換性の範囲内で対処し、選択したモードの該当する検証ゲートを再実行します。修正によってセキュリティ境界が変わる、または新たな重大リスクが生じる場合は、レビューをやり直します。一時的な変更や無関係な変更が残っていないことを確認します。

Workbench Remediation Stages

Codex Security のワークベンチリクエストにスキャン ID、発生 ID、修正リクエスト ID、アクショントークン、期待されるバージョンが含まれている場合は、指定された修正ステージのみを実行してください。ステージの境界によってコードを書き込めるタイミングは変わりますが、前述の検証要件が緩和されることはありません。

• Generate：選択した対象のチェックアウトは変更しないでください。修正の作成やテストのために編集が必要な場合は、分離したワークツリーまたは一時コピーを使用してください。前述のパッチ契約と検証要件を適用し、ソースコードと回帰テストの変更をすべて含む正規の統合差分を1つ作成してから、指定されたワークベンチ ID を使用して generated または failed を記録してください。
• Apply：記録されたベースリビジョンとパッチダイジェストを確認してから、無関係な編集を加えずに、そのパッチのみを選択した作業ツリーに適用してください。applied または failed を記録してください。このステージでは、指摘事項を検証したり、クローズしたりしないでください。
• Verify：ソースコードを変更しないでください。前述の選択されたモードの検証ゲートを、記録されたパッチに対して実行してください。元の脆弱な経路が塞がれ、正当な動作が維持され、必要なチェックに合格したことを証拠で示せる場合にのみ、verified を記録してください。正確な証拠と、実行したコマンドを検証の概要に残してください。それ以外の場合は failed を記録し、失敗したゲートまたは証明上の不足を記載してください。指摘事項をクローズしないでください。

親スレッドが修正ステージを委任した場合、ワーカーはワークベンチを最終状態に更新するまで、そのステージの責任を負います。親はオーケストレーターに徹し、ワーカーの編集を重複して行ったり、チャットの応答を完了と見なしたりしてはなりません。

Outcome and Output Contract

呼び出し元から出力スキーマが指定されている場合は、それに従ってください。指定されていない場合は、最終回答に次の内容を含めてください。

• outcome：fixed、no_change、または blocked
• 具体的な脆弱な経路、セキュリティ不変条件、維持する必要のあった正当な動作
• 選択したパッチ戦略と、それがリポジトリの既存の方法を活用した最も限定的かつ完全な選択肢である理由。または、ブロックされた場合は未解決の製品上の判断
• 変更したファイル
• 追加したテストまたは検証用アーティファクト
• 実行したコマンドと、その合格、失敗、不明の結果
• 元の脆弱な経路が塞がれたことを示す証拠。ソースコードの評価と実行時に観測した証拠を区別してください
• 正当な動作が維持されたことをどのように確認したかの明示的な説明
• 残っている不確実性や、実施を見送った検証があればその内容

スキャンアーティファクトディレクトリを使用する場合は、../../references/scan-artifacts.md に従ってその場所を特定し、修正レポートのパスにレポートを出力してください。既存のスキャンディレクトリがない場合は、ユーザーからファイルを求められない限り、最終チャットの概要で十分です。

Hard Rules

• 選択したモードのすべての検証ゲートに合格するまで、fixed と報告してはなりません。リポジトリの証拠から無関係だと判断できる場合に限り、そのモードで必須のチェックを省略できます。必須チェックを実施できない場合、検証結果は blocked として報告しなければなりません。
• 標準モードでは、対象を絞ったテストまたは再現テストが実行可能な場合、コードの確認だけに頼ってはなりません。
• 完全に塞ぐために変更が必要だという証拠がない限り、無関係なクリーンアップ、関連する別の指摘事項、アーキテクチャの再設計にまでパッチを広げてはなりません。
• ユーザーの変更や、無関係なローカル変更を削除してはなりません。
• テストに合格させるために、認証、認可、テナント分離、入力検証、サンドボックス化、ロギングを弱めてはなりません。
• 証明上の不足を隠してはなりません。環境の制約で検証できない場合は、どのコマンドまたはセットアップが失敗したか、またどの証拠が不足しているかを正確に述べてください。