Skip to main content

Grouping & Deduplication

Vulnerability scanners can generate large numbers of findings, including repeated or related findings for the same assets and software.

Cloudaware offers configurable deduplication so that you select how related vulnerability findings are grouped during collection.

What Can Be Grouped​

Depending on the deduplication strategy, Cloudaware can combine findings that share a CVE, affect the same application, or require the same remediation.

For cross-source analysis, findings can also be treated as a single logical issue when they represent:

  • The same vulnerability, such as a CVE, on the same asset.
  • The same misconfiguration on a resource, even when reported by multiple scanners.

Cloudaware Vulnerability Management uses:

  • Record types to distinguish sources such as Qualys, Rapid7, Tenable, and cloud-native scanners.
  • Asset and CVE fields to group findings across sources.

Configure Vulnerability Deduplication​

For supported integrations, such as CrowdStrike and Orca Security, you can enable vulnerability deduplication and select a deduplication strategy in the integration configuration.

The selected strategy determines how Cloudaware deduplicates related source findings during collection. Findings that match the selected grouping criteria are combined into a single vulnerability record. Findings that do not match other findings remain as individual records.

Available deduplication strategies include:

  • By Affected Software — Groups findings that affect the same application, software, library, etc.
  • By Remediation — Groups findings with the same remediation guidance.
  • By Affected Software and Remediation — Groups findings only when both the affected software and remediation match.
  • By CVE — Groups findings associated with the same CVE.
tip

For most environments, Cloudaware recommends By Affected Software as the most effective deduplication strategy. It groups vulnerability findings for the same application (e.g., on each CrowdStrike host), typically reducing the record volume more than other strategies.

note

After changing the deduplication strategy, you must wait 7 days before changing it again.

Example​

Assume a host has the following vulnerability findings:

Affected SoftwareCVERemediation
App ACVE-1Upgrade the application
App ACVE-2Upgrade the application
App BCVE-2Upgrade the application

The resulting vulnerability records depend on the selected deduplication strategy:

  • By Affected Software: Cloudaware creates one record for App A containing CVE-1 and CVE-2, and another record for App B containing CVE-2.
  • By Remediation: Cloudaware creates one record because all three findings have the same remediation guidance.
  • By Affected Software and Remediation: Cloudaware creates one record for App A with the shared remediation and another for App B with the same remediation.
  • By CVE: Cloudaware creates one record for CVE-1 and another for CVE-2. The CVE-2 record includes both affected applications.

For example, if ten source findings are collected and seven of them match the selected grouping criteria, Cloudaware can combine those seven findings into one grouped record. The remaining three findings stay as individual records, resulting in four vulnerability records instead of ten.

Vulnerability Deduplication Strategy

Reporting and Analysis Patterns​

After collection, you can also organize vulnerability data using grouping patterns such as:

  • CVE + Asset — One logical finding per CVE and asset.
  • Rule/Check ID + Asset — Useful for configuration or policy checks.
  • Package + Version + Asset — Useful for package-centric analysis.

These groupings can be implemented using summary objects, roll-ups, custom list views, and reports.

Cross-Source Deduplication​

When multiple scanners report the same logical issue:

  • Prefer a single canonical record for routing and SLA purposes, with other records treated as supporting evidence.
  • Use source-specific fields to investigate discrepancies, such as when one scanner reports an issue that another does not.
  • Keep source data available for investigation and validation, even when individual scanner records are not used in day-to-day operational views.

Impact on Workflows​

Grouping and deduplication can affect how vulnerability data is used downstream:

  • Remediation Tasks — Scope tasks around logical issues, such as fixing an OpenSSL vulnerability on a group of affected servers, rather than individual scan hits.
  • Dashboards — Use counts of unique findings rather than raw scanner records to avoid overstating vulnerability volume.
  • SLAs — Track age and deadlines at the grouped-finding level.

For details on how grouped findings translate into tasks and escalations, see Vulnerability Management Processes.

On this page