スキャナーツールからアラートを解釈する

11 分

ソフトウェアコンポジション分析ツールは、依存関係の脆弱性、ライセンスの問題、およびコード品質の問題に関する多数のアラートを生成します。これらのアラートを効果的に解釈するには、重大度スコアを理解し、悪用可能性を評価し、誤検知を管理し、アプリケーションに対する実際のリスクに基づいて修復作業の優先順位を付ける必要があります。適切な解釈と優先順位付けを行わないと、チームは重大な脆弱性を見逃しながら、影響の少ない問題でアラートの疲労と無駄な時間に直面します。

脆弱性の重大度について

脆弱性の重大度スコアは、標準化されたリスク評価を提供します。

CVSS スコアリングシステム

Common Vulnerability Scoring System (CVSS) は、脆弱性の重大度を示す標準化された数値スコアを提供します。

CVSS メトリックのカテゴリ:

基本メトリック: 特定の環境に依存しない固有の脆弱性特性。
テンポラルメトリック: 時間の経過と伴って変化する脆弱性特性 (悪用の可用性、パッチの可用性、信頼度)。
環境メトリック: 特定の環境とデプロイに固有の脆弱性の特性。

CVSS v3 ベーススコアの計算: 基本スコアは、複数のメトリックを組み合わせます。

悪用可能性メトリック:

攻撃ベクトル (AV): ネットワーク (N)、隣接 (A)、ローカル (L)、または物理 (P)。
攻撃の複雑さ (AC): 低 (L)、または高 (H) の脆弱性を悪用する難易度。
必要な特権 (PR): 悪用するために必要な特権である [なし] (N)、[低] (L)、または [高] (H)。
ユーザー操作 (UI): 悪用を成功させるには、なし (N) または必須 (R) です。

影響メトリック:

機密性への影響 (C): なし (N)、低 (L)、または高 (H) の情報開示。
整合性への影響 (I): なし (N)、低 (L)、高 (H) のデータ変更機能。
可用性への影響 (A): なし (N)、低 (L)、高 (H) サービス中断。

CVSS ベクターの例:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

これは、攻撃の複雑さが少なく、特権が不要で、ユーザーの操作がなく、機密性、整合性、可用性に大きな影響を与えるネットワーク悪用可能な脆弱性を表します。

重大度の分類

CVSS スコアは重大度評価にマップされます。

重症度	CVSS スコア	説明	優先順位
重大	9.0 - 10.0	広範囲にわたるシステム侵害を引き起こす悪用可能な脆弱性。	即時修復が必要です。
High	7.0 - 8.9	重大な情報漏えいまたはサービスの中断を可能にする重大な脆弱性。	修復は数日以内に必要です。
Medium	4.0 - 6.9	脆弱性を中程度にし、悪用可能性や影響が制限されます。	数週間以内に修復が必要です。
Low	0.1 - 3.9	セキュリティへの影響を最小限に抑えた軽微な脆弱性。	便利な場合の修復。
なし	0.0	実際のセキュリティへの影響のない情報の結果。	オプションの修復。

重大度の解釈の例:

重大な脆弱性 (CVSS 10.0):

CVE-2021-44228 (Log4Shell)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description: Remote code execution in Apache Log4j 2
Impact: Unauthenticated attacker can execute arbitrary code remotely
Exploitability: Actively exploited in the wild with publicly available exploits

高い脆弱性 (CVSS 8.1):

CVE-2022-23648
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Description: Path traversal in container runtime
Impact: Authenticated users can access files outside container boundaries
Exploitability: Requires authentication but easily exploitable

中程度の脆弱性 (CVSS 5.9):

CVE-2023-12345
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Description: Information disclosure through timing attack
Impact: Sensitive information disclosure possible with sophisticated attack
Exploitability: Requires specific timing conditions, difficult to exploit

悪用可能性の評価

CVSS スコアは完全なストーリーを示しません。悪用可能性評価によって、実際のリスクが決まります。

エクスプロイトの成熟度

Exploitの利用可能ステージ:

未証明：

地位： 既知の悪用のない理論的な脆弱性。
リスクレベル: リスクの低減 — 悪用には、攻撃者の多大な労力が必要です。
アクション： エクスプロイトの開発を監視する。修復を計画しますが、緊急ではありません。

概念実証:

地位： 概念実証の悪用コードは公開されていますが、武器化されていません。
リスクレベル: 中程度のリスク—高度な攻撃者が悪用を武器にする可能性があります。
アクション： 修復に優先順位を付ける。軽減戦略を策定する。

機能的な：

地位： 動作中の悪用コードが公開されています。
リスクレベル: 危険度が高い-中程度のスキルを持つ攻撃者が悪用にアクセスできる。
アクション： 迅速な修復。修正プログラムの適用が遅れた場合は、一時的な軽減策を実装します。

