vulnerability-deduplication

脆弱性の重複排除

概要

このスキルを使用すると、複数のスキャナーが同じ資産に対して同じ CVE を報告した際に生じる脆弱性レコードを、脆弱性管理チームが特定して統合できます。重複排除によりノイズを減らし、修正対応の効率を高め、組織が実際に抱える脆弱性の範囲を正確に把握できます。

主な機能：

• CVE ID と構成アイテムを照合して、重複する脆弱性アイテムを特定する
• 異なるスキャナーが同じ問題を報告した場合の、類似する重複を検出する
• 冗長な修正タスクを、実行可能な単一のアイテムに統合する
• CVSS スコアとビジネス上の重要度を使用して、重複排除後の脆弱性に優先順位を付ける
• 重複の削減数と実際の脆弱性件数を示すレポートを生成する
• 重複排除の判断に関する監査証跡を保持する

使用するタイミング： 脆弱性スキャンのインポート後、定期的な脆弱性衛生レビュー中、新しいスキャナーの導入時、または複数のスキャナー間の重複によって脆弱性件数が過大に見える場合。

前提条件

• ロール： sn_vul.manager、sn_vul.admin
• アクセス： sn_vul_vulnerable_item、sn_vul_entry、sn_vul_third_party_entry、sn_vul_remediation_task テーブルへの読み取り／書き込みアクセス
• プラグイン： Vulnerability Response (sn_vul)
• データ： 1 つ以上のスキャナーからインポートされた ServiceNow の脆弱性スキャンデータ

手順

ステップ 1：CVE と CI によって重複候補を特定する

同じ CVE と構成アイテムを共有する脆弱性アイテムを検索します。これは、複数のスキャナーソースからの重複を示します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var ga = new GlideAggregate('sn_vul_vulnerable_item');
    ga.addQuery('state', 'IN', 'Open,Under Investigation');
    ga.addAggregate('COUNT');
    ga.groupBy('vulnerability');
    ga.groupBy('cmdb_ci');
    ga.addHaving('COUNT', '>', 1);
    ga.query();
    var dupCount = 0;
    while (ga.next()) {
      dupCount++;
      gs.info('Duplicate: Vuln=' + ga.vulnerability.getDisplayValue() +
              ' CI=' + ga.cmdb_ci.getDisplayValue() +
              ' Count=' + ga.getAggregate('COUNT'));
    }
    gs.info('Total duplicate groups found: ' + dupCount);

REST を使用：

GET /api/now/stats/sn_vul_vulnerable_item?sysparm_query=stateINOpen,Under Investigation&sysparm_count=true&sysparm_group_by=vulnerability,cmdb_ci&sysparm_having=COUNT>1

ステップ 2：特定の CVE の重複レコードを取得する

重複グループごとに完全なレコードを取得し、スキャナーソースと検出の詳細を比較します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_vulnerable_item
  query: vulnerability=[VULNERABILITY_SYS_ID]^cmdb_ci=[CI_SYS_ID]^stateINOpen,Under Investigation
  fields: sys_id,vulnerability,cmdb_ci,state,risk_score,cvss_score,first_found,last_found,source,scanner,assignment_group,assigned_to,remediation_task
  limit: 20

REST を使用：

GET /api/now/table/sn_vul_vulnerable_item?sysparm_query=vulnerability=[VULNERABILITY_SYS_ID]^cmdb_ci=[CI_SYS_ID]^stateINOpen,Under Investigation&sysparm_fields=sys_id,vulnerability,cmdb_ci,state,risk_score,cvss_score,first_found,last_found,source,scanner,assignment_group,assigned_to,remediation_task&sysparm_limit=20&sysparm_display_value=true

ステップ 3：脆弱性エントリーから CVE の詳細を取得する

正式な CVE 情報を取得するため、正規の脆弱性エントリーを検索します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_entry
  query: sys_id=[VULNERABILITY_SYS_ID]
  fields: sys_id,cve_id,description,cvss_score,severity,exploit_available,vendor_advisory,published_date,solution
  limit: 1

