security-gate

セキュリティゲート

小さな役割が2つあります。（1）ユーザーがまだ機能を選んでいる段階で threat-model-lite を適用し、後続のフェーズでセキュリティ上の判断を推測せずに済むようにします。（2）各スライスに deep-pass trigger リストを適用し、該当するスライスがその判断に照らして検証されるようにします。このスキル自体はレビューを行いません。レビューを行うのは full-review です。

以下の2つのキーワードは、作業中に名前を付けて扱うものです。threat-model-lite の質問は、今すぐ人間に尋ねる質問です。deep-pass trigger は、後でより詳細なレビューを必須にする変更の特性です。

Threat-model-lite — 仕様作成時のチェックリスト（対話形式）

要件のヒアリング中に実施してください。リポジトリの事実は根拠に基づいて確認し、未解決のセキュリティ上の判断だけをヒアリングの質問候補に戻します。これらの質問は5つという上限を共有します。2回目の質問を送らないでください。回答は shared/references/answer-evidence.md を使って、移植可能な情報源の権威性を確保しながら、判断記録に残します。to-prd はその内容を PRD の Security Decisions セクションに引き継ぎます。

記録済みの判断は、安定した ID とソースインデックスの参照を使って再利用します。各スライスは、それぞれ独自の deep-pass trigger を評価します。判断を共有していても、リスク分類を共有するわけではありません。重要でない詳細に限り、安全で対象範囲を限定した既定値を使ってください。アクセス、データの取り扱い、範囲、コスト、許可される影響、または未解決のセキュリティ上の判断に答えが影響する場合にのみ質問してください。返答がないことは承認を意味しません。

1. アクターと認証：誰がこれを呼び出せますか？各アクションにはどのロールや権限が必要ですか？未認証または不適切なロールでのアクセスにはどう対応しますか？
2. 信頼できない入力：ユーザーや外部システムからどのようなデータが届きますか？どこで検証し、何を拒否しますか？
3. データの機密性：PII、認証情報、トークン、金融データを扱いますか？どこに保存、記録、送信しますか？ログやエラーメッセージに絶対に含めてはならないものは何ですか？
4. シークレット：新しいキー、トークン、認証情報はありますか？どこに保管しますか（環境変数、シークレットマネージャー）？誰がローテーションしますか？
5. 依存関係：新しいパッケージやサービスはありますか？なぜそれを選ぶのですか？侵害された場合の影響範囲はどの程度ですか？
6. テナントとアクセス範囲：あるユーザーのリクエストが別のユーザーのデータを読み書きする可能性はありますか？その境界は何によって強制されますか？
7. 悪用：悪意のあるユーザーや不注意なユーザーは、この機能をどのように悪用できますか？レート制限、クォータ、冪等性は必要ですか？
8. 障害時の情報露出：エラーやタイムアウト時に何が漏えいしますか（スタックトレース、内部 ID、部分的な書き込みなど）？

Deep-pass trigger（決定論的）

タスクの計画時に、次のいずれかに関わるスライスには security: deep と指定します。

• 認証、認可、セッション、権限のロジック
• 信頼できない入力の解析またはデシリアライズ（リクエスト本文、ファイルアップロード、Webhook、クエリに使用されるクエリパラメーター）
• シークレット、トークン、認証情報、暗号処理
• PII や規制対象データ、またはそれに関してログに記録される情報
• 新しいサードパーティ依存関係や外部サービスとの統合
• CORS、CSP、セキュリティヘッダー、Cookie、リダイレクト
• SQL/NoSQL クエリの構築、シェルコマンドの構築、または変数からのテンプレート描画
• データベースのマイグレーションやデータのバックフィル
• ユーザー入力から派生するファイルシステムのパス

それ以外は security: standard と指定します。

検証時には、すべての deep スライスを対象に full-review と security_focus=true を使ってレビューし、記録済みのセキュリティ上の判断を渡します。この重点レビューを、承認済みのレビュープランに含めてください。タスク完了時、または同じ最終コードとリスクを対象にする場合は機能レビュー時に実施できます。根拠に変更がない限り、重複して実施しないでください。standard スライスには、追加のレビュー担当者を含めず、通常の対象範囲に限定したレビューを適用します。実装によってスライスの範囲が広がった場合は、トリガーを再確認してください。フラグをより厳しくすることはできますが、緩和してはなりません。

ステージの境界については、shared/references/workflow-stage-routing.md を読んでください。ヒアリングで判断を収集し、PRD でその判断を保持し、タスク計画でスライスを分類し、実装で結果を検証します。

出力契約

仕様策定時には、既存の決定記録に、安定した決定 ID、根拠となる権限情報、参照箇所、内容の改訂履歴を添えて、回答済みの決定事項を記載します。これらの参照情報を PRD の security_decisions として返します。計画策定時には、各スライスについて、一致したトリガーとともに security: deep|standard を返します。検証時には、full-review に渡す優先順位付けの指示を返します。

注意点

1. チェックリストの 8 つの質問を機械的にすべて尋ねないでください。その機能が関係する質問だけを尋ねます。
2. 自律フェーズ中に deep フラグを下げないでください。計画策定後にフラグを引き上げることのみ可能です。
3. ここでレビュー内容を重複して記載しないでください。指摘事項、エクスプロイト、修正は full-review に記載します。