アクティブな悪用:

地位： 脆弱性は、野生で積極的に悪用されます。
リスクレベル: 重大なリスク- 現在発生している悪用。
アクション： 緊急対策；直ちに軽減策を実施し、侵害を監視する。

悪用可能性評価の例:

CVE-2021-44228 (Log4Shell)
Severity: Critical (CVSS 10.0)
Exploit Maturity: Active exploitation

Analysis:
- Public exploit code available within hours of disclosure
- Automated scanning and exploitation observed globally
- Multiple malware families incorporating the exploit
- Trivial to exploit with single HTTP request

Priority: EMERGENCY - Immediate patching required

攻撃面の分析

脆弱性に到達できるかどうかを判断します。

到達可能性の要因:

コードの使用法: 脆弱なコードパスは実際にアプリケーションによって実行されますか?
ネットワークの露出: 脆弱なコンポーネントはネットワークアクセスに公開されていますか?
認証要件: 悪用には認証済みアクセスが必要ですか?
構成の依存関係: この脆弱性を悪用するには、特定の構成が必要ですか?

到達可能性の例:

Vulnerability: SQL injection in unused admin feature
Severity: High (CVSS 8.5)
Reachability: NOT REACHABLE

Analysis:
- Vulnerable code exists in imported library
- Admin features are disabled in production configuration
- Vulnerable code paths never executed
- Network access to admin interface blocked by firewall

Priority: LOW - Update during regular maintenance window

環境コンテキスト

特定の環境を検討します。

ネットワークのセグメント化:

インターネットに接続: インターネットに接続するコンポーネントの脆弱性の優先度が最も高い。
内部ネットワーク: ネットワークがセグメント化されている場合、内部のみの脆弱性の優先順位は低くなります。
分離システム: エアギャップまたは分離されたシステムは、ネットワークの脆弱性によるリスクを最小限に抑えます。

データ感度:

機密データ: 機密データを処理するシステムの脆弱性には、緊急の修復が必要です。
公開情報: データが既に公開されている場合、情報漏えいの脆弱性の優先順位は低くなります。
テスト環境: 非運用環境の脆弱性は、通常、優先度が低くなります。

補正コントロール:

Web アプリケーションファイアウォール: WAF ルールは、悪用の試行を軽減する可能性があります。
侵入検出: IDS/IPS は、悪用の試行を検出してブロックできます。
ネットワークのセグメント化: ネットワーク分離により、悪用への影響が制限されます。
最小特権: 制限されたアクセス許可により、悪用の影響が軽減されます。

誤検知の管理

報告されたすべての脆弱性が実際にアプリケーションに影響を与えるわけではありません。

一般的な誤検知の原因

誤って識別されたコンポーネント:

名前付けの競合: 類似した名前の異なるコンポーネントが正しく一致しません。
バージョン検出エラー: バージョン識別が正しくないと、誤った脆弱性の一致が発生します。
パッケージ名前空間の混乱: 異なるエコシステム内のパッケージが、誤って同じパッケージとして識別されました。

誤検知の例:

Alert: CVE-2022-12345 in "parser" package (npm)
Severity: High

Investigation:
- Application uses "xml-parser" package
- Scanner incorrectly identified "xml-parser" as vulnerable "parser" package
- Different packages with similar names
- Vulnerability does not affect application

Resolution: Suppress false positive with documented justification

未使用のコードパス:

デッドコード: 脆弱なコードがインポートされましたが、実行されていません。
オプションの機能: アプリケーションで有効にならないオプション機能の脆弱性。
開発の依存関係: 開発中にのみ使用されるパッケージの脆弱性。運用環境では使用されません。

バージョン範囲のエラー:

バージョンレポートを修正しました: スキャナーは、既に修正プログラムが適用されているバージョンの脆弱性を報告します。
バックポートパッチ: ベンダーは、バージョン番号を変更せずに、以前のバージョンにセキュリティ修正プログラムをバックポートします。
カスタムパッチ: 脆弱性は、カスタム変更によって既に修正プログラムが適用されています。

偽陽性の検証

調査プロセス:

コンポーネント ID を確認します。 スキャナーがコンポーネントを正しく識別したことを確認します。
バージョンの精度を確認します。 検出されたバージョンが実際にデプロイされたバージョンと一致するかどうかを確認します。
脆弱性の詳細を確認します。 脆弱性が影響を受ける内容を理解します。
コードの使用状況を分析する: 脆弱なコードパスが実際に使用されているかどうかを判断します。
ベンダーのアドバイザリを参照してください。 ベンダーが追加のコンテキストを提供しているかどうかを確認します。
テストの悪用: テスト環境で脆弱性の再現を試みます。

