prd-securability-enhancement

PRD のセキュラビリティ強化（FIASSE/SSEM + ASVS）

各機能に、OWASP ASVS に準拠し、FIASSE v1.0.4 / SSEM に基づく、明示的でテスト可能なセキュラビリティ要件を盛り込み、PRD の内容を強化します。目的は、実装前に要件をまとめた成果物を改善し、後からコントロールを追加するのではなく、提供チームが設計段階からセキュラブルな機能を構築できるようにすることです。

このスキルは要件を中心に扱います。コードのレビューや作成は行いません。ユーザーがコードレビューを希望する場合は、securability-engineering-review に案内してください。コード生成を希望する場合は、securability-engineering に案内してください。

呼び出すタイミング

ユーザーが次のことを求めた場合に、このスキルを呼び出します。

• PRD、仕様書、ユーザーストーリー一式、または製品概要にセキュリティ要件を追加して強化する
• 製品または機能に適した ASVS 保証レベル（レベル 1、2、または 3）を選ぶ
• 機能を ASVS コントロールに対応付ける、または要件文書の ASVS カバレッジを確認する
• 開発開始前に不足しているセキュリティ要件を見つける
• 機能に SSEM 属性または FIASSE のテネットを付与する
• 既存の機能要件にテスト可能なセキュリティ受け入れ基準を追加する

関連する表現：「この仕様をセキュリティレビューして」「この機能一覧でセキュリティ面で不足している点は？」「PRD にセキュリティの NFR を追加して」「これらの要件をセキュラブルにして」

入力

開始前に、不足している情報をユーザーに確認してください。

• PRD、仕様書、または機能一覧（Markdown、文章、チケットのエクスポートなど）
• システムのコンテキスト：ユーザーの種類、デプロイモデル、データの機密性、統合ポイント
• コンプライアンスやリスクに関するコンテキスト（HIPAA、PCI、SOC 2、規制対象業界など）
• ASVS レベルの希望があるか、またはこのスキルに推奨を求めるか

成果物が大規模な場合は、機能をインラインで解析してください。ユーザーに事前の抽出を求めないでください。

手順

Step 1 — 機能を解析する

各機能を正規化されたレコードに抽出します。それぞれについて、次の項目を記録します。

• 機能 ID とタイトル（ない場合は F-01 のような ID を割り当てる）
• アクター（ユーザーの役割、システム、外部サービス）
• 扱うデータと機密性クラス
• 越える信頼境界（ブラウザー↔サーバー、サービス↔サービス、サーバー↔ストレージ、内部↔外部）
• 既存の受け入れ基準（不十分な内容であっても、原文のまま）

元の PRD で複数の機能が 1 つの箇条書きにまとめられている場合は、各機能を個別にテストできるよう分割してください。

Step 2 — まず ASVS レベルを選ぶ

要件を対応付ける前にレベルを選ぶことで、スコープ不足と過剰なスコープ設定の両方を防げます。次の基準を使用してください。

レベル	使用する場合
1	内部ツール、プロトタイプ、機密性の低いデータ、規制上の圧力がない場合、侵害された際の影響範囲が限定的な場合
2	認証済みユーザー、業務上重要な動作、顧客データ、または中程度の規制上のリスクがある一般的な本番 Web/API システム（ほとんどの製品はこのレベルに該当します）
3	高い保証が求められる状況：決済、医療記録、政府機関、ID プロバイダー、侵害によって重大な損害が生じるもの、または攻撃者が十分なリソースを持つ場合

より低い、または高いレベルを示す根拠がない限り、レベル 2 をデフォルトとしてください。次の項目を記録します。

• 選択したレベル
• より低いレベルでは不十分な理由（レベルが 1 より高い場合）
• ベースラインより高いレベルに引き上げるべき特定の機能（例：レベル 2 の製品内にある決済エンドポイントには、レベル 3 の対応を適用する）

ステップ 3 — 各機能を ASVS に対応付ける

各機能について、data/asvs/README.md（章のインデックス）と data/asvs/V*.md の when_to_use フロントマターを使用して、該当する章を特定します。よくある対応付けは次のとおりです。