REST を使用：

GET /api/now/table/sn_vul_entry?sysparm_query=sys_id=[VULNERABILITY_SYS_ID]&sysparm_fields=sys_id,cve_id,description,cvss_score,severity,exploit_available,vendor_advisory,published_date,solution&sysparm_limit=1

ステップ 4：サードパーティ製スキャナーのエントリーを確認する

スキャナー固有のエントリーを確認し、どのスキャナーが同じ脆弱性を報告したかを把握します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_third_party_entry
  query: vulnerability_entry=[VULNERABILITY_SYS_ID]
  fields: sys_id,source,scanner_id,vulnerability_entry,severity,first_found,last_found,status,plugin_id
  limit: 20

REST を使用：

GET /api/now/table/sn_vul_third_party_entry?sysparm_query=vulnerability_entry=[VULNERABILITY_SYS_ID]&sysparm_fields=sys_id,source,scanner_id,vulnerability_entry,severity,first_found,last_found,status,plugin_id&sysparm_limit=20&sysparm_display_value=true

ステップ 5：影響を受ける CI のビジネスコンテキストを取得する

資産の詳細を取得し、優先順位付けにビジネス上の重要度を反映します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_ci
  query: sys_id=[CI_SYS_ID]
  fields: sys_id,name,sys_class_name,ip_address,os,environment,business_criticality,support_group,department,operational_status
  limit: 1

REST を使用：

GET /api/now/table/cmdb_ci?sysparm_query=sys_id=[CI_SYS_ID]&sysparm_fields=sys_id,name,sys_class_name,ip_address,os,environment,business_criticality,support_group,department,operational_status&sysparm_limit=1&sysparm_display_value=true

ステップ 6：重複レコードを統合する

first_found の日付が最も早く、データが最も充実しているレコードを残します。重複レコードを、プライマリレコードへの参照を付けてクローズします。

MCP を使用：

Tool: SN-Update-Record
Parameters:
  table_name: sn_vul_vulnerable_item
  sys_id: [DUPLICATE_SYS_ID]
  fields:
    state: Closed
    close_notes: "Duplicate of [PRIMARY_SYS_ID]. Same CVE ([CVE_ID]) on same CI ([CI_NAME]) reported by different scanner ([SCANNER_NAME]). Consolidated into primary record."

Tool: SN-Add-Work-Notes
Parameters:
  table_name: sn_vul_vulnerable_item
  sys_id: [PRIMARY_SYS_ID]
  work_notes: "Deduplication: Consolidated [N] duplicate records from scanners [SCANNER_LIST]. This record retained as primary. Earliest first_found: [DATE]. Highest risk_score: [SCORE]."

REST を使用：

PATCH /api/now/table/sn_vul_vulnerable_item/[DUPLICATE_SYS_ID]
Content-Type: application/json

{
  "state": "Closed",
  "close_notes": "Duplicate of [PRIMARY_SYS_ID]. Same CVE on same CI from different scanner. Consolidated."
}

ステップ 7：修正タスクを統合する

重複する脆弱性アイテムに対して作成された冗長な修正タスクを特定し、統合します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_vul_remediation_task
  query: vulnerable_item=[PRIMARY_SYS_ID]^ORvulnerable_item=[DUPLICATE_SYS_ID]^stateINOpen,In Progress
  fields: sys_id,number,short_description,state,assigned_to,assignment_group,vulnerable_item,opened_at,due_date
  limit: 20

重複する修正タスクをクローズします：

Tool: SN-Update-Record
Parameters:
  table_name: sn_vul_remediation_task
  sys_id: [DUPLICATE_TASK_SYS_ID]
  fields:
    state: Closed
    close_notes: "Consolidated with [PRIMARY_TASK_NUMBER]. Duplicate vulnerability record closed during deduplication."

REST を使用：

