inspect-security

inspect-security — ソフトウェアセキュリティと脅威露出の監査

ドメイン基準

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

• 必須の対象スコープ：ユーザーは明示的な対象パス（file、directory、またはsubsystem）を必ず指定してください。対象スコープが指定されていない場合は、直ちに処理を停止し、ユーザーに"/inspect-security を呼び出す際は、明示的な対象スコープ（file、directory、またはsubsystem）を指定してください。"と促してください。リポジトリ全体を推測に基づいてスキャンすることは禁止します。
• 脆弱性対応の負債とリンターの細かな指摘：分析対象は、実際に対処可能な脅威露出、認可の不備、暗号の欠陥、汚染データのシンク、並行処理の競合に厳密に限定してください。基本的な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 refresh rotationの実装、残高変更のアトミックな条件付き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を呼び出す際は、明示的な対象スコープ（file、directory、またはsubsystem）を指定してください。」と促してください。
   • references/security-rubric.mdを読み、これを基準として評価します。

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

   • ターン内での実行（10ファイル未満またはまとまりのあるモジュール）：ルーブリックの各評価項目に照らして、ターン内でコードを直接監査します。
   • サブエージェントへの並列展開（複数パッケージにまたがる広範なサブシステム）：分割した範囲または呼び出し元が指定した予算に応じて、researchサブエージェントを動的に並行起動します（役割：Security Inspector (<Slice>)）。対象範囲の座標、発見した手がかり、ドメイン基準、出力契約を与えます（詳細な検証経路やPoCは.agents/scratch/security-<slice>-dossier.mdに委任します）。
   • セクション1のガードレールを徹底します。スタイル上のノイズは無視し、すべての指摘を[LOCAL-FIX]または[ARCHITECTURAL-REFACTOR]のいずれかに明示的に分類します。

3. 統合とターン停止の確認：

   • 指摘を標準出力の契約にまとめ、委任した報告書があればその参照先を示します。
   • セキュリティ態勢を確定します（HARDENED、LOCALIZED_RISKS、CRITICAL_EXPOSURE）。
   • 完成した報告書を会話に提示し、直ちにターンを停止します。