mcpField
V
verify-fix

verify-fix

github.com/openaiセキュリティ11.2k51 回インストール今日更新
リポジトリ

verify-fix について

明示的な依頼に基づき、現在のチェックアウトでセキュリティ修正を検証する読み取り専用スキルです。元の攻撃経路、関連する制御や回避経路、正当な動作を確認し、リポジトリや課題管理を変更しません。

主な機能

  1. 01指摘ごとの修正ステータス判定
  2. 02元の攻撃経路と境界の追跡
  3. 03関連制御と回避可能性の確認
  4. 04リポジトリファイルを変更しない評価
  5. 05標準モードと静的モード

活用シーン

  1. 01報告された脆弱性の修正確認
  2. 02コード再構成後の攻撃経路の確認
  3. 03テストを実行しない静的な修正評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openai/codex-security --skill verify-fix

インストール後、Claude Code で/verify-fixを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

修正の検証

使用するタイミング

セキュリティ修正の検証を明示的に依頼された場合に限り、このスキルを呼び出してください。$verify-fix を直接呼び出した場合も含みます。修正の実装やテストの実行を依頼されただけでは、このスキルの使用を求められたことにはなりません。それ以外のタスクでは、ユーザーが指定したワークフローと回答形式に従ってください。

目的

提示された各セキュリティ指摘が、現在のチェックアウトで修正されているかどうかを判定します。単独の検証専用モードで作業してください。リポジトリのファイルの作成、変更、削除、パッチの適用、変更のコミット、成果物の書き込み、課題管理システムの変更は行わないでください。

評価方法

../../references/static-finding-assessment.md を使用して、元の攻撃者が制御できるソース、セキュリティ制御、機密性の高いシンク、到達可能な経路、信頼境界、反証となる情報、証明の不足点を特定してください。呼び出し元がその参照資料をすでにプロンプト内で提示している場合は、再度読み込まず、提示された内容を使用してください。

呼び出し元が verificationMode: static を明示的に指定しない限り、standard モードで検証してください。static モードでは、現在のソースと差分、元のエクスプロイト経路と想定される回避策、呼び出し元やソースとして読み取った既存テストを通じた正当な動作を評価してください。検証の指示に実行を求める内容が含まれていても、依存関係のインストール、ビルド、テスト、再現手順の実行、アプリケーションの起動は行わないでください。リポジトリを読み取るツールは引き続き使用できます。証拠には、これが静的評価であり、実行時チェックは行っていないことを明記してください。それらを合格として扱ったり、この評価に必須としたりしてはいけません。実行時ツールが不足しているだけで結論不能になることはありませんが、ソースの証拠に重大な不足がある場合はその限りではありません。

検証ワークフロー

  1. 元の脆弱性、その前提条件、影響を受けるセキュリティ境界、継続すべき正当な動作を特定します。
  2. 現在のチェックアウトに影響を受けるコンポーネントが含まれていることを確認します。ファイルが見つからないこと、行が削除されていること、関数名が変わっていることを修正の証拠とせず、移動またはリファクタリングされたコードを追跡してください。
  3. 現在の実装において元のエクスプロイト経路をたどり、最も関連性の高い制御、同等の経路、想定される回避策を確認します。
  4. standard モードでは、リポジトリを変更せずに実行できる場合に限り、元の再現手順、対象を絞った回帰チェック、または正当な動作のチェックを実行します。実行時チェックが利用できない場合は、正確な静的証拠を保持してください。
  5. 提示された各指摘について、指定された順序で結果を返します。クローズ済みのチケット、無関係なテストの合格、新しいスキャンで指摘が検出されなかったことは、十分な証拠として扱わないでください。

結果の形式

対話形式の場合は、呼び出し元が別の形式を求めない限り、読みやすい Markdown を使用してください。各指摘の判定を示し、根拠となる証拠をソースへの参照とともに説明し、関連するチェックと残る証明上の不足点を明らかにしてください。

呼び出し元が JSON を要求した場合、または自動処理用の結果形式を提示した場合は、次の形式で JSON オブジェクトを 1 つだけ返してください。CLI の検証ワークフローでは、この形式が明示的に求められます。どちらの形式でも、同じ判定と証拠要件を使用してください。

{
  "results": [
    {
      "id": "finding-or-issue-id",
      "status": "fixed|still_vulnerable|inconclusive",
      "evidence": "specific current source, exploit, test, or proof-gap evidence"
    }
  ]
}
  • fixed は、元のセキュリティ境界が閉じられ、正当な動作も維持されていることを証拠が示す場合に限り使用してください。
  • still_vulnerable は、元の脆弱な経路に引き続き到達可能であることを証拠が示す場合に限り使用してください。
  • inconclusive は、リポジトリの不一致、元のコンテキストの不足、選択したモードで必要なチェックが利用できないこと、正当な動作を維持する制御が証明されていないこと、またはその他の重大な証明上の不足がある場合に使用してください。

読み取り専用の境界を弱めたり、別の脆弱性に置き換えたり、証拠の不足を隠したりして、判定を実際より強いものにしてはいけません。

コメント