Finding Deduplication and Merge

In ETM, all security findings related to a particular asset are imported and aggregated from multiple sources. Because the same issue can appear multiple times across tools, ETM de-duplicates overlapping records and consolidates them into a single, accurate view of risk.

This section explains what a duplicate finding is, how ETM detects and consolidates duplicates, how the rules that govern this behavior work, and what you can do with consolidated findings.

Why Duplicate Findings Occur

Finding data is imported from many external sources, such as Qualys VMDR, CrowdStrike, Microsoft Defender, Tenable, and other scanners and agents. It is expected to encounter overlapping information — for example, an identical CVE with the same asset context for a given vulnerability, or an identical control technology with asset context for a given misconfiguration.

Without deduplication, one vulnerability generates a separate console record for every tool that happens to see it. Deduplication reconciles those overlapping detections into a single, trustworthy finding while keeping genuinely distinct installations apart.

Why Deduplication and Merge Matter

Your environment is typically covered by more than one source of truth — for example, Qualys VMDR, CrowdStrike, Microsoft Defender, and Tenable may all scan the same asset. If each source's record were kept separately, the same vulnerability or misconfiguration could appear several times in your findings list. That inflates your counts, makes prioritization harder, and can hide whether an issue is actually resolved because one source says "fixed" while another still reports it as active.

Deduplication and merge solve this by:

• Recognizing when two or more incoming records describe the same finding on the same asset
• Combining those records into a single consolidated finding
• Keeping the most complete and most trustworthy details from all contributing sources
• Preserving a link back to every contributing source record, so you can still trace a consolidated finding to each console it came from

How ETM Handles Duplicates

Deduplication works in three stages:

Stage	What Happens
Identify	Incoming records are matched against existing findings on the same asset using identification attributes such as CVE ID, port, protocol, and title. Each finding is uniquely recognized and duplicates are flagged.
Merge	Identified duplicates are consolidated into a single aggregated record. Attribute conflicts are resolved by precedence — most recent data, highest severity, or most trusted source.
Purge	Outdated or irrelevant findings are removed based on conditions you define, keeping the security posture current.

The result is that duplicate findings are detected and removed, related findings are consolidated into one record, and outdated findings are automatically cleaned up.

AI-Based Findings Consolidation Engine 2.0

The AI-based Findings Consolidation Engine 2.0 uniquely identifies, deduplicates, and normalizes vulnerability data reported across all your connected sources. Instead of one vulnerability generating a separate record for every tool that sees it, the engine reconciles overlapping detections into a single finding while keeping genuinely distinct installations apart.

The engine powers two related capabilities:

• Static consolidation — reconciling the set of records seen today
• Lifecycle-aware consolidation — tracking how a finding's contributors change as new scans arrive over time

AI-based Findings Consolidation Engine 2.0 currently applies to vulnerability findings only. Merge rules for misconfigurations remain unchanged and continue to operate as before.

This capability is being rolled out in a phased manner. Once Consolidation Engine 2.0 is deployed on your platform, the Merge Rules tab no longer lists rules for vulnerabilities. Vulnerability consolidation is handled automatically by the engine. Only misconfiguration merge rules continue to appear in that tab.

Review Duplicate Findings

After ETM consolidates findings, review the consolidated records to confirm that duplicates are merged as you expect and that each finding reflects the current state reported by its sources.

To review the sources of a consolidated finding:

1. Navigate to Risk Management > Findings, and then select the Vulnerabilities or Misconfigurations tab.
2. Select a finding, and then click View Details from the Quick Actions menu.
3. Open the Sources tab. The tab displays the aggregated record and each contributing source record, including the connector name, connector ID, and source asset ID.

When you review a consolidated finding, check the following details:

• Contributing sources: Confirm that every source that detected the issue on the asset is listed.
• Status of each source: Compare the status that each source reports. A difference between sources can explain why the finding is active, fixed, or reopened.
• Detection dates: Compare the first-found and last-found dates of each source to identify which source scanned the asset most recently.

