Resolve Asset Conflicts

When multiple discovery sources detect the same infrastructure resource, AttackLens creates an asset conflict. The conflicts page helps you identify and resolve these duplicates to maintain a clean, accurate asset inventory.

INFO

Requires Posture Manager role or higher.

What Is an Asset Conflict?

A conflict occurs when two or more asset records share the same identifier type and normalized value. AttackLens automatically detects this overlap and flags it for manual resolution.

Common Conflict Scenarios

Scenario	Example
Sensor + Adapter overlap	A sensor enrolled on a VM reports hostname web-01. The Azure adapter also discovers the same VM with the same hostname. Two asset records exist for one machine.
Multi-adapter overlap	A resource is visible in two AWS regions or two subscriptions, and both adapters create an asset with the same Cloud Resource ID.
Manual + automatic overlap	An administrator manually creates an asset with IP 10.0.1.25. Later, an adapter discovers the same machine and creates a second asset with the same IP.
Re-provisioned machines	A machine is decommissioned and a new one is provisioned with the same hostname, causing a conflict with the old asset record.

TIP

Conflicts are not errors. They are a normal part of operating a multi-source discovery system. The goal is to resolve them so each real-world resource has exactly one asset record.

Viewing Conflicts

Navigate to Assets > Asset Conflicts in the sidebar to see the conflicts list.

The table displays:

Column	Description
Identifier Type	The type of identifier that triggered the conflict (e.g., Hostname, IPv4 Address)
Normalized Value	The shared identifier value (e.g., web-01, 10.0.1.25)
Candidate Count	The number of asset records involved in the conflict
Status	Current conflict state: Pending, Resolved, or Ignored
Resolved By	The user who resolved the conflict (if applicable)
Resolved At	When the conflict was resolved (if applicable)
Created	When the conflict was first detected

Filtering by Status

Use the status filter to focus on specific conflict states:

• Pending: Conflicts that need your attention
• Resolved: Conflicts that have been resolved via merge
• Ignored: Conflicts that were dismissed without merging

Conflict Detail Page

Click on a conflict row to open the detail page, which shows:

Conflict Information

• Identifier Type: The type of the overlapping identifier
• Normalized Value: The shared identifier value
• Status: Current state with a color-coded badge (yellow = Pending, green = Resolved, gray = Ignored)
• Detected At: When the conflict was first identified
• Resolved At / Resolved By: Resolution metadata (shown only for resolved/ignored conflicts)
• Resolution: The method used to resolve (Merge, Ignore, or Split)
• Survivor Asset: Link to the asset that survived the merge (shown only after a merge resolution)

Candidate Assets

Below the conflict information, you will see a list of candidate assets: the asset records involved in the conflict. For each candidate:

• Name (clickable link to the asset detail page)
• Platform (e.g., Linux, Windows)
• Environment (Dev, Test, Staging, Prod)
• Agent: Whether a sensor is bound to this asset
• Identifiers: The full list of identifiers on this candidate

This side-by-side view lets you compare the candidates and decide which one to keep.

Resolving a Conflict

Click the Resolve button (visible only for Pending conflicts) to open the resolution dialog.

Step 1: Choose a Resolution Strategy

Strategy	Description
Merge	Combine the candidate assets into a single record. You choose which asset survives; the others are absorbed.
Ignore	Dismiss the conflict without taking action. The assets remain separate. Use this when the assets are genuinely different resources that happen to share an identifier.

Step 2: Select the Survivor (Merge Only)

If you choose Merge, select the Survivor Asset from the dropdown. The survivor is the asset record that will be kept. All other candidate assets are absorbed into it.

Step 3: Preview the Merge (Optional)

Before confirming, click Preview Merge on any candidate to see what the merged result will look like:

• Survivor Asset: The asset that will remain
• Merge Assets: The assets that will be absorbed
• Estimated Identifiers Count: How many identifiers the merged asset will have (union of all candidates' identifiers)
• Estimated Policies Count: How many policy assignments will carry over

TIP

Choose the survivor based on which asset record has the most complete data. If one asset was created by an adapter with rich cloud metadata and the other was manually created, prefer the adapter-created one as the survivor.

Step 4: Confirm

Click Resolve to execute the resolution. For merge:

1. The survivor asset absorbs identifiers from all other candidates (union, no duplicates)
2. Policy assignments from absorbed assets transfer to the survivor
3. Absorbed assets are set to Merged status
4. The conflict status changes to Resolved

What Happens After Merging

Data	Behavior
Survivor asset	Gains all unique identifiers from absorbed assets; remains Active
Absorbed assets	Status set to Merged; retained for audit trail but hidden from active views
Findings	Findings from absorbed assets are reassociated to the survivor
Vulnerabilities	Vulnerability findings are reassociated to the survivor
Sensor binding	If an absorbed asset had a bound sensor, the sensor is rebound to the survivor
Group membership	The survivor retains its group; absorbed assets' group memberships are cleared
Conflict record	Updated with resolution details (strategy, survivor, resolved by, timestamp)

WARNING

Merging is permanent. Absorbed assets cannot be unmerged. If you are unsure whether two assets represent the same resource, use Ignore to dismiss the conflict without taking destructive action. You can always revisit ignored conflicts later.

What Happens After Ignoring

• The conflict status changes to Ignored
• Both assets remain as separate, independent records
• No data is moved or modified
• The same conflict will not be re-created unless the assets' identifiers change

Preventing Conflicts

While conflicts are normal in multi-source environments, you can reduce their frequency:

• Use consistent naming: Ensure hostnames and FQDN values are consistent across your infrastructure
• Avoid duplicate manual assets: Before creating an asset manually, check if an adapter or sensor has already discovered it
• Clean up stale assets: Delete or deactivate assets for decommissioned resources so they do not conflict with new provisioned machines

Related

• Understanding Assets -- Asset identifiers and lifecycle
• Manage Assets -- Search and filter the asset list
• Delete an Asset -- Remove assets instead of merging