security-review

セキュリティレビュー

概要

コードを体系的にレビューしてセキュリティ上の脆弱性を見つけ、安全なコーディングパターンを適用し、アプリケーションが多層防御の原則に従っていることを確認します。このスキルでは、OWASP Top 10、認証パターンの選択、入力検証、シークレット管理、依存関係の監査、セキュリティヘッダー、脅威モデリングを扱います。

開始時に告知： 「セキュリティ体制を評価するため、security-review スキルを使用します。」

---

フェーズ 1：スコープと脅威の評価

目標： 攻撃対象領域を特定し、レビュー領域の優先順位を決定します。

アクション

1. ユーザー向けのすべてのエンドポイントと入力面を特定します
2. 認証と認可の境界をマッピングします
3. 外部依存関係とその信頼レベルを一覧にします
4. 機密データのフロー（PII、認証情報、決済）を特定します
5. コンプライアンス要件（SOC 2、GDPR、HIPAA）を確認します

停止 — 次の条件を満たすまでフェーズ 2 に進まないでください：

• 攻撃対象領域がマッピングされている
• 機密データのフローが特定されている
• コンプライアンス要件が把握されている

---

フェーズ 2：OWASP Top 10 の監査

目標： 各 OWASP カテゴリーに照らして体系的に確認します。

OWASP Top 10 チェックリスト（2021）

#	カテゴリー	主な確認事項	合格／不合格
1	アクセス制御の不備	すべてのエンドポイントで認可を確認し、デフォルトでは拒否する
2	暗号化の失敗	平文のシークレットがなく、強力なアルゴリズム（AES-256、bcrypt）を使用している
3	インジェクション	パラメーター化クエリを使用し、SQL／コマンドに文字列連結を使用していない
4	安全でない設計	脅威モデルがあり、レート制限を設け、不正利用のケースを考慮している
5	セキュリティ設定の不備	本番環境でデフォルト設定を使用せず、権限を最小限にし、エラーメッセージから情報が漏れない
6	脆弱なコンポーネント	依存関係を監査し、既知の CVE がなく、更新ポリシーが定められている
7	認証の失敗	MFA を利用でき、パスワードをハッシュ化し、セッション管理が安全である
8	データ整合性の失敗	署名を検証し、CI/CD パイプラインの整合性を検証する
9	ログ記録の失敗	認証イベント、アクセス制御の失敗、入力検証の失敗を記録する
10	SSRF	URL を検証／許可リスト化し、ユーザー入力から内部ネットワークへアクセスさせない

停止 — 次の条件を満たすまでフェーズ 3 に進まないでください：

• 10 個すべてのカテゴリーを確認している
• 発見事項を重大度とともに記録している

---

フェーズ 3：カテゴリー別の詳細レビュー

目標： 特定した問題に、詳細なセキュリティパターンを適用します。

認証パターン選択表

パターン	使用する場面	主な要件
JWT	ステートレス API、マイクロサービス、モバイルのバックエンド	複数サービスでは RS256 を使用する。アクセストークンは最大 15 分。HttpOnly Cookie を使用する
セッションベース	従来型のウェブアプリ、サーバーレンダリングされたページ	サーバーサイドに保存する。HttpOnly + Secure + SameSite Cookie と CSRF トークンを使用する
OAuth2/OIDC	サードパーティーログイン、SSO、委任認証	Authorization Code + PKCE を使用する。ID トークンのクレームを検証する。トークンはサーバーサイドに保存する
パスキー／WebAuthn	パスワードレス、高セキュリティのアプリ	フィッシング耐性を備える。公開鍵のみを保存する。アカウントごとに複数の認証情報をサポートする

JWT セキュリティチェックリスト

項目	ガイダンス
署名	複数サービスでは RS256（非対称鍵）、単一サービスでは HS256 を使用する
有効期限	アクセストークン：最大 15 分。リフレッシュトークン：最大 7 日
保存	HttpOnly Cookie（ウェブ）またはセキュアストレージ（モバイル）を使用する。localStorage は決して使用しない
リフレッシュ	リフレッシュトークンの使用時にローテーションし、ログアウト時に無効化する
ペイロード	最小限のクレーム（sub、exp、iat、roles）にする。機密データを含めない

入力検証パターン

許可リストによる検証（常に拒否リストより優先します）：

# Good: allow-list
ALLOWED_SORT_FIELDS = {'name', 'created_at', 'price'}
if sort_field not in ALLOWED_SORT_FIELDS:
    raise ValidationError("Invalid sort field")

# Bad: block-list (always incomplete)
BLOCKED_CHARS = ['<', '>', '"']

パラメーター化クエリ（ユーザー入力を決して連結しないでください）：

# Good: parameterized
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# Bad: SQL injection vulnerability
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

ファイルアップロードの検証

• MIME タイプをサーバーサイドで検証します（拡張子だけで判断しません）
• ファイルサイズの上限を設定します
• ランダムなファイル名を生成します（ユーザーが指定した名前は決して使いません）
• アップロードファイルをウェブルートの外部に保存します
• 信頼できないユーザーから受け付ける場合は、マルウェアをスキャンします

停止 — 以下を満たすまでフェーズ 4 に進まないでください：

• 特定されたすべての問題に対する修正案がある
• 認証パターンが正しく適用されている
• 入力検証が包括的である

---

フェーズ 4：インフラストラクチャと依存関係の強化

目標： デプロイ環境とサプライチェーンを保護します。

シークレット管理ルール

環境	方法
開発	.env files (git-ignored)
CI/CD	Pipeline secrets (GitHub Secrets, GitLab CI vars)
本番	Secrets manager (AWS Secrets Manager, Vault, GCP Secret Manager)

シークレットに関する禁止事項