• 認証フロー → V2（認証）、V3（セッション管理）
• 認可、所有権、マルチテナントのスコープ設定 → V4（アクセス制御）
• ファイルのアップロード／ダウンロード → V5（ファイル処理）
• 暗号化、パスワード保存、トークン → V6（暗号技術）
• ログ記録、エラー処理、可観測性 → V7（エラー／ログ記録）
• PII、保存中／転送中のデータ → V8（データ保護）、V14（セキュアな通信）
• 公開 API → V9（API／Web サービス）
• 設定、シークレット、デプロイ → V10（設定）
• ワークフロールール、自動化対策 → V11（ビジネスロジック）
• ユーザーまたは外部からの入力全般 → V12（入力検証）
• クライアントにレンダリングまたは返されるもの全般 → V13（出力エンコーディング）
• 機密データのライフサイクル → V16（機密データ）

選択した ASVS レベルに基づいて要件を絞り込みます。各要件のカバレッジを次のように分類します。

• Covered — PRD がすでに意図を満たしています
• Partial — 一部を満たしています。受け入れ基準の明確化または強化が必要です
• Missing — 要件がなく、追加が必要です
• N/A — 1 行の根拠を添えて該当なしとします

以下の ASVS カバレッジギャップパターン表を使用して、PRD で見落とされがちなギャップを特定します。

ステップ 4 — 機能ごとに Securability Notes を追加する

各機能について、実装に実質的な影響を与える SSEM と FIASSE の項目だけを取り上げた、短い段落を作成します。SSEM の 10 属性や FIASSE の 10 原則をすべて列挙しないでください。ノイズになります。

参考となる観点（該当する場合のみ記載）：

• 信頼境界の処理と入力の正規化（FIASSE v1.0.4 S4.3、S4.4.1）
• 導出される完全性 — サーバーが所有する状態について、クライアントから提供された値を決して信頼しない（FIASSE v1.0.4 S4.4.1.2）
• リクエストサーフェスの最小化 — 想定した名前付きの値のみを処理する（FIASSE v1.0.4 S4.4.1.1）
• 可観測性：ログ記録または監査が必要な内容（FIASSE v1.0.4 S3.2.1.4 ＋説明責任、透明性 S2.5）
• 最小驚愕 — 信頼境界やエラーパスで予測可能な動作を実現する（FIASSE v1.0.4 S2.6）
• レジリエンスまたは可用性の要因（レート制限、タイムアウト、適切かつセキュアなフェイル処理）
• テスト容易性または変更容易性に関する必須事項（例：暗号処理／認証処理を専用モジュールに集約する）
• 依存関係の管理 — サードパーティコードとの継続的な関係（FIASSE v1.0.4 S4.6）

ステップ 5 — テスト可能な受け入れ基準に変換する

追加または強化する要件ごとに、次の条件を満たす受け入れ基準を少なくとも 1 つ記述します。

• 動作として観測できる（テストまたは監査で合否を確認できる）
• 境界条件（失敗モード、未認可のアクター、不正な入力）が具体的である
• 検証可能な成果物（ログ行、レスポンスコード、拒否されたアクション）に結び付いている

曖昧な「セキュア」や「堅牢」といった表現は認められません。

ステップ 6 — 強化した PRD 成果物を出力する

以下の正確なテンプレートを使用して、指定順にセクションを作成します。

ASVS カバレッジギャップパターン表

PRD で見落とされがちなギャップは次のとおりです。左側にあるトリガー表現を見つけたら、右側に示す要件を追加してください。元の成果物では、ほとんどの場合これらが欠けています。

