誤解を招く脆弱性の重大度を、ポリシーで修正する5つの方法

企業の脆弱性レポートには、スキャンサイクルごとに数百件もの検出結果が表示され、すべてCVSS（共通脆弱性評価システム）によってランク付けされています。問題は、CVSSがCVE（共通脆弱性識別子）の理論的な特性を記述するものであり、自社環境での実際のリスクを示すものではないという点です。内部専用のユーティリティライブラリにある「緊急（Critical）」の脆弱性と、公開されている認証サービスにある「中（Medium）」の脆弱性は、リスクとして同列には扱えません。しかし、手動でトリアージしない限り、両者は同じように扱われてしまいます。こうした手動トリアージは、スケールしません。

GitLabの脆弱性管理ポリシーでは、定義した条件に基づいてデフォルトのCVSS重大度レベルを自動的にオーバーライドできるようになりました。これにより、脆弱性レポートが汎用的なスコアではなく、自社の実際のリスクモデルを反映したものになります。

重大度オーバーライドポリシーの仕組み

重大度オーバーライドポリシーは、脆弱性管理ポリシーの一種で、デフォルトブランチのパイプライン実行のたびに脆弱性の重大度レベルを自動的に調整します。マッチ条件（CVE ID、CWE ID、ファイルパス、ディレクトリ）とオーバーライドアクションを含むルールを定義します。脆弱性が条件に一致すると、GitLabのSecurity Policy Botが即座に重大度を更新します。

利用できるオーバーライド操作は3種類です。

• 重大度を設定（Set Severity）: 重大度を特定のレベル（info、low、medium、high、critical）に固定します。
• 重大度を上げる（Increase Severity）: 重大度を1段階引き上げます。
• 重大度を下げる（Decrease Severity）: 重大度を1段階引き下げます。

権限を持つユーザーによる手動オーバーライドは、常にポリシーによるオーバーライドより優先されます。自動変更はすべて脆弱性の履歴と監査イベントに記録されるため、何が変更され、その理由についての完全な記録を維持できます。

すぐに使える設定付きユースケース

以下の各例には、すぐにコピー・カスタマイズして適用できるポリシー設定を記載しています。

1. 内部サービスにおける低リスクCVEの重大度を下げる

セキュリティスキャナーは、どのプロジェクトが内部ツール、テストユーティリティ、または本番サービスであるかを認識しません。デプロイのコンテキストに関わらず、すべてのCVEを同じように評価します。外部トラフィックにさらされることのない内部管理ダッシュボード、開発者向けツール、バッチ処理ジョブを運用しているチームにとって、Critical評価の依存関係の脆弱性は、顧客向けAPIにある脆弱性と同じ対応を必要とするわけではありません。

このポリシーは、内部サービスのディレクトリで検出された特定のCVEの重大度を下げます。

      vulnerability_management_policy:
  - name: "Downgrade CVEs in internal services"
    description: "Internal-only services have lower exposure risk"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2023-44487"
              - "CVE-2024-29041"
          - type: directory
            value: "internal/**/*"
    actions:
      - type: severity_override
        severity_override_operation: decrease

    

CVEの値は、チームが内部デプロイにおいて低リスクと判断した識別子に置き換えてください。decrease 操作により重大度が1段階下がります（CriticalはHighに、HighはMediumになります）。コンテキストに不適切なスコアに過剰反応することなく、相対的な優先度を維持できます。

2. 本番コードにおけるインジェクション脆弱性の重大度を上げる

本番ソースコードで検出された場合、より強力な対応が必要な脆弱性クラスがあります。クロスサイトスクリプティング（CWE-79）およびSQLインジェクション（CWE-89）は、OWASPとCISAの既知の悪用された脆弱性（KEV）カタログによると、最も悪用されている脆弱性タイプに継続的にランクインしています。スキャナーが src/ ディレクトリ内でこれらをMediumまたはHighと報告している場合、トリアージプロセスではCriticalとして扱う必要があります。

このポリシーは、本番コードにおけるXSSおよびSQLiの検出結果の重大度をCriticalに設定します。

      vulnerability_management_policy:
  - name: "Upgrade XSS and SQLi in production code"
    description: "Injection vulnerabilities in src/ are always Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
          - type: directory
            value: "src/**/*"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

このポリシーと、Criticalの検出結果にセキュリティチームの承認を必要とするマージリクエスト承認ポリシーを組み合わせることをお勧めします。重大度オーバーライドにより、脆弱性レポートで適切な検出結果にフラグが立てられて優先度が付けられ、承認ポリシーにより、新たに検出された検出結果がレビューなしに本番環境に到達できなくなります。

3. スキャナー間で重大度を統一する

スキャナーによっては、同じCVEに異なる重大度レベルを割り当てることがあります。SAST（静的アプリケーションセキュリティテスト）スキャナーがHighと評価した検出結果を、依存関係スキャンがMediumと呼ぶ場合があります。こうした不整合はトリアージ時に混乱を招き、スキャンタイプをまたいだ一貫した承認しきい値の設定を困難にします。

重大度オーバーライドポリシーを使用して、一貫したベースラインを適用します。セキュリティチームが特定のCVEファミリーを評価し、どのスキャナーで検出されたかに関わらず常にHighであるべきと判断した場合、明示的に設定できます。

      vulnerability_management_policy:
  - name: "Normalize log4j severity to High"
    description: "Consistent severity for log4j CVEs across all scanners"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2021-44228"
              - "CVE-2021-45046"
              - "CVE-2021-45105"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: high

    