• ソースコードにシークレットをハードコードしないでください
• .env files を git にコミットしないでください
• シークレットをログに記録しないでください（デバッグレベルでも同様です）
• シークレットをコマンドライン引数として渡さないでください
• 環境ごとに異なるシークレットを使用してください

依存関係の監査コマンド

# Node.js
npm audit
npx socket-security audit

# Python
pip-audit
safety check

# Go
govulncheck ./...

# Rust
cargo audit

セキュリティヘッダー

ヘッダー	値	目的
Content-Security-Policy	default-src 'self'（アプリごとにカスタマイズ）	XSS とデータインジェクションを防止します
Strict-Transport-Security	max-age=63072000; includeSubDomains	HTTPS を強制します
X-Content-Type-Options	nosniff	MIME スニッフィングを防止します
X-Frame-Options	DENY または SAMEORIGIN	クリックジャッキングを防止します
Referrer-Policy	strict-origin-when-cross-origin	リファラー情報の漏えいを制御します
Permissions-Policy	使用しない API を無効化	ブラウザー機能へのアクセスを制限します

CORS ルール

• 認証情報を使用する場合は、Access-Control-Allow-Origin: * を使用しないでください
• 特定のオリジンのみを許可リストに登録してください
• 必要なメソッドとヘッダーのみを許可してください

---

フェーズ 5：脅威モデリング（STRIDE）

目標： 新機能や大幅な変更を行う際は、各脅威カテゴリを検討します。

脅威	確認事項	緩和策
なりすまし	攻撃者が他人になりすますことはできますか？	強力な認証、多要素認証
改ざん	検知されずにデータを変更できますか？	整合性チェック、署名
否認	ユーザーが操作の実行を否認できますか？	監査ログ
情報漏えい	エラー、ログ、またはサイドチャネルを通じて機密データが漏えいする可能性はありますか？	エラーのサニタイズ、暗号化
サービス拒否	システムを過負荷状態にできますか？	レート制限、リソースクォータ
権限昇格	ユーザーが本来持つべきでない権限を取得できますか？	最小権限、RBAC

特定した脅威ごとに：

1. 脅威と攻撃経路を記録する
2. 発生可能性と影響を評価する
3. 緩和策を定義する
4. 緩和策が実装され、テスト済みであることを確認する

---

判断表：セキュリティレビューの深度

変更の種類	レビューの深度	注力領域
認証／セッションの変更	STRIDE と OWASP に基づく完全なレビュー	すべてのカテゴリ
ユーザー入力の処理	インジェクションと検証に重点	OWASP 1、3、10
依存関係の更新	CVE スキャンと変更履歴のレビュー	OWASP 6
API エンドポイントの追加	アクセス制御と入力検証	OWASP 1、3、5
設定／インフラストラクチャ	シークレット、ヘッダー、設定ミス	OWASP 2、5
ファイルアップロード機能	インジェクション、SSRF、マルウェア	OWASP 3、10

---

アンチパターン／よくある間違い

アンチパターン	問題点	正しいアプローチ
クライアント側のみでの検証	簡単に回避されます	必ずサーバー側で検証してください
トークンを localStorage に保存する	XSS によって窃取される可能性があります	HttpOnly クッキーを使用してください
ブロックリスト方式の入力検証	常に不完全です	許可リスト方式の検証を使用してください
本番環境で汎用的なエラーメッセージを使用する	内部の詳細が漏れる可能性があります	エラーをサニタイズし、詳細はサーバー側でログに記録してください
環境間で同じシークレットを使用する	1 つが侵害されると、すべてが危険にさらされます	環境ごとに固有のシークレットを使用してください
依存関係の CVE を無視する	既知の脆弱性は積極的に悪用されています	定期的に監査して更新してください
認証情報を含む CORS のワイルドカード指定	CORS による保護が完全に無効になります	特定のオリジンを許可リストに登録してください
機密データをログに記録する	ログの漏えいはデータ侵害につながります	シークレット、PII、トークンは決してログに記録しないでください

---

シークレットのローテーションスケジュール

シークレットの種類	ローテーション頻度	侵害が疑われる場合
API キー	90 日ごと	直ちに
データベースのパスワード	90 日ごと	直ちに
暗号化キー	年次（キーのバージョン管理に対応すること）	直ちに
JWT 署名キー	6 か月ごと	直ちに
OAuth クライアントシークレット	90 日ごと	直ちに

---

サブエージェントへの委任機会

タスクのパターン	委任先	タイミング
複数の OWASP カテゴリを並行してスキャンする	Agent ツールの subagent_type="Explore"（カテゴリごとに 1 つ）	複数の脆弱性の種類にわたって大規模なコードベースをレビューする場合
認証フローの分析	Agent ツールの subagent_type="general-purpose"	認証の実装が複数のファイル／サービスにまたがる場合
依存関係の脆弱性スキャン	Bash ツールの run_in_background=true	npm audit などのツールを並行して実行する場合

委任時は dispatching-parallel-agents スキルのプロトコルに従ってください。

---

統合ポイント

スキル	関連性
code-review	セキュリティに関する指摘は Critical カテゴリの問題です
senior-backend	バックエンドの堅牢化には、セキュリティレビューでの指摘を反映します
senior-fullstack	認証の実装には、セキュリティパターンを適用します
acceptance-testing	セキュリティ要件は受け入れ基準になります
performance-optimization	レート制限はセキュリティとパフォーマンスの両方に役立ちます
systematic-debugging	セキュリティインシデントが発生したら、デバッグのワークフローを開始します

---

スキルの種類

柔軟 — 判断表を使用し、変更の種類に応じてレビューの深さを調整してください。認証または入力処理に関する変更では、OWASP チェックリストと STRIDE 分析を強く推奨します。シークレット管理のルールは必ず守ってください。