PRD のトリガーとなる表現（機能が何をうたっているか）	ほぼ必ず欠落している要件	ASVS セクション	タグ
「ユーザーがメールアドレスとパスワードでログインする」	アカウント列挙への対策（有効なメールアドレスと無効なメールアドレスで応答とタイミングを同じにする）；漏洩済みパスワードリストを使ったパスワードチェック；認証イベントの監査ログ；アカウント単位のブルートフォース攻撃対策のレート制限	V6.3.8, V2.1, V2.4, V16.3	"認証機能の抜け漏れ"
「ユーザーがパスワードをリセットする／忘れた場合」	リクエストエンドポイントでのアカウント列挙対策；使い捨てトークン；短い有効期限（≤15 min）；トークンのハッシュを保存；メールアドレスと IP ごとのレート制限；トークンの発行・使用に関する監査ログ	V6.3.8, V6.2, V2.4, V16.3	"リセットフローの抜け漏れ"
「ユーザーがファイルをアップロードする」	許可リスト（拒否リストではなく）；申告されたタイプに対するコンテンツスニッフィング；最大サイズ；ウイルス対策／安全なストレージパス；ファイル名の正規化；Web ルート外への保存；推測できない URL	V5.1, V5.2, V12.1	"アップロード機能の抜け漏れ"
「ユーザーがプロフィールを編集できる」／「設定を更新する」	変更可能なフィールドの許可リスト（リクエスト本文からの email／role／is_admin の設定を禁止）；リソースの所有者チェック；変更の監査ログ；変更前と変更後の値の記録	V4.1, V4.2, V16.2, V16.3	"一括割り当ての抜け漏れ"
「管理者が X を実行できる」／「ロールベースのアクセス制御」	許可／拒否を含む認可判定のログ記録；一元化された認可モジュール（チェックを各所に分散させない）；境界でのデフォルト拒否；すべてのレコード取得時に所有者の範囲を適用	V4.1, V4.2, V16.2, V16.3	"認可の抜け漏れ"
「パブリック API エンドポイント」／「サードパーティ連携」	キー／クライアントごとのレート制限；すべての呼び出しでの認証（初回呼び出しだけではない）；リクエスト ID の伝播；レスポンスフィールドの許可リスト（内部フィールドを漏らさない）；コントラクト検証	V2.4, V9.1, V13.1, V16.2	"API の抜け漏れ"
「ユーザーにメール／SMS を送信する」	ユーザーが制御できる件名／本文のインジェクションを防ぐテンプレート化されたペイロード；受信者と送信者ごとのレート制限；バウンス／不正利用ループへの対処；オプトアウトと監査ログ	V2.4, V12.1, V13.1, V16.3	"送信メッセージの抜け漏れ"
「ユーザー指定のパラメーターによる検索／絞り込み／一覧表示」	パラメーターの許可リスト；並べ替え／ページネーションの上限；クエリーのタイムアウト；結果数の上限；テナント／所有者の範囲をサーバー側で適用	V4.1, V12.1, V13.1	"クエリー機能の抜け漏れ"
「Webhook 受信エンドポイント」／「コールバック URL」	送信元の検証（署名、mTLS、IP 許可リスト）；リプレイ攻撃対策（タイムスタンプ＋ノンス）；冪等性キー；レート制限；受信イベントの監査ログ	V2.4, V2.5, V9.1, V16.3	"Webhook の抜け漏れ"
「ユーザーのファイル／ドキュメント／メモを保存する」	所有者 ID をクライアントから受け取らない；サイズとコンテンツの上限；読み取り時または書き込み時のリッチテキスト／HTML のサニタイズ；書き込みの監査ログ	V4.1, V5.1, V12.1, V16.3	"サーバー所有状態の抜け漏れ（導出された整合性）"
「データをエクスポートする」／「レポートをダウンロードする」	エクスポート時に認可を再確認（UI ルートでの確認だけでは不十分）；レート制限；行数を含む監査ログ；該当する場合は PII を除去するポリシー	V4.1, V7.1.1, V8.1	"エクスポートの抜け漏れ"
「バックグラウンドジョブがユーザー投稿データを処理する」	同期パスと同じ境界の規律（検証、対象範囲の最小化、所有者の範囲指定）；ジョブレベルの監査ログ；不正なメッセージへの対処と DLQ	V11.1, V12.1, V7.1.1	"非同期パスの境界に関する抜け漏れ"
「構成／フィーチャーフラグ／管理者設定」	変更には認証済みの実行者と監査記録が必要；管理者ロールなしでプロダクト API から設定できない；シークレット値を決して返さない；安全なデフォルト値	V7.1.1, V10.1, V14.2	"構成機能の抜け漏れ"
「PII／PHI／金融データ」への言及	フィールドレベルの分類；保存時および転送時の暗号化；保持／廃棄ポリシー；アクセスログの要件；エクスポート／消去（忘れられる権利）のフロー	V8.1, V14.1	"機微データのライフサイクルに関する抜け漏れ"
「リアルタイム」／「websocket」／「ストリーミング」機能	接続ごとの認証（初回メッセージだけではない）；接続ごとのリソース上限；バックプレッシャー／キューの最大サイズ；アイドルタイムアウト；接続ライフサイクルの監査	V3.1, V9.1, V11.1.4	"ストリーミングの抜け漏れ"
「AI／LLM を活用した機能」	信頼境界でのプロンプトインジェクションへの対処；後続の副作用を起こす前の出力検証；実行者ごとのレート制限とコスト上限；プロンプトとツール呼び出しの監査ログ；PII の編集ポリシー	V11.1, V12.1, V8.1	"LLM 境界の抜け漏れ"
機能がこれらのパターンのいずれかに該当する場合、PRDで明示的に扱われていない限り、対応する要件をカバレッジマトリックスで Missing として事前入力してください。ほとんどの場合、明示的には扱われていません。

