security-review

セキュリティレビュー

使用するタイミング

• アプリケーション、インフラストラクチャ、または特定の機能のセキュリティ監査を希望している
• リリース前に脅威モデルの作成が必要、またはペネトレーションテストの準備レビューが必要
• 依存関係の脆弱性に関するアラートを受け取り、修正の指針が必要
• 機密データ（PII、決済情報、医療情報）を取り扱っており、検証が必要
• コード監査、シークレット検出、またはコンプライアンス評価を依頼している

必要なコンテキスト

startup-context から、技術スタック、デプロイ環境、コンプライアンス要件、データの種類を確認します。また、次の点も尋ねます。

• 対象範囲 — アプリ全体、機能、認証システム、単一の PR、インフラストラクチャ、またはクラウド環境
• データの種類 — 取り扱う PII、決済情報、医療情報、認証情報、またはその他の機密データ
• コンプライアンス要件 — SOC 2、HIPAA、PCI-DSS、GDPR、ISO 27001
• 承認 — アクティブテストを行う前に、書面による承認があることを確認します

ワークフロー

5 段階の手法に従います。自動スキャンを手動レビューより先に行います。アクティブテストの前には、必ず承認を確認します。

1. 対象範囲の定義 — 攻撃対象領域の境界を定めます。すべてのコンポーネント、データフロー、信頼境界を特定します。承認を確認し、対象範囲内と対象範囲外を定義します。
2. 自動スキャン — 手動レビューの前にツールを実行します。
   • SAST： コードベース全体に対して semgrep --config=auto を実行
   • 依存関係の監査： npm audit / pip-audit / govulncheck / trivy fs .
   • シークレット検出： ソースコード内のハードコードされた認証情報、API キー、トークンをスキャン
   • コンテナスキャン： コンテナ化されたデプロイに対して trivy image を実行
   • 次のフェーズで検証するため、自動スキャンの検出結果をすべて記録します。
3. 手動コードレビュー — 自動ツールでは見つからないコンテキストに応じた分析を行います。
   • 認証および認可のフローをエンドツーエンドで追跡
   • ビジネスロジックの脆弱性（価格の改ざん、競合状態、権限昇格）
   • 機密情報のデータフロー分析（PII はどこから入り、どこを通り、どこに保存されるか）
   • 各コンポーネントとデータフローに対する STRIDE 脅威モデリング
4. 検証と分類 — 検出結果をテストし、重大度を割り当てます。
   • 自動スキャンの検出結果を検証し、誤検知を除外
   • CVSS v3.1 のスコアを割り当て、状況に応じた悪用可能性を評価
   • 技術的な重大度だけでなく、ビジネスへの影響に基づいて分類
5. 報告 — 脆弱性の正確な箇所、ビジネスへの影響、是正措置を記録します。優先順位を付けた修正ロードマップを提示します。

出力形式

# Security Review: [Scope Description]

## Executive Summary
Overall risk posture (Critical / High / Medium / Low), top findings count, and business impact summary.

## Threat Model (STRIDE)
| Threat | Category | Asset | Impact | Likelihood | Risk |

## Findings
### Critical / High / Medium / Low
- **[SEC-N] Title** — CVSS X.X — file:line — description, business impact, remediation with code example

## Auth Flow Assessment
End-to-end trace of authentication and authorization with findings.

## Dependency Vulnerabilities
| Package | Current Version | CVSS | Fix Version | Exploitable in Context? |

## Remediation Roadmap
Prioritized action list with timelines.

フレームワークとベストプラクティス

STRIDE 脅威モデリング

すべてのコンポーネントとデータフローに適用します。

• なりすまし — 攻撃者がトークンを偽造したり、ユーザーになりすましたりできますか？API キーはローテーションできますか？
• 改ざん — 通信中にリクエストを変更できますか？Webhook に署名されていますか？データの完全性は検証されていますか？
• 否認 — 重要な操作は記録されていますか？ログは改ざんを検知できますか？
• 情報漏えい — エラーレスポンスにスタックトレースが含まれていませんか？PII は保存時と転送時に暗号化されていますか？
• サービス拒否 — レート制限は設定されていますか？1 人のユーザーが全ユーザー分のリソースを使い果たす可能性はありませんか？
• 権限昇格 — 一般ユーザーが管理者機能にアクセスできますか？ロールチェックはサーバー側で行われていますか？

