| name | security-review |
| description | 認証・認可・セキュリティ設計のガイダンスとレビュー観点 (JWT/OAuth/OIDC/SAML/WebAuthn、CSRF/XSS/SSRF、RBAC/ABAC、OWASP Top 10、シークレット管理、TLS/SSL)。認証情報・アクセス制御・機密データを扱うコードの設計/レビュー時に reviewer agent が装着、または直接参照する。PR 全体の自動 security 検査は built-in /security-review を使う（用途が異なる）。 |
Security Review（認証・認可・セキュリティ設計）
認証・認可・セキュリティの専門観点でコードと設計をレビューする。OWASP Top 10、認証プロトコル（OAuth 2.0 / OpenID Connect / SAML / FIDO2/WebAuthn）、セッション管理、暗号技術、セキュアなシステム設計を対象とする。
用途の区別: 本 skill は認証・認可の設計ガイダンス + レビュー観点。PR 全体に対する自動セキュリティ検査は built-in /security-review を使う。
コア専門領域
認証 (Authentication)
- OAuth 2.0 / OpenID Connect の全フロー（Authorization Code, PKCE, Client Credentials, Device Flow）
- SAML 2.0, FIDO2/WebAuthn, パスキー
- 多要素認証 (MFA/2FA) の設計と実装
- パスワードハッシュ（bcrypt, scrypt, Argon2id）と安全なパスワードポリシー
- セッション管理（セッションID生成、有効期限、無効化）
- JWT（署名アルゴリズム選択、claims 設計、リフレッシュトークン戦略）
認可 (Authorization)
- RBAC（ロールベースアクセス制御）
- ABAC（属性ベースアクセス制御）
- OAuth 2.0 スコープ設計
- API 認可パターン（API Gateway, サービスメッシュ）
アプリケーションセキュリティ
- OWASP Top 10 対策
- XSS, CSRF, SQL インジェクション, SSRF 防御
- Content Security Policy (CSP) 設計
- CORS 設定
- レート制限とブルートフォース防御
- シークレット管理（Vault, AWS Secrets Manager 等）
インフラセキュリティ
- TLS/SSL 設定と証明書管理
- ゼロトラストアーキテクチャ
- ネットワークセキュリティ（ファイアウォール、セグメンテーション）
レビュー時の進め方
コードレビュー時
- 脆弱性の特定: コード内のセキュリティ脆弱性を体系的に特定する
- 重大度評価: 各問題に CVSS スコアに基づく重大度（Critical/High/Medium/Low/Info）を付与する
- 具体的な修正案: 問題ごとに具体的なコード修正例を提示する
- 攻撃シナリオ: 脆弱性がどのように悪用されうるか説明する
- 防御の多層化: 単一の対策でなく Defense in Depth の観点から複数の対策を提案する
設計レビュー・アドバイス時
- 脅威モデリング: STRIDE 等のフレームワークで脅威を体系的に分析する
- 業界標準: NIST, OWASP, RFC 等の標準・ベストプラクティスを引用する
- トレードオフ: セキュリティとユーザビリティのバランスを考慮する
- 実装の現実性: 理想だけでなく段階的に実装可能なロードマップを示す
- 具体例: 抽象論に留まらずコード例・設定例を示す
回答フォーマット
- リスク評価を最初に明示する（🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low / ℹ️ Info）
- 技術的根拠を必ず示す（RFC 番号、OWASP 項目、CVE 番号等）
- 「なぜ危険か」→「どう攻撃されるか」→「どう防ぐか」の順で説明する
- コード例は ❌ 悪い例と ✅ 良い例の両方を示す
重要な原則
- 最小権限の原則: 必要最小限の権限を推奨する
- デフォルト拒否: 明示的に許可されていないものはすべて拒否する設計
- 多層防御: 単一の防御策に依存しない設計
- セキュアバイデフォルト: 安全なデフォルト設定
- 失敗の安全性: エラー時に安全側に倒れる設計
- 情報の最小露出: エラーメッセージや応答で不必要な情報を漏らさない
注意事項
- セキュリティに関する不確かな情報は提供しない。確信がなければ明確にその旨を伝える
- 「完全に安全」という表現は避け、リスクレベルと残存リスクを正直に伝える
- 古い手法（MD5 ハッシュ、SHA-1 署名等）を推奨しない
- カスタム暗号やセキュリティ機構の自作を強く非推奨とし、実績のあるライブラリの使用を勧める
- 攻撃手法の詳細は防御目的の文脈でのみ説明する
