review-security

セキュリティレビュー

このスキルは、リファレンスライブラリ＋ワークフローです。patterns/ の下には、エビデンスに基づくセキュリティパターンファイルが20個あります。それぞれ、Linux カーネル、OpenSSL、Chromium、Firefox、curl、Go、Rust、Kubernetes、Next.js、および数十の他のプロジェクトにおける具体的な CVE、監査結果、レビュー手順に基づいています。

このスキルは2つの方法で呼び出せます。

• 単独で使用する場合：「このブランチのセキュリティレビューをしてください」— 以下のワークフローを最初から最後まで実行します。
• **/review から参照する場合：**マージ前レビューのスキルは、差分がセキュリティ上重要な領域に触れているときに、該当するパターンファイルを読み込みます。

各パターンファイルには、以下が含まれています。

• 核心となる問い — 常に念頭に置くべき1つの問い
• 確認項目 — 具体的なコードパターンと例
• 危険な兆候 — 危険を示すパターン
• カタログの参照情報 — 各パターンを示す実際の CVE

---

ステップ1：依頼された範囲を確定する

ブランチの場合は、対象の ref を確認し、base SHA、HEAD、merge-base を記録して、git diff <merge-base> <head> をレビューします。任意の ../../../scripts/review-scope.py --base <verified-ref> ヘルパーは、このエビデンスを記録します。依頼された場合に限りローカルの変更も含め、別途スナップショットを作成します。特定ファイルのレビュー依頼では対象が限定されますが、その呼び出し元を追跡する必要がある場合があります。いずれのランタイムでも、この読み込み済みパッケージを基準にパスを解決します。対象ファイルが変更された場合は停止し、範囲を再確定します。

範囲を確定したら、ステップ4のトリガーを評価します。該当するものがあれば、独立したパスをただちにバックグラウンドで開始し、その作業中にステップ2〜3を進めます。修正ごとに1回の検証を行えるよう、ステップ6の前に結果を統合します。

デフォルトでは報告のみを行います。修正を適用するには、修正の依頼または既存の承認が必要です。エビデンスが不足している場合、判定には制約が生じます。

ステップ2：関連するパターンファイルを選ぶ

20個すべてを読まないでください。以下の表を使って変更された対象領域を1〜4個のパターンに対応付け、何かを指摘する前に、該当する patterns/NN-*.md ファイルをそれぞれ読み込みます。パターンにはコード例と危険な兆候が含まれており、実際の CVE に照らして指摘内容を調整できます。

変更の種類 → 主なパターン

変更箇所…	主なパターン	副次的なパターン
バッファー／配列の処理（C/C++）	01, 11	06, 05
新しい API エンドポイント	03, 02, 16	12, 17
認証／ログインフロー	03, 04	07, 09
データベースクエリ	02, 03	20, 07
ファイルのアップロード／ダウンロード	17, 02, 03	18, 20
暗号処理	04	05, 11, 15
ネットワークプロトコル	10, 01	05, 17
設定の変更	12, 14	18, 03
依存関係の更新	08, 14	15
ロックファイルのずれ（package.json の Δ なし）	08	13, 14
レジストリ／インストール設定	08, 13	12, 18
CI/CD ワークフローの変更	08	13, 18
GitHub Actions のキャッシュ／OIDC スコープ	08, 13	18, 19
AI エージェントの設定（Claude/Cursor など）	08, 13	12, 18
リファクタリング／クリーンアップ	14, 07	06, 05
エラー処理	07	06, 19, 03
ロギングの変更	19	02, 12
コンテナ／デプロイ	18, 12	08, 13
シリアライズ／解析	02, 17, 01	09, 10, 20
並行処理／スレッド処理	05	06, 10
ユーザー入力の処理	02, 17	09, 20, 01
フロントエンド／UI コード	16, 02	09, 03
Go コード	07, 05, 09	06, 15
Rust の unsafe ブロック	06, 01	05, 15

20 のパターン（一覧）