OWASP Top 10 チェック

1. インジェクション — SQL/NoSQL のパラメーター化、OS コマンド、SSTI、LDAP を確認
2. 認証の不備 — argon2id/bcrypt、セッションタイムアウト、ログイン時のレート制限
3. データ漏えい — TLS 1.2 以上、保存時の PII 暗号化、HSTS ヘッダー
4. XXE — DTD 処理を無効化し、XML より JSON を優先
5. アクセス制御 — すべてのエンドポイントでサーバー側の認可を行い、IDOR を防止し、CORS の許可リストを設定
6. 設定ミス — デバッグモードをオフにし、デフォルトの認証情報を削除し、セキュリティヘッダーを設定
7. XSS — 出力エンコーディング、Content Security Policy、HTTP 専用 Cookie
8. デシリアライズ — スキーマを検証し、JSON を優先し、信頼できないシリアライズ済みオブジェクトを拒否
9. 脆弱な依存関係 — npm audit、pip-audit、trivy、govulncheck
10. ログ記録 — 認証イベント、管理者操作、アクセス違反を記録し、アラートを設定

CVSS v3.1 スコアリングガイド

• Critical（9.0-10.0）： RCE、認証バイパス、データの完全な漏えい、システムの完全な侵害
• High（7.0-8.9）： 権限昇格、重大なデータ露出、内部サービスへの SSRF
• Medium（4.0-6.9）： 格納型 XSS、CSRF、限定的な IDOR、情報漏えい
• Low（0.1-3.9）： セキュリティヘッダーの欠如、軽微な情報漏えい、詳細すぎるエラー

認証フローのチェックリスト

• パスワード：argon2id または bcrypt（コスト >= 10）
• JWT：有効期間 15 分のアクセストークン、有効期間 7 日のリフレッシュトークン（使用時にローテーション）
• レート制限：認証エンドポイントで 15 分あたり 5 回まで
• パスワード変更時にセッションを無効化
• OAuth の state パラメーターを検証し、API キーのスコープを設定
• 管理者アカウントで MFA を必須化
• パスワードリセットトークンは一度のみ使用可能とし、有効期間を制限

スキャンツール

• SAST： semgrep --config=auto（すべてのスタック）、bandit（Python）、gosec（Go）、eslint-plugin-security（Node）
• 依存関係： npm audit / pip-audit / govulncheck / trivy fs .
• コンテナ： trivy image

必須の制約

• 明示的な書面による許可なく、本番環境をテストしないでください
• 概念実証の実演を超えて悪用しないでください
• 手動レビューの前に、必ず自動スキャンを実施してください

修正の優先順位

1. 現在悪用可能な問題と重大なデータへの影響 — 直ちに対応
2. 認証／認可のバイパス — 24 時間以内
3. インジェクション — 48 時間以内
4. データ露出／重大な CVE — 1 週間以内
5. 設定の強化 — 2 週間以内
6. 多層防御 — 次のスプリント

関連スキル

• code-review — 発見事項にコードレベルの修正とレビューが必要な場合に連携
• architecture-design — 発見事項からアーキテクチャ上のセキュリティ上の欠陥が明らかになった場合に連携
• soc2-prep — レビューがコンプライアンス準備の一環である場合に連携

例

プロンプトの例：「ユーザー認証システムのセキュリティをレビューしてください。Express で JWT を使用しています。」

出力例：

# Security Review: JWT Authentication System

## Executive Summary
Risk posture: **Critical**. Hardcoded JWT secret and non-expiring tokens.

## Findings
### Critical (CVSS 9.8)
- **[SEC-1] Hardcoded JWT secret** — auth/config.js:3 — Secret is
  "supersecret123". Attacker can forge any token.
  **Fix:** Move to env var, generate with `openssl rand -base64 64`.

### Critical (CVSS 9.1)
- **[SEC-2] Tokens never expire** — auth/jwt.js:12 — No `expiresIn`.
  **Fix:** Set `expiresIn: '15m'`, implement refresh token rotation.