脆弱性スキャナー
攻撃者のように考え、専門家のように防御しましょう。2025年の脅威情勢を把握します。
🔧 ランタイムスクリプト
任意のヒューリスティック スキャン（セキュリティ検証ではありません）：
| スクリプト | 目的 | 使用方法 |
|---|
scripts/security_scan.py | 適用されているセキュリティ原則を検証する | python scripts/security_scan.py <project_path> |
📋 参照ファイル
1. セキュリティ専門家の考え方
基本原則
| 原則 | 適用方法 |
|---|
| 侵害を前提とする | 攻撃者がすでに内部に侵入している前提で設計する |
| ゼロトラスト | 決して信頼せず、常に検証する |
| 多層防御 | 複数の防御層を設け、単一障害点をなくす |
| 最小権限 | 必要最小限のアクセスのみを許可する |
| 安全側に失敗させる | エラー発生時はアクセスを拒否する |
脅威モデリングの質問
スキャンの前に、次の点を確認してください。
- 何を保護するのか？（資産）
- 誰が攻撃する可能性があるのか？（脅威アクター）
- どのように攻撃するのか？（攻撃ベクトル）
- どのような影響があるのか？（ビジネスリスク）
2. OWASP Top 10:2025
リスクカテゴリ
| 順位 | カテゴリ | 考慮する点 |
|---|
| A01 | アクセス制御の不備 | 誰が何にアクセスできるか？ IDOR、SSRF |
| A02 | セキュリティ設定の不備 | デフォルト設定、ヘッダー、公開されたサービス |
| A03 | ソフトウェアサプライチェーン 🆕 | 依存関係、CI/CD、ビルドの完全性 |
| A04 | 暗号化の失敗 | 脆弱な暗号、漏えいした秘密情報 |
| A05 | インジェクション | ユーザー入力 → システムコマンド |
| A06 | 安全でない設計 | アーキテクチャの欠陥 |
| A07 | 認証の失敗 | セッション、認証情報の管理 |
| A08 | 完全性の失敗 | 署名のない更新、改ざんされたデータ |
| A09 | ロギングとアラート | 監視の死角、監視機能の欠如 |
| A10 | 例外的な状況 🆕 | エラー処理、フェイルオープン状態 |
2025年の主な変更点
2021 → 2025 Shifts:
├── SSRF merged into A01 (Access Control)
├── A02 elevated (Cloud/Container configs)
├── A03 NEW: Supply Chain (major focus)
├── A10 NEW: Exceptional Conditions
└── Focus shift: Root causes > Symptoms
3. サプライチェーンセキュリティ（A03）
攻撃対象領域
| ベクトル | リスク | 確認事項 |
|---|
| 依存関係 | 悪意のあるパッケージ | 新しい依存関係を監査していますか？ |
| ロックファイル | 完全性への攻撃 | コミットされていますか？ |
| ビルドパイプライン | CI/CD の侵害 | 誰が変更できますか？ |
| レジストリ | タイポスクワッティング | 検証済みのソースですか？ |
防御の原則
- パッケージの完全性を検証する（チェックサム）
- バージョンを固定し、更新を監査する
- 重要な依存関係にはプライベートレジストリを使用する
- 成果物に署名し、検証する
4. 攻撃対象領域のマッピング
マッピングする対象
| カテゴリ | 要素 |
|---|
| エントリーポイント | API、フォーム、ファイルアップロード |
| データフロー | 入力 → 処理 → 出力 |
| 信頼境界 | 認証／認可を確認する場所 |
| 資産 | 秘密情報、PII、ビジネスデータ |
優先順位付けマトリクス
Risk = Likelihood × Impact
High Impact + High Likelihood → CRITICAL
High Impact + Low Likelihood → HIGH
Low Impact + High Likelihood → MEDIUM
Low Impact + Low Likelihood → LOW
5. リスクの優先順位付け
CVSS + コンテキスト
| 要因 | 重み | 質問 |
|---|
| CVSS スコア | 基本的な深刻度 | 脆弱性はどの程度深刻ですか？ |
| EPSS スコア | 悪用される予測確率 | 今後30日以内に悪用される確率であり、実際に悪用されている証拠ではありません |
| 資産価値 | ビジネス上のコンテキスト | 何がリスクにさらされていますか？ |
| 露出度 | 攻撃対象領域 | インターネットに公開されていますか？ |
優先順位付けの決定木
Is there credible active-exploitation evidence (for example a relevant KEV entry or incident evidence)?
├── YES → CRITICAL: Immediate action
└── NO → Check CVSS
├── CVSS ≥9.0 → HIGH
├── CVSS 7.0-8.9 → Consider asset value
└── CVSS <7.0 → Schedule for later
6. 例外的な状況（A10 - 新規）
フェイルオープンとフェイルクローズ
| シナリオ | フェイルオープン（不適切） | フェイルクローズ（適切） |
|---|
| 認証エラー | アクセスを許可する | アクセスを拒否する |
| 解析の失敗 | 入力を受け入れる | 入力を拒否する |
| タイムアウト | 無期限に再試行する | 回数を制限して中止する |
確認事項
- すべての例外を捕捉して無視する例外ハンドラー
- セキュリティ操作におけるエラー処理の不足
- 認証／認可における競合状態
- リソース枯渇のシナリオ
7. スキャン方法
フェーズ別アプローチ
1. RECONNAISSANCE
└── Understand the target
├── Technology stack
├── Entry points
└── Data flows
2. DISCOVERY
└── Identify potential issues
├── Configuration review
├── Dependency analysis
└── Code pattern search
3. ANALYSIS
└── Validate and prioritize
├── False positive elimination
├── Risk scoring
└── Attack chain mapping
4. REPORTING
└── Actionable findings
├── Clear reproduction steps
├── Business impact
└── Remediation guidance
8. コードパターン分析
高リスクパターン
| パターン | リスク | 確認するもの |
|---|
| クエリ内の文字列連結 | インジェクション | "SELECT * FROM " + user_input |
| 動的コード実行 | RCE | eval()、exec()、Function() |
| 安全でないデシリアライズ | RCE | pickle.loads()、unserialize() |
| パスの操作 | トラバーサル | ファイルパス内のユーザー入力 |
| セキュリティの無効化 | さまざま | verify=False、--insecure |
シークレットのパターン
| 種類 | 指標 |
|---|
| API キー | api_key、apikey、高エントロピー |
| トークン | token、bearer、jwt |
| 認証情報 | password、secret、key |
| クラウド | AWS_、AZURE_、GCP_ のプレフィックス |
9. クラウドセキュリティに関する考慮事項
共有責任
| レイヤー | お客様の責任 | プロバイダーの責任 |
|---|
| データ | ✅ | ❌ |
| アプリケーション | ✅ | ❌ |
| OS／ランタイム | 状況による | 状況による |
| インフラストラクチャ | ❌ | ✅ |
クラウド固有の確認項目
- IAM：最小権限が適用されていますか？
- ストレージ：公開バケットはありませんか？
- ネットワーク：セキュリティグループは適切に制限されていますか？
- シークレット：シークレットマネージャーを使用していますか？
10. アンチパターン
| ❌ やってはいけないこと | ✅ やるべきこと |
|---|
| 理解せずにスキャンする | まず攻撃対象領域を把握する |
| すべての CVE でアラートを出す | 悪用可能性と資産に基づいて優先順位を付ける |
| 誤検知を無視する | 検証済みのベースラインを維持する |
| 症状だけを修正する | 根本原因に対処する |
| デプロイ前に一度だけスキャンする | 継続的にスキャンする |
| サードパーティの依存関係を盲信する | 整合性を検証し、コードを監査する |
11. レポート作成の原則
検出事項の構成
各検出事項では、次の質問に答える必要があります。
- 何か？ - 脆弱性を明確に説明する
- どこか？ - 正確な場所（ファイル、行、エンドポイント）
- なぜか？ - 根本原因を説明する
- 影響は？ - ビジネス上の影響
- どう修正するか？ - 具体的な修正方法
重大度の分類
| 重大度 | 基準 |
|---|
| Critical | RCE、認証バイパス、大規模なデータ漏えい |
| High | データ漏えい、権限昇格 |
| Medium | 影響範囲が限定的で、特定の条件が必要 |
| Low | 情報提供、ベストプラクティス |
覚えておいてください： 脆弱性スキャンは問題を検出します。何が重要かを優先順位付けするには、専門的な判断が必要です。常に「攻撃者ならこれをどう悪用するか？」と考えてください。
使用する場面
このスキルは、概要で説明されているワークフローまたはアクションを実行する場合に適用できます。
制限事項
- 同梱のスキャナーはデータフローや到達可能性の分析ではなく、正規表現によるヒューリスティックを使用します。一致した箇所は手動で検証する必要があり、一致がないことは安全性の判断にはなりません。Git 履歴、バイナリ、スキップされたディレクトリは対象外です。ネットワークを使った依存関係の監査は
--allow-network を指定した場合に限り有効になり、依存関係のメタデータを設定済みのレジストリに送信します。読み取りエラーやツールのエラーがある場合、網羅的な確認ができていません。合格とみなさないでください。
- このスキルは、タスクが上記の範囲に明確に合致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を止めて確認してください。