ドキュメントの要件: 誤検知を抑制する場合は、次のドキュメントを参照してください。

ジャスティフィケーション： 結果が誤検知である理由。
調査の詳細: 誤検知を確認するための手順。
承認： 抑制を承認するセキュリティチームメンバー。
レビュー日: 抑制を再評価する日付。

抑制ファイルの例 (OWASP Dependency-Check):

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>
            False positive: CVE-2022-12345 affects "parser" package but we use "xml-parser".
            Scanner incorrectly matched based on partial name match.
            Investigated by security team on 2025-10-21.
            Review annually.
        </notes>
        <packageUrl regex="true">^pkg:npm/xml-parser@.*$</packageUrl>
        <cve>CVE-2022-12345</cve>
    </suppress>
</suppressions>

優先順位付けフレームワーク

効果的な脆弱性管理には、体系的な優先順位付けが必要です。

リスクベースの優先順位付け

優先順位付けの要因:

重大度スコア (25% の重み):

CVSS ベーススコアは、リスク評価の基礎を提供します。
スコアが高いほど、より深刻な影響を与える可能性があることを示します。

悪用可能性 (35% 比重):

アクティブな悪用の状態が最も重要な要因です。
パブリックエクスプロイトの可用性により、リスクが大幅に増加します。
概念実証の悪用は、実行可能な悪用を示します。

資産の重要度 (20% 重み):

インターネットに接続するアプリケーションの優先度が高くなります。
機密データを処理するシステムには、緊急の修正プログラムが必要です。
ビジネスクリティカルなアプリケーションでは、長時間のダウンタイムを許容できません。

環境要因 (20% 重量):

既存の補正コントロールにより、効果的なリスクが軽減されます。
ネットワークセグメント化では、ブラスト半径が制限されます。
監視機能により、脅威の検出が可能になります。

優先順位付けマトリックス:

悪用可能性	重大度: クリティカル	重大度が高い	中程度の重大度	重大度が低い
アクティブな悪用	P0 (緊急)	P0 (緊急)	P1 (重大)	P2 (高)
機能上の悪用	P0 (緊急)	P1 (重大)	P2 (高優先度)	P3 (中程度)
概念実証	P1 (重大)	P2 (高)	P3 (中程度)	P4 (低)
不可知論	P2 (高優先度)	P3 (ミディアム)	P4 (低)	P5 (任意)

修復 SLA

修復のためのサービスレベルアグリーメントを定義します。

緊急 (P0):

期間: 即時 (24 時間以内)。
条件： インターネットに接続するシステムでアクティブな悪用を受けている重大な脆弱性。
過程： 役員通知を含む緊急変更プロセス。
例：公開アプリケーションの Log4Shell (CVE-2021-44228)。

重大 (P1):

期間: 7 日。
条件： 機能の悪用やインターネットにさらされる高/重大な深刻度。
過程： セキュリティチームの調整による迅速な変更プロセス。
例：認証された管理インターフェイスでの SQL インジェクション。

高優先度 (P2):

期間: 30 日。
条件： 概念実証の悪用または内部公開による中/高の重大度。
過程： 計画メンテナンス期間を含む標準の変更プロセス。
例：内部ダッシュボードのクロスサイトスクリプティング (XSS)。

中 (P3):

期間: 90 日。
条件： 既知の悪用がない低/中の重大度。
過程： 四半期ごとの修正プログラムを適用した定期的な更新サイクル。
例：開発ツールの依存関係における情報漏えい。

低 (P4):

期間: 次のメジャーリリース。
条件： 重大度が低い誤検出や、ドキュメントが必要なもの。
プロセス： 定期的なメンテナンスアクティビティに含める。
例：未使用のオプション機能でのサービス拒否。

セキュリティバグバーの確立

セキュリティバグバーは 、満たす必要がある最低限のセキュリティ標準を定義します。

完了条件の定義

セキュリティバグバーの例:

Security Bug Bar:
  Blocking Issues (Must Fix Before Release):
    - No critical severity vulnerabilities
    - No high severity vulnerabilities with public exploits
    - No vulnerabilities actively exploited in the wild
    - No strong copyleft licenses (GPL, AGPL) in proprietary code
    - No secrets in source code or container images

  Non-Blocking Issues (Track and Plan):
    - High severity without public exploits (90-day remediation plan)
    - Medium severity vulnerabilities (next minor release)
    - License issues requiring legal review (document plan)

  Informational (Monitor):
    - Low severity vulnerabilities
    - Informational security findings
    - Code quality issues

ポリシーの適用

Azure Pipelines の品質ゲート:

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
  displayName: "Enforce security bug bar"