To review findings from a specific source, use the finding.vendorProductName token. For example, finding.vendorProductName: VMDR displays the findings that VMDR reports.

If findings are not consolidated as you expect, review the following causes:

Observation	Possible Cause	What to Do
The same issue appears as separate findings for what is the same asset.	ETM did not correlate the source records into a single asset, so the findings belong to different asset records.	Review the asset identification rules. For more information, refer to Asset Identification Rules.
The same issue appears as separate findings on one asset.	The records differ in an identification attribute, such as the port, protocol, or title, so ETM treats them as distinct findings.	Compare the identification attributes on the Sources tab. Distinct installations are expected to remain separate.
A misconfiguration finding displays attribute values from an unexpected source.	The merge configuration resolves conflicts in favor of a different source.	Review the source trust ranking and custom merge settings. For more information, refer to Merge Rules.

For vulnerability findings, the AI-based Findings Consolidation Engine 2.0 handles consolidation automatically after it is deployed on your platform. Merge rule settings apply to misconfiguration findings.

Handle Reopened Findings

A finding is reopened when a source detects it again after it was fixed. ETM sets the status of the finding to REOPENED, and the finding becomes active again.

A finding can be reopened for several reasons:

• The remediation was incomplete, or a change, such as a rollback or a reimage, reintroduced the vulnerability.
• A source that did not scan the asset before the fix scans it again and still detects the issue.
• A source reports a newer detection than the source that reported the fix.

To find reopened findings, use the following tokens:

• finding.status: REOPENED displays all findings that are currently reopened.
• finding.reopenedDate: [now-2w .. now-1s] displays the findings that were reopened in the last two weeks.

To handle a reopened finding:

1. Open the finding details, and then review the Sources tab to identify the source that detected the finding again and the date of the detection.
2. Confirm with the asset owner whether the issue is present on the asset.
3. If the issue is present, remediate it again, and then validate the remediation. For more information, refer to Remediation Validation.
4. If the detection comes from outdated third-party data, review the purge rules that remove stale findings. For more information, refer to Create Findings Purge Rules.

Track reopened findings regularly. Findings that reopen repeatedly can indicate a gap in the remediation or change management process.

Handle Resolved Findings

A vulnerability finding is resolved when its status is FIXED. A misconfiguration finding is resolved when its control check returns PASS.

For a consolidated finding, ETM determines the status from the contributing source records. For example, the merge configuration can use the status of the record with the latest last-found date. In the following example, two sources report the same CVE on the same asset:

Source	Last Scan Date	Status Reported
Source T	March 8	Fixed
Source V	March 5	Open

Source T scanned the asset most recently, so the consolidated finding displays the status Fixed. If Source V detects the issue in a later scan, the finding is reopened.

To find resolved findings, use the following tokens:

• finding.status: Fixed displays the vulnerabilities that were fixed in the last 365 days.
• finding.lastFixedDate: [0..30] displays the findings that were last fixed in the last 30 days.

To confirm that a finding is resolved:

1. Review the Sources tab to confirm that the latest scan from each source no longer detects the issue.
2. Validate the remediation if required. For more information, refer to Remediation Validation.
3. Measure the effect of the remediation on risk. For more information, refer to Measure Risk Reduction After Remediation.

Keep the following points in mind:

• Manual closure: You can close a finding manually only when its single source is Generic CSV. Findings that have multiple sources, such as CSV and VMDR, close when their sources report them as fixed. For more information, refer to Manage Lifecycle State of Important Vulnerabilities Ingested via CSV.
• Risk acceptance and false positives: A finding that you mark as risk accepted or false positive is excluded from the TruRisk calculation but is not fixed. For more information, refer to Exceptions and Risk Acceptance.

Related Topics

Understand Findings

Correlate Findings

Merge Rules

Create Findings Purge Rules

Search Tokens for Findings