GET /api/now/table/sn_vul_remediation_task?sysparm_query=vulnerable_itemIN[PRIMARY_SYS_ID],[DUPLICATE_SYS_ID]^stateINOpen,In Progress&sysparm_fields=sys_id,number,short_description,state,assigned_to,assignment_group,vulnerable_item,opened_at,due_date&sysparm_limit=20&sysparm_display_value=true

PATCH /api/now/table/sn_vul_remediation_task/[DUPLICATE_TASK_SYS_ID]
Content-Type: application/json

{
  "state": "Closed",
  "close_notes": "Consolidated with primary remediation task during deduplication."
}

ステップ 8：重複排除レポートと優先順位付け済みの脆弱性リストを生成する

重複排除後に、リスクに基づいて優先順位付けした、一意の脆弱性をまとめた見やすいビューを生成します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var gr = new GlideRecord('sn_vul_vulnerable_item');
    gr.addQuery('state', 'IN', 'Open,Under Investigation');
    gr.orderByDesc('risk_score');
    gr.query();
    var results = [];
    while (gr.next()) {
      results.push({
        vuln: gr.vulnerability.getDisplayValue(),
        ci: gr.cmdb_ci.getDisplayValue(),
        cvss: gr.cvss_score + '',
        risk: gr.risk_score + '',
        first_found: gr.first_found + '',
        source: gr.source + ''
      });
    }
    gs.info('Unique open vulnerabilities after dedup: ' + results.length);
    // Output top 20 by risk score
    for (var i = 0; i < Math.min(20, results.length); i++) {
      gs.info((i+1) + '. ' + results[i].vuln + ' on ' + results[i].ci +
              ' (CVSS: ' + results[i].cvss + ', Risk: ' + results[i].risk + ')');
    }

重複排除サマリーテンプレート：

=== VULNERABILITY DEDUPLICATION REPORT ===
Date: 2026-03-19 | Analyst: J. Smith

BEFORE DEDUPLICATION:
Total Open Vulnerable Items: 2,847
Unique CVE+CI Combinations: 1,923

DUPLICATES IDENTIFIED: 924 (32.5% duplication rate)

BY SCANNER SOURCE:
| Scanner | Records | Unique | Duplicates | Dup Rate |
|---------|---------|--------|------------|----------|
| Qualys | 1,450 | 1,200 | 250 | 17.2% |
| Tenable | 1,100 | 950 | 150 | 13.6% |
| Rapid7 | 297 | 273 | 24 | 8.1% |
| Cross-scanner overlap | - | - | 500 | - |

ACTIONS TAKEN:
- Closed 924 duplicate vulnerable item records
- Consolidated 312 redundant remediation tasks
- Updated 1,923 primary records with consolidated scanner data

TOP 10 CRITICAL UNIQUE VULNERABILITIES:
| Rank | CVE | CVSS | CI | Environment | Exploit |
|------|-----|------|----|-------------|---------|
| 1 | CVE-2025-44123 | 9.8 | WEBSVR-01 | Production | Yes |
| 2 | CVE-2025-33456 | 9.1 | DB-PROD-02 | Production | Yes |
| 3 | CVE-2025-22789 | 8.8 | APPSVR-05 | Production | No |
| 4 | CVE-2025-11234 | 8.5 | FILESVR-03 | Production | Yes |
| 5 | CVE-2025-99876 | 8.1 | MAIL-01 | Production | No |
...

RECOMMENDATIONS:
1. Schedule recurring deduplication job (weekly recommended)
2. Configure scanner import rules to prevent duplicate creation
3. Prioritize patching for top 10 critical vulnerabilities with exploits
4. Review Qualys/Tenable overlap rules to reduce cross-scanner duplicates

ツールの使用方法

ツール	目的
SN-Query-Table	脆弱性アイテム、CVE エントリー、スキャナーデータ、CI を取得する
SN-Execute-Background-Script	集計クエリと一括重複排除スクリプトを実行する
SN-Update-Record	重複レコードをクローズし、プライマリレコードを更新する
SN-Add-Work-Notes	脆弱性レコードに重複排除の判断を記録する

ベストプラクティス