- script: |
    # Custom policy check script
    if [ $(jq '.vulnerabilities.critical' scan-results.json) -gt 0 ]; then
      echo "##vso[task.logissue type=error]Critical vulnerabilities detected"
      echo "##vso[task.complete result=Failed;]Failed security bug bar"
      exit 1
    fi
  displayName: "Validate security bug bar compliance"

脆弱性トリアージワークフロー

体系的なトリアージにより、効率的な脆弱性管理が保証されます。

トリアージプロセス

手順 1: 自動フィルター処理:

スキャナーツール: 脆弱性を重大度別に自動的にフィルター処理します。
到達可能性分析: トリアージキューから到達できない脆弱性を削除します。
既知の誤検知: 以前に識別された誤検知を自動的に抑制します。

手順 2: 初期評価:

重大度の確認: 環境の CVSS スコアの精度を確認します。
悪用可能性チェック: 悪用の可用性とアクティブな悪用を決定します。
資産の識別: 影響を受けるアプリケーションとシステムを特定します。

手順 3: リスク評価:

ビジネスへの影響: 悪用の成功による潜在的なビジネスへの影響を評価します。
露出分析: ネットワークの露出と攻撃対象領域を特定します。
補正コントロール: リスクを軽減する既存の軽減策を特定します。

手順 4: 優先順位付け:

優先度の割り当て: 優先順位付けマトリックスを使用して、修復の優先順位を割り当てます。
期限を設定します。 SLA に基づいて修復期限を割り当てます。
所有者の割り当て: 修復を担当するチームを指定します。

手順 5: 修復の追跡:

チケットを作成します。 追跡システム (Jira、Azure Boards) で作業項目を生成します。
進行状況の監視: 期限に対する修復の進行状況を追跡します。
検証： 再スキャンによって修復が成功したことを検証します。

ミーティングの頻度のトリアージ

毎週のセキュリティトリアージ:

参加者： セキュリティチーム、開発リーダー、運用担当者。
議題： 新しい高/重大な結果を確認し、修復の進行状況を追跡し、優先順位を調整します。
期間: 30 ~ 60 分。

毎月の脆弱性レビュー:

参加者： セキュリティリーダーシップ、エンジニアリング管理、コンプライアンスチーム。
議題： 傾向を確認し、ポリシーを調整し、全体的なセキュリティ体制を評価します。
期間: 60 ~ 90 分。

メトリックとレポート

脆弱性管理の有効性を追跡する:

主要なメトリック

脆弱性メトリック:

平均検出時間 (MTTD): 脆弱性の漏えいからシステムでの検出までの時間。
修復の平均時間 (MTTR): 検出から修復が成功までの時間。
脆弱性の密度: アプリケーションまたはコード行ごとの脆弱性の数。
修復率: SLA 内で修復された脆弱性の割合。

傾向メトリック:

開いている脆弱性の数: 重大度別の未解決の脆弱性の傾向数。
新規と解決済み: 新しく検出された脆弱性と修復された脆弱性の比較。
SLA コンプライアンス: 定義された SLA 内で修復された脆弱性の割合。
誤検知率: 誤検知と判断された結果の割合。

ダッシュボードの例

脆弱性管理ダッシュボード:

Critical Vulnerabilities: 0 (Target: 0)
High Vulnerabilities: 3 (Target: < 10)
Medium Vulnerabilities: 47 (Target: < 100)
Low Vulnerabilities: 132 (Tracking only)

Mean Time to Remediate:
- Critical: 18 hours ✓
- High: 6 days ✓
- Medium: 21 days ✓

Remediation Progress:
- P0 (Emergency): 0 overdue
- P1 (Critical): 1 due in 3 days
- P2 (High): 5 due in next 30 days
- P3 (Medium): 12 due in next 90 days

Trends (Last 90 Days):
- New vulnerabilities: 127
- Remediated: 138
- Net reduction: -11 ✓

注

サービスレベルアグリーメント (SLA) と修復タイムラインの詳細については、「 Azure サービスレベルアグリーメント」を参照してください。

効果的な脆弱性アラートの解釈と優先順位付けにより、スキャナーの圧倒的な出力が実用的なセキュリティ向上に変換されます。チームは、重大度スコアを理解し、悪用可能性を評価し、誤検知を管理し、体系的な優先順位付けを実装することで、すべてのアラートを追跡するのではなく、実際のリスクをもたらす脆弱性に対する修復作業に重点を置きます。このリスクベースのアプローチにより、アプリケーションを保護する持続可能なセキュリティプログラムが可能になり、開発チームがノイズを伴わずに圧倒的に保護されます。

フィードバック

このページはお役に立ちましたか?

スキャナー ツールからアラートを解釈する