出力テンプレート

A. ASVS レベルの決定

## ASVS Level Decision

**Chosen Level**: [1 | 2 | 3]

**Rationale**: [2–4 sentences. Cover data sensitivity, user population, regulatory context, and material-impact reasoning. Note why lower levels are insufficient if Level > 1.]

**Feature-Level Escalations**: [List any features that need a higher level than baseline, with one-line justification, or "None".]

B. カバレッジマトリックス

## Feature ↔ ASVS Coverage Matrix

| Feature | ASVS Section | Requirement ID | Level | Coverage | PRD Change Needed |
|---------|--------------|----------------|-------|----------|-------------------|
| F-01    | V2.2         | 2.2.1          | 2     | Missing  | Add MFA requirement for high-risk actions |
| F-01    | V7.1         | 7.1.1          | 2     | Partial  | Specify which auth events are logged |
| F-02    | V12.1        | 12.1.1         | 2     | Covered  | — |

ここでは簡潔さより網羅性を重視してください。機能と該当する要件の組み合わせごとに、すべて行を設けます。ギャップパターンの表が該当する場合は、表で示される要件を含めてください。

C. 機能仕様の強化

各機能について、必ず次の形式で出力してください。

### Feature F-01: [Title]

**Actor**: [user role / system]
**Data**: [data classes touched]
**Trust Boundaries**: [boundaries crossed]

**ASVS Mapping**: V2.2.1, V7.1.1, ...

**Updated Requirements**:
- [Original requirement, kept or rewritten]
- [Newly added requirement from ASVS mapping]
- [Newly added requirement from ASVS mapping]

**Acceptance Criteria**:
- [Testable criterion tied to a requirement above]
- [Testable criterion tied to a requirement above]

**Securability Notes**: [Short paragraph — only material SSEM/FIASSE points for this feature. Do not enumerate all attributes.]

D. 横断的なセキュリティ要件

複数の機能にまたがる対策（ログの一元管理、シークレット管理、依存関係のポリシー、TLS のベースライン、エラー処理の標準など）。ASVS の参照を添えて、それぞれ 1 項目ずつ記載してください。

E. 未解決のギャップと前提

入力から解決できなかった事項をすべて記載してください。システムコンテキストの不足、データ機密性の不明確さ、ユーザー層の未提示、先送りされた決定事項などです。実装前にチームが解決できるよう、具体的に記載してください。

作成例（簡易版）

入力機能（PRD より）：

F-03: ユーザーは「パスワードを忘れた場合」をクリックしてメールアドレスを入力すると、パスワードをリセットできます。システムからリセットリンクをメールで送信します。

これはギャップ表の「リセットフローのギャップ」パターンに該当します。そのため、不足している要件は予測できます。

強化後の出力：

### Feature F-03: Password Reset via Email

**Actor**: Unauthenticated user (claiming an account)
**Data**: Email address (PII), password (credential), reset token
**Trust Boundaries**: browser → public API; API → email provider; API → credential store

**ASVS Mapping**: V2.2.2, V6.2.1, V6.2.2, V7.1.1, V11.1.4, V12.1.1