• 重複を統合する際は、正確な露出期間を維持できるよう、常に最も早い first_found 日を保持します
• リスクを過小評価しないよう、主要レコードには最も高い risk_score と cvss_score を保持します
• 監査証跡として、クローズした重複レコードを参照する作業メモに、統合の判断を記録します
• 重複の蓄積を防ぐため、スキャンをインポートするたびに重複排除を実行します
• スキャナーによって同じ CVE に異なるプラグイン ID が付与される場合があるため、スキャナー固有のプラグイン ID を考慮します
• 一括クローズの前に、特定された重複のサンプルを確認して正確性を検証します
• スケジュールされたスクリプトや、スキャンのインポート時に実行されるビジネスルールを使用して、定期的な重複排除を自動化します
• 修復チームがどのスキャナーで検出が確認されたか把握できるよう、主要レコードにスキャナーのソースメタデータを保持します

トラブルシューティング

集計クエリで重複が返されない

原因： 異なるスキャナーからインポートされた場合、同じ CVE でも vulnerability フィールドが異なる sn_vul_entry レコードを参照している可能性があります。 解決策： vulnerability の sys_id ではなく、sn_vul_entry の cve_id を使って結合します。まず sn_vul_entry をクエリして、重複する CVE ID を確認します。

スキャナーのソースフィールドが空

原因： スキャナーの統合機能によって、脆弱性アイテムの source フィールドや scanner フィールドが設定されない場合があります。 解決策： sn_vul_third_party_entry テーブルでスキャナーのソースデータを確認します。ソースのマッピングが設定されていることを確かめるため、スキャナー統合の設定を確認します。

重複排除後に修復タスクが孤立する

原因： 重複する脆弱性アイテムをクローズしても、関連する修復タスクは自動的にクローズされません。 解決策： 重複排除プロセスの一環として、必ず関連する修復タスクをクエリしてクローズします（ステップ 7）。これを自動化するビジネスルールの作成を検討します。

重複排除によって実際には固有のレコードがクローズされる

原因： 同じ CI 上にある異なる脆弱性アイテムが、同じ CVE を共有しているために重複と見なされることがあります（例：インストールされている別々のアプリケーションに同じ CVE が存在する場合）。 解決策： 照合条件に port、protocol、または software フィールドを追加します。sn_vul_third_party_entry のスキャナープラグインの詳細を確認し、実際に重複していることを確かめます。

例

例 1：スキャンインポート後の重複排除

1. Tenable のスキャンで、新たに脆弱性アイテム 500 件をインポート
2. 重複検出を実行：既存の Qualys の検出結果と 78 件が一致（同じ CVE + CI）
3. 重複 10 件のサンプルを確認し、一致の正確性を検証
4. Qualys のレコード（より早い first_found）を保持し、重複 78 件を一括クローズ
5. 冗長な修復タスク 23 件を統合
6. 実際に新たに検出された項目が 422 件（500 件ではない）と示すレポートを作成

例 2：四半期ごとの脆弱性衛生レビュー

1. 未クローズの脆弱性アイテム全件をクエリ：4,200 件
2. 3 つのスキャナーソースを対象に、重複排除の全件分析を実行
3. 重複 1,100 件を特定（重複率 26.2%）
4. 同じ資産上で 3 つすべてのスキャナーに検出されている CVE を 45 件確認
5. 重複をクローズし、タスクを統合して、主要レコードを更新
6. 優先順位付けされた露出リストを作成：固有の脆弱性 3,100 件
7. 整理済みデータと正確な露出指標を CISO に提示

関連スキル

• secops/correlation-insights - 重複排除された脆弱性と進行中のセキュリティインシデントを関連付けます
• secops/metrics-analysis - 重複排除率と脆弱性の露出傾向を追跡します
• secops/incident-summarization - インシデントの要約で、重複排除された脆弱性データを参照します
• secops/post-incident-analysis - PIR の際に脆弱性の重複排除の有効性をレビューします
• cmdb/data-quality - 適切な脆弱性照合のため、CI レコードの正確性を確保します