security-audit

セキュリティ監査

OWASP Top 10 のカテゴリー、シークレットの漏えい、サプライチェーンのリスク、言語固有のパターンにわたって、コードベースのセキュリティ脆弱性を調査します。優先順位を付けた修正アクションを記載した、スコア付きの SECURITY_AUDIT.md を作成します。

基本原則： 単に grep するのではなく、調査してください。一致箇所の周辺のコードを読み、それが実際の脆弱性なのか、誤検知なのか、すでに緩和されているのかを判断します。具体的なファイル名と行番号の証拠があり、リスクが確認された問題のみを報告してください。

前提条件の確認

git --version 2>/dev/null && git rev-parse --is-inside-work-tree 2>/dev/null

利用可能なセキュリティツールを確認します（任意ですが、分析の精度が高まります）。

command -v gitleaks 2>/dev/null && echo "gitleaks: available"
command -v semgrep 2>/dev/null && echo "semgrep: available"
command -v trivy 2>/dev/null && echo "trivy: available"
command -v govulncheck 2>/dev/null && echo "govulncheck: available"

ツールがなくても続行してください。手動での調査も可能です。レポートには、利用できないツールを記載してください。

ステップ 1：範囲とコンテキスト

監査対象を特定し、アプリケーションを理解します。

1. 技術スタックを検出する — go.mod、package.json、pyproject.toml、Cargo.toml、*.csproj をスキャンして、使用言語を特定します
2. セキュリティ上重要な領域を特定する — 認証、認可、データベースアクセス、API エンドポイント、暗号処理、ファイル処理に関連するファイルを検索します
3. 範囲を決定する — ユーザーの入力に基づき、コードベース全体、特定のモジュール、または最近の変更のみを監査します
4. プロジェクトのドキュメントを読む — アーキテクチャのコンテキストと既知の境界を把握するため、CLAUDE.md、README.md、CONTEXT.md を確認します

ステップ 2：自動スキャン

手動調査の前に、利用可能なセキュリティツールを実行します。ツールの検出結果を参考に、手動レビューで注目する箇所を決めます。

# Secrets in current code and git history
gitleaks detect -v 2>&1

# Static analysis (language-aware rule sets)
semgrep --config=auto --severity=ERROR . 2>&1

# Dependency vulnerabilities
trivy fs --severity HIGH,CRITICAL . 2>&1
# or: govulncheck ./... / npm audit / pip-audit / cargo audit

ツールが問題を検出した場合は、それぞれを検証してください。自動スキャナーは誤検知を出すことがあります。レポートに含める前に、該当コードを前後の文脈とともに読んでください。

ステップ 3：OWASP Top 10 分析

プロジェクトに関連する OWASP カテゴリーを体系的に調査します。すべてのカテゴリーがすべてのプロジェクトに当てはまるわけではありません。CLI ツールに XSS の確認は不要ですし、ライブラリに CSRF 対策は必要ありません。

該当するカテゴリーごとに、次の手順を実施します。

1. この脆弱性が存在しうるコードパスを特定します
2. 実際の実装を読みます（キーワードを grep するだけではありません）
3. 緩和策が適用されているか確認します
4. 確認済み、または可能性が高い脆弱性のみを報告します

OWASP カテゴリーごとの詳細な調査パターンについては、references/owasp-patterns.md を参照してください。

ステップ 4：シークレットとサプライチェーン

シークレット： 現在のコードと Git の履歴の両方をスキャンし、ハードコードされた認証情報、API キー、トークン、接続文字列を探します。現在のコードから削除されていても、Git の履歴に残っているシークレットは依然として侵害されています。CRITICAL として報告してください。

サプライチェーン： ロックファイルの整合性、依存関係の脆弱性、依存関係の混同リスク、重要な依存関係のメンテナンス状況を確認します。

詳細なスキャンコマンドと分析パターンについては、references/secrets-and-supply-chain.md を参照してください。

ステップ 5：脅威モデリング

実際のコードベースに STRIDE を適用します。

1. エントリーポイントを把握する — アプリケーションにデータが入るすべての経路を特定します
2. 信頼境界を特定する — 信頼できないデータが信頼された領域に入る箇所を特定します
3. STRIDE カテゴリーを適用する — なりすまし、改ざん、否認、情報漏えい、サービス拒否、権限昇格
4. DREAD を使って脅威を評価する — 損害、再現性、悪用可能性、影響を受けるユーザー、発見可能性

詳細な脅威モデリング手順と DREAD による評価については、references/threat-model.md を参照してください。

ステップ 6：言語固有のレビュー

検出した言語に固有の脆弱性パターンを確認します。該当する言語のセクションのみを読み込みます。

Go、JavaScript/TypeScript、Python、Rust、.NET のパターンについては、references/language-security.md を参照してください。

ステップ 7：検出結果の評価と分類

各検出結果に、次の項目を割り当てます。

• 深刻度：CRITICAL / HIGH / MEDIUM / LOW
  • CRITICAL：現時点で悪用可能で、データ侵害または RCE のリスクがある
  • HIGH：中程度の労力で悪用可能で、影響が大きい
  • MEDIUM：特定の条件が必要で、影響は中程度
  • LOW：理論上のリスクで、影響は最小限
• 修正に必要な労力：S（1 日未満）/ M（1～5 日）/ L（1～2 週間）
• 証拠：具体的なファイル名と行番号、および説明

ステップ 8：SECURITY_AUDIT.md を生成する

references/report-template.md のテンプレートを使用してレポートを作成します。エグゼクティブサマリー、証拠を含む詳細な検出事項、脅威モデルの概要、優先順位付けした修正対応を含めてください。

生成したファイルに対して markdownlint を実行します。

ステップ 9：概要を提示する

ユーザーに以下を提示します。

1. 重大度別の検出件数
2. 証拠を含む、最も重大な項目トップ 3
3. 利用可能だったツールと不足していたツール
4. 修正対応の優先順位リスト
5. どの検出事項から対応するか尋ねる