**Updated Requirements**:
- User can request a password reset by entering an account email at `/reset`.
- The system always returns the same success response whether or not the email matches an account (prevents account enumeration, V2.2.2).
- Reset tokens are single-use, expire within 15 minutes, and are stored only as a salted hash (V6.2).
- New passwords are validated against a minimum policy and screened against a known-breached-password list (V6.2.1).
- All reset requests, token issuances, token redemptions, and password changes are logged with user ID, source IP, user agent, and outcome (V7.1.1).
- Reset requests are rate-limited per email and per source IP (V11.1.4).
- The email input is canonicalized and validated against a strict format (V12.1.1).

**Acceptance Criteria**:
- Submitting a non-existent email returns the same response body, status code, and timing characteristics as a valid email (within tolerance).
- A reset token cannot be redeemed after 15 minutes or after first successful use; both cases produce a generic failure response and a logged `reset_token_invalid` event.
- More than 5 reset requests for the same email within 10 minutes are rejected with HTTP 429 and logged.
- Audit log lines for reset events are queryable by user ID and contain the fields above.

**Securability Notes**: This feature crosses an unauthenticated trust boundary (FIASSE v1.0.4 S4.3), so input handling and rate limiting are the load-bearing concerns. The reset token is server-owned state; never accept client-supplied token attributes beyond the opaque token itself (Derived Integrity, FIASSE v1.0.4 S4.4.1.2). Centralize token generation, hashing, and verification in a single module so the policy can evolve without touching call sites (Modifiability). All reset events must be observable in the audit pipeline so abuse patterns can be detected (Accountability + Observability, FIASSE v1.0.4 S3.2.1.4; Transparency S2.5).

出力は、この程度に具体的で、テスト可能であり、ASVS まで追跡できるようにしてください。

品質チェックリスト（出力前に実施）

カバレッジ

• すべての機能に ID、アクター、データ分類、信頼境界のリストがある
• 機能ごとのマッピングの前に ASVS レベルを選択し、その理由を示している
• 選択したレベルで、すべての機能を該当する ASVS の全章にマッピングしている
• 上記の表にあるギャップパターンを、該当するすべての機能に適用している
• Missing／Partial の各項目について、具体的な PRD 変更案を提示している

出力の規律

• カバレッジマトリックスを含め、変更が必要かどうかの列を設けている
• 各機能が指定の形式（Actor / Data / Trust Boundaries / ASVS Mapping / Updated Requirements / Acceptance Criteria / Securability Notes）に従っている
• 受け入れ条件が、願望的なものではなく、動作をテストできる内容になっている
• Securability Notes は要点を絞り、重要な SSEM／FIASSE の点だけを扱っている。網羅的な列挙はしない

追跡可能性

• 追加するすべての要件に ASVS の参照を記載している
• 横断的な要件のセクションに、共有される対策をまとめている
• 未解決のギャップと前提を明示している

判断に迷った場合

• カバレッジがあると仮定するより、不足要件を追加してください。レビュー担当者に分かるよう、明示的に記載してください。
• 誰も対応しないような長いリストより、機能ごとに少数の明確な ASVS 参照を選んでください。
• Securability Notes は平易な言葉で記載してください。読むのはセキュリティエンジニアだけでなく、プロダクトマネージャーも含まれます。

参考資料

• 手順ごとのランブック：plays/prd-fiasse-asvs-enhancement.md
• ASVS の章インデックス：data/asvs/README.md
• ASVS 要件（章ごと）：data/asvs/V*.md
• FIASSE v1.0.4 の基本原則：data/fiasse/S2.1.md–S2.6.md（透明性 S2.5、最小の驚き S2.6）
• FIASSE v1.0.4 の SSEM 属性群：data/fiasse/S3.2.1.md–S3.2.3.md。属性固有のガイダンスについてはリーフファイル（例：S3.2.1.4.md Observability）を参照してください
• FIASSE v1.0.4 の境界制御とレジリエントなコーディング：data/fiasse/S4.3.md、S4.4.md、および正規入力処理のリーフファイル S4.4.1.md、S4.4.1.1.md、S4.4.1.2.md
• FIASSE v1.0.4 の依存関係管理とスチュワードシップ：data/fiasse/S4.5.md、S4.6.md