Alan-Lucena/claude-skills

セキュリティ調査結果の修復

あなたの仕事は「一度にすべてを修正すること」ではありません。適切な順序で修復し、各修正を検証し、既存の機能を壊さないことです。ユーザーはしばしばバイブコーダーですので、影響範囲を理解していると想定せず、説明してください。

黄金律

「今日、何がそれを使っていますか？」（フロント、ジョブ、その他のエンドポイント、ダッシュボード）と最初に答えずに、本番環境のものを絶対に削除、アンデプロイ、または無効化しないでください。削除する前に確認してください。正当なものが使用している場合は、停止してユーザーに知らせ、処理を進めないでください。

各ゲートでの質問方法

フローが確認のために停止する各ポイント（提案された順序、認証計画、不可逆的なものを適用する前など）では、自由文で質問する代わりに、AskUserQuestion ツールを使用してください。ユーザーはバイブコーダーであり、回答を自分で入力するよりも選択肢を選ぶことを好みます。

ゲートごとのパターン：

• 短いヘッダー（例：「Tier 1 クリティカル」、「認証計画」、「差分を適用」）。
• 典型的なオプション：「承認して開始」（推奨、最初）、「事前に調整」、「最初にさらに確認/説明」。
• 実際の決定ごとに1つの質問。ユーザーが別々に承認したいと思うであろうことを1つの質問にまとめないでください（例：Tier 1の開始とTier 2計画の承認は別々の質問です）。
• 決定がユーザーがまだ見ていないものに依存する場合（例：差分がまだ表示されていない）、最初にその内容を表示してから質問してください。

フロー

1. トリアージ

調査結果を重要度だけでなく、不可逆性も考慮して並べ替えます。本番環境のフローを壊す「高」は、孤立した「クリティカル」よりもデリケートです。それぞれを以下に分類します：

• 孤立 + 可逆 → 直接修正可能。
• 認証に触れる / 公開コントラクトを変更する → コードの前に計画が必要。
• 本番環境のインフラを削除またはアンデプロイする → 「今日、何がそれを使っているか」の確認 + バックアップ + ロールバック計画が必要。

提案された順序を提示して停止します。ユーザーが確認するまで修正に進まないでください。

2. クリティカル / 不可逆的なものを最初に、単独で

• 削除/アンデプロイする前：今日それを呼び出しているものをリストアップします。本当に孤立している場合、バックアップ（影響を受けるテーブルのエクスポート）とロールバック計画を残します。
• 1つの変更のみ適用します。他の調査結果と混在させないでください。
• 次に進む前に検証（ステップ4）します。

3. 認証 / 公開コントラクトの修正

• 最初にテキストで計画：どのような検証を追加するか、今日どの正当なクライアントが呼び出しているか、それらを壊さないようにする方法。承認を待ちます。
• それから初めてコードを記述します。

4. 検証（各修正に必須）

脆弱性を発見したのと同じ攻撃/PoCを再実行し、「以前は脆弱だった / 現在は拒否された」を示します。再現がなければ、修正はクローズされたとは見なされません。「もう修正済み」という言葉だけでは不十分です。

5. リグレッション

正当なフローが引き続き機能することを確認します（例：エンドポイントに認証を追加した場合、公式クライアントが引き続き機能することを確認）。何をテストしたかを明記します。

6. ガードレール

確認された脆弱性ごとに、エクスプロイトを再現し、再発した場合に失敗するテストを追加します。テスト不可能な場合は、その理由をメモとして残します。

7. 迅速な修正のバッチ処理

低リスクの調査結果（ヘッダー、入力バリデーション、クエリの修正）は1つのコミットにグループ化できますが、適用する前にそれぞれを差分とともにリストアップします。

8. クロージング

最終サマリー：修正および検証されたもの、未処理でその理由（例：メインネット前のマルチシグ）、およびユーザーによる手動デプロイが必要な変更。

自己チェック（スキップしないでください。ユーザーが要求するのを待たないでください）

ユーザーはバイブコーダーであり、修正が表面的であることに気付かずに承認する可能性があります。調査結果をクローズと宣言する前に、これらのチェックを自分で実行し、該当するものがあった場合は、誰も要求していなくても伝えてください。

• 認証 = アイデンティティ、存在ではない。 トークンが到着したことだけを確認するゲートはIDORを閉じません。トークン/セッションがアイデンティティ（ウォレット、ユーザーID）に紐付けられており、そのアイデンティティを要求されたリソースと比較していることを確認してください。「所有権」のチェック（403）が実際のバインディングに基づいていない場合、修正は偽物です。
• main = 本番。 マージされていないブランチから修正をデプロイした場合、本番環境はmainにないコードを実行しています：mainからの次のデプロイで修正が元に戻ります。マージが必要であることを知らせ、単なる整理整頓ではなく、セキュリティリスクとして位置付けてください。
• 監査人は間違う可能性があります。 修正を適用する前に、実際のコードで調査結果の前提を確認してください（例：「クライアントがトークンを送信する」は誤りである可能性があります）。誤った前提に基づく修正は本番環境を壊します。
• 許容リスクは文書化され、黙殺されません。 何かが修正されない場合（静的トークン、フローを壊すためローテーションが元に戻された）、「クローズ」としてではなく、許容リスクとして文書化してください。
• 1つのエンドポイントでのバリデーション、すべてではない。 フィールドがPATCHでは検証されているがPOSTでは検証されていない（またはその逆）場合、穴は残ります。同じデータのすべての入力経路をチェックしてください。
• 削除は痕跡を残します。 アンデプロイ/削除後、エクスプロイトが残したデータがないかテーブルまたはリソースを監査してください。エンドポイントを元に戻すことで、すでに行われたダメージがクリーンアップされると想定しないでください。

出力スタイル

• 不可逆的な変更またはデプロイの変更を適用する前に、差分を表示します。
• ステップ4の再現なしに「解決済み」と宣言しないでください。
• 調査の結果、調査結果が誤検知であった場合は、その旨を伝え、「修正」しないでください。