inspect-security

inspect-security — ソフトウェアセキュリティと脅威エクスポージャーの監査

ドメイン別基準

1. スコープと許容範囲のガードレール（無視する項目）

• 必須の対象スコープ：ユーザーは明示的な対象パス（file、directory、またはsubsystem）を必ず指定してください。対象スコープが指定されていない場合は、ただちにターンを中断し、ユーザーに次のように促してください：「/inspect-securityを使用する際は、検査対象の範囲（ファイル、ディレクトリ、またはサブシステム）を明示してください。」推測によるリポジトリ全体のスキャンは禁止します。
• 脆弱性の負債とリンターの細かな指摘：分析は、対処可能な脅威エクスポージャー、認可の不備、暗号処理の欠陥、汚染データのシンク、並行処理の競合状態に厳密に限定してください。基本的なASTの書式、構文上のスタイルの好み、空白については、すべてネイティブリンターに任せてください。
• 準拠する参照資料：セキュリティパターンは、references/security-rubric.mdのみに照らして厳密に評価してください。

2. 判断の分岐：[LOCAL-FIX] と [ARCHITECTURAL-REFACTOR]

• [LOCAL-FIX]（関数内の局所的なパッチ）：生のORMクエリのパラメーター化、Math.random()のCSPRNGへの置き換え、事前ハッシュ化を伴う定時間のtimingSafeEqualの追加、厳格なDTOスキーマのホワイトリスト化、ストリームのio.LimitReaderによるラップ、またはJWTアルゴリズムの固定が該当します。動作に影響する修正は/changesetに回してください。/forgeは、サポート対象で承認済みの変更セットがある場合にのみ使用してください。
• [ARCHITECTURAL-REFACTOR]（システム全体にわたる構造的な強化）：テナント分離のためのPostgreSQL Row-Level Security（RLS）の導入、SSRF緩和のための専用Egress Proxy（Smokescreen/Envoy）の配備、侵害時の連鎖処理を伴うToken Familyのリフレッシュローテーションの実装、残高の変更処理のアトミックな条件付きSQL／台帳への移行、または分散スライディングウィンドウ型レート制限の導入が該当します。修正は/changesetに回してください。

正式な出力仕様

# Security Audit Dossier: <Target Scope>

## 1. Executive Summary
- **Target Inspected**: `<directory_or_file_path>`
- **Security Posture**: <HARDENED | LOCALIZED_RISKS | CRITICAL_EXPOSURE>
- **Primary Threat Vector**: <Single-sentence summary of highest-severity exploit scenario or systemic hazard>

## 2. Load-Bearing Defect Catalog
### [<CRITICAL | HIGH | MEDIUM>] [<LOCAL-FIX | ARCHITECTURAL-REFACTOR>] <Dimension>: `<Target Symbol / Route>`
- **Offending Code**: [<file>#L<N>](file:///path/to/file#L<N>)
- **Violated Rubric**: [<spec_or_dimension>](references/security-rubric.md#anchor)
- **Threat & Exploit Scenario**: <Observable attack vector, failure mode, or privilege escalation scenario>
- **Action**: <[LOCAL-FIX] Local patch OR [ARCHITECTURAL-REFACTOR] Systemic architecture hardening>

*(Emit 'No load-bearing security defects observed across rubric dimensions' if clean)*

ルーティング

• サポート対象の変更セットが、セキュリティ修正と必要な検証をすでに承認している →（/forge経由）。
• 認可、暗号処理、またはデータコントラクトの変更を含み、スコープの段階的な適用が必要な局所的またはシステム全体のセキュリティパッチ →（/changeset経由）。

実行プロトコル

1. 受付とスコープゲート：

   • 対象スコープ（file、directory、またはsubsystem）を取り込みます。
   • スコープゲートの適用：明示的なスコープが指定されていない場合は、ただちにターンを中断し、ユーザーに次のように促してください：「/inspect-securityを使用する際は、検査対象の範囲（ファイル、ディレクトリ、またはサブシステム）を明示してください。」
   • references/security-rubric.mdを読み、内容に基づいて判断します。

2. 規模に応じた実践的な監査：

   • ターン内での実行（10ファイル未満、または一貫性のあるモジュール）：基準の各項目に照らして、ターン内でコードを直接監査します。
   • サブエージェントへの分割（複数パッケージにまたがる広範なサブシステム）：スライスの座標、発見したアンカー、ドメイン別基準、出力仕様を与えて、researchサブエージェントを2～3個起動します（役割：Security Inspector (<Slice>)）。
   • セクション1のガードレールを適用します：スタイル上のノイズを無視し、すべての指摘を[LOCAL-FIX]または[ARCHITECTURAL-REFACTOR]として明示的に分類します。

3. 統合とターン終了ゲート：

   • 指摘を正式な出力仕様にまとめます。
   • セキュリティ態勢を確定します（HARDENED、LOCALIZED_RISKS、CRITICAL_EXPOSURE）。
   • 完成した監査報告書を会話に提示し、ただちにターンを終了します。