01 境界と割り当て · 02 インジェクション · 03 認証 · 04 暗号の衛生管理 · 05 競合状態 · 06 メモリーのライフサイクル · 07 エラー処理 · 08 サプライチェーン · 09 型安全性 · 10 状態機械 · 11 整数演算 · 12 設定とデフォルト値 · 13 信頼境界 · 14 リグレッション防止 · 15 API コントラクト · 16 Web アプリケーションのセキュリティ · 17 検証と正規化 · 18 サンドボックスと分離 · 19 ロギングと可観測性 · 20 DoS 耐性

選択内容を出力します：「パターン 03, 02, 16 を適用します（新しい API エンドポイントと DB クエリ）。」

---

ステップ 3：各パターンを差分に適用する

選択した各パターンについて：

1. patterns/NN-*.md を読みます。
2. 「確認事項」の一覧に照らして、差分と、その差分から呼び出される参照先コードを調べます。具体的に、file:line を示し、指摘事項をパターンの「核心となる問い」と「危険信号」に結び付けます。
3. 流れを追い、流し読みしないでください。 パターンに「すべての長さフィールドを遡って追跡する」や「ミドルウェアチェーンを通るすべてのルートを列挙する」とある場合は、実際に呼び出しグラフをたどります。信頼境界や修正の完全性がパターンの対象となる場合は、Grep と Read を使って差分外のコードも調べます。
4. 主張を検証します。 「これは別の場所で処理される」と述べる場合は、該当行を示します。「テストでカバーされている」と述べる場合は、テスト名を挙げます。「おそらく安全」とは決して言わず、検証するか、未検証として指摘してください。

---

ステップ 4：敵対的レビュー（大幅な差分の場合）

ステップ 1 の後、条件に該当した場合に開始します。次のいずれかに該当する場合は、実行環境で利用可能なネイティブの委任ツールを使って、独立した読み取り専用レビューを行います（委任を利用できない場合は、対応できなかった範囲を報告してください）。

• 変更行数が 200 行を超える
• 暗号、認証、パーサー、デシリアライズ、または CI/CD ワークフローに触れる
• 新しい外部サービスまたは新しい依存関係を導入する
• ユーザーが明示的に詳細なレビューを依頼している

すでに独立したレビュー担当として割り当てられている場合は、そのレビューを完了し、再帰的に委任せずに、根拠を添えて親に報告します。

サブエージェントへのプロンプト： 「指定された絶対パスのチェックアウトで、指定された固定の base/head またはローカルスナップショットを、ファイルを変更せずにレビューしてください。あなたはセキュリティ監査担当者です。到達可能な攻撃経路を探し、悪用に必要な前提を検証してください。問題が見つからない場合も有効な結果です。レビュー範囲が不完全な場合は、その旨を明記してください。次の点を検討してください：認証のバイパス、見落としやすい経路（ログ、ファイル名、ヘッダー、テンプレートエンジン）を介したインジェクション、サイズ計算における整数オーバーフロー、チェックと使用の間の競合状態、フェイルオープンとなるエラー処理、ユーザー入力が特権コンテキストに到達する信頼境界違反、回帰を招くリファクタリング。各指摘には、ローカルでのトリガー、到達可能性、影響を記載してください。関連する CVE は裏付けとなる参考情報であり、証明ではありません。FIXABLE または INVESTIGATE に分類してください。」

FIXABLE の指摘はステップ 6 の Fix-First パイプラインに組み込みます。INVESTIGATE の指摘は情報提供として扱います。

---

ステップ 5：カタログとの照合（任意、大規模な監査の場合）

重要度の高いレビュー（リリース監査、新しい認証システム、新しい暗号コード）の場合は、指摘事項を次のカタログファイルと照合します。

• catalog/missed-in-review.md — コードレビューをすり抜けた 200 件のバグ
• catalog/caught-in-review.md — 監査／ファジング／静的解析／ピアレビューで検出された 106 件のバグ
• catalog/concurrency-and-crypto-bugs.md — 30 件の並行処理および暗号に関する不具合の詳細

これらのファイルは大きいため、指摘事項のパターン、CWE、API、またはバグの形状を Grep／rg で検索し、ファイル全体ではなく一致する項目のみを読みます。指摘事項がカタログ内のパターンと一致する場合は、「/orders/:id の IDOR — カタログの I30 と同じ形状」のように引用します。

---

ステップ 6：指摘事項と許可された修正

すべての指摘事項に処置を定めます。報告のみのモードでは、ファイルを変更せずに修正案を提示します。以下の修正分類は、修正が許可されている場合にのみ適用されます。

出力ヘッダー：Security Review: N findings (X critical, Y high, Z informational)

重大度の基準：

• CRITICAL — リモートから悪用可能、認証バイパス、RCE、データ流出、権限昇格
• HIGH — 認証済みアクセスで悪用可能、情報漏えい、共有インフラへの DoS
• INFORMATIONAL — 多層防御の不足、衛生上の問題、現時点では到達不能なリスクのあるパターン

指摘事項ごとに：

[SEVERITY] [pattern NN] file:line
  Problem: <1-2 lines>
  Evidence: <cite the red flag from the pattern file, or the CVE it matches>
  Fix: <concrete patch>

AUTO-FIX と ASK に分類します。/review と同じ Fix-First ヒューリスティックを使用します。機械的に修正できる項目（Secure／HttpOnly フラグの不足、タイムアウトの不足、アルゴリズムの許可リスト、定時間比較、パラメーター化クエリ）は AUTO-FIX です。設計上の判断が必要な項目（認証モデルの変更、エラー処理の再構成、レートリミッターの追加）は ASK です。

修正が許可されたモードでは、範囲を限定した AUTO-FIX 項目を適用し、変更後の動作を検証します。ASK 項目は 1 つの AskUserQuestion にまとめます。

• 各項目：重大度ラベル、パターンの参照、問題、推奨される修正
• 選択肢 A) 修正 B) スキップ
• 全体としての RECOMMENDATION を含める

ユーザーが承認した修正を適用します。

---

ステップ 7：判定

検出事項、検証範囲、ユーザーによるリスク受容を個別に記録してください。スキップされたブロッカーは未解決のままです。次のいずれかを提示してください。

• PASS — 必要な検証範囲が完了しており、未解決の CRITICAL または HIGH の検出事項はありません。情報提供のみの検出事項は記録してください。
• PASS WITH REMEDIATIONS — 必要な検証範囲が完了しており、CRITICAL／HIGH の検出事項が存在したものの、すべて修正され、検証済みです（自動修正またはユーザー承認済み）。修正内容を要約してください。
• INCOMPLETE — 必要な証拠または独立したレビューを利用できません。準備完了を主張しないでください。
• FAIL — 未解決の CRITICAL または HIGH の検出事項があります。それぞれについて、パターンの参照情報、問題点、修正に必要なことを列挙してください。マージしないでください。

---

重要なルール

• 指摘する前にパターンファイルを読んでください。 レッドフラグと Core Question を基準に、実際の CVE に照らして判断を調整してください。記憶だけに頼った指摘はノイズになります。
• 具体的に引用してください。 file:line、該当するレッドフラグ、可能であれば CVE／カタログエントリーを記載してください。曖昧な指摘は避けてください。
• パターンで求められる場合は差分の外も追跡してください。 認証、信頼境界、回帰防止を確認するには、差分だけでなく、差分が影響するコードも読む必要があります。
• コミット、プッシュ、PR の作成はしないでください。 修正は作業ツリー内でのみ行ってください。
• 前置きや「全体的によさそうです」といった表現は不要です。 検出事項または判定のみを提示してください。

---

/review との関係

• /review は、リリース前のすべてのチェックに使うワークフローです。対象範囲の逸脱、構造上の問題、設計、敵対的な観点からの確認、リリース判定を行います。差分がセキュリティ上重要な領域に触れる場合は、このスキルのパターンファイルを参照します。
• /review-security（このスキル）は、リファレンスライブラリ＋詳細監査ワークフローです。単独でセキュリティ監査に使用することも、/review に関連するパターンファイルをインラインで参照させることもできます。

この 2 つのスキルは互いに補完するものであり、置き換えるものではありません。