これは、SAST、依存関係スキャン、コンテナスキャンなど複数のスキャンタイプを運用している組織において特に有効です。検出方法によって評価が異なる同一の脆弱性が、それぞれ異なる重大度で表示される状況に対処できます。

4. エクスプロイトインテリジェンスに合わせて重大度を調整する

CVSSスコアは静的です。脆弱性が実際に悪用されはじめても変化せず、現実世界での悪用確率も考慮しません。FIRSTのExploit Prediction Scoring System（EPSS）とCISAのKEVカタログが、この欠けているシグナルを提供します。

脅威インテリジェンスから、あるMedium重大度のCVEが現在活発に悪用されている（KEV）か、悪用確率が高い（EPSSが0.5超）と判明した場合、重大度オーバーライドで引き上げます。

      vulnerability_management_policy:
  - name: "Upgrade actively exploited CVEs"
    description: "CVEs in CISA KEV catalog should be treated as Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2024-3094"
              - "CVE-2023-4966"
              - "CVE-2023-22515"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

自社のスタックに関連するKEVエントリのリストを管理し、新たなCVEがカタログに追加されるたびにポリシーを更新してください。これにより、アナリストが各検出結果を手動で調整することなく、脅威インテリジェンスと開発者向けの重大度表示をつなぐフィードバックループが生まれます。

5. グループレベルで組織全体のリスクモデルを適用する

組織に数百または数千のプロジェクトがある場合、プロジェクト単位のポリシーは管理できません。重大度オーバーライドポリシーはグループレベルで適用でき、グループ内のすべてのプロジェクトに影響を与えます。policy_scope と組み合わせることで、特定のコンプライアンスフレームワークラベルに一致するプロジェクトにポリシーをターゲット指定できます。

例えば、「PCI-DSS」コンプライアンスフレームワークを持つ組織では、PCI対象プロジェクト全体にインジェクション脆弱性の厳格な重大度処理を適用しつつ、内部ツールグループには緩いポリシーを適用できます。

      vulnerability_management_policy:
  - name: "PCI projects: upgrade injection severity"
    description: "All injection vulnerabilities are Critical in PCI scope"
    enabled: true
    policy_scope:
      compliance_frameworks:
        - id: 12345
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
              - "CWE-78"
              - "CWE-94"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

このパターンにより、セキュリティチームがリスクモデルを一度定義するだけで、あらゆる場所に一貫して適用されます。プロジェクトごとの設定も、個々のチームが正しく設定することへの依存も不要です。

はじめ方

脆弱性管理ポリシーを作成するには、以下の手順に従ってください。

1. 不一致を特定する。 脆弱性レポートを開き、「Needs triage」でフィルタリングします。パターンを探してください。テストコードにあるCriticalの検出結果、活発に悪用されているMediumの検出結果、スキャンタイプをまたいだ一貫性のない評価などです。
2. ユースケースを1つ選ぶ。 上記のシナリオの中から、最も多くの不一致な検出結果に対応するものから始めます。
3. ベースラインを記録する。 ポリシーを作成する前の重大度分布（対象スコープ内のCritical、High、Mediumの件数）を記録します。
4. 作成して適用する。 Secure > Policies > New policy > Vulnerability management policy に移動し、上記のユースケースから設定を貼り付けてマージリクエストをマージします。
5. 結果を検証する。 次のデフォルトブランチパイプライン実行後、脆弱性レポートで更新された重大度を確認します。アクティビティログをフィルタリングして調整された検出結果を確認し、対象が正しいことを検証します。

クイックリファレンス

よくある質問

自動却下（auto-dismiss）と重大度オーバーライドの違いは何ですか？
自動却下は、検出結果をアクティブなトリアージキューから削除します。重大度オーバーライドは、検出結果を表示したまま優先度レベルを調整するため、適切な緊急度で追跡・レビューが続けられます。

重大度オーバーライドを他のポリシータイプと組み合わせることはできますか？
はい。重大度オーバーライドは default ブランチの検出結果に適用され、GitLabの脆弱性レポートに表示される脆弱性に影響します。その後、マージリクエスト承認ポリシーを使用して新たに検出された検出結果をゲートできます。

重大度オーバーライドは既存の脆弱性に遡及して適用されますか？
はい。重大度オーバーライドポリシーが適用されると、次のデフォルトブランチパイプライン実行時に、ステータスが「Needs triage」または「Confirmed」の一致する脆弱性が1回につき最大1,000件処理されます。

2つのポリシーが競合する重大度を設定した場合、どうなりますか？
手動オーバーライドは常に優先されます。ポリシーの競合については、最後に適用されたポリシーが優先されます。重複する条件を避けるため、定期的にポリシーを見直してください。

開発者は重大度オーバーライドポリシーを回避できますか？
いいえ。ポリシーはアクセスが制限されたセキュリティポリシープロジェクトで管理されます。開発者はポリシーを変更したり無効にしたりできません。権限を持つユーザーは個々の脆弱性に手動オーバーライドを適用でき、これが優先されます。

脆弱性レポートに実際のリスクを反映させる準備はできていますか？重大度オーバーライドポリシーのドキュメントで詳細を確認するか、GitLab Ultimateの無料トライアルを開始して今すぐお試しください。