Vulnerability management breaks when every tool names the asset differently

Open the Wednesday remediation queue and count how often the same box shows up. The Windows subnet scanner returns 10.42.11.108, the cloud inventory has it as i-0a3fb2c8e1d5a4197, EDR calls it a device ID, the CMDB a configuration item, the SBOM pipeline an image digest, the Kubernetes API a pod UID. Five tickets, one machine, and the on call team learns to close three of them without reading the details because the queue keeps lying about how many things there are. That is where most vulnerability programs actually break, and it is not a scanner problem. Every source of truth in the stack invented its own asset key, and until those keys are joined by explicit rules the exposure picture is a pile of near duplicates the queue can never fully trust.

The category being absorbed, and the work still on the table

Naming prior art first, because plenty of it is real. Cyber Asset Attack Surface Management (CAASM) existed as a category for years, with Axonius, Armis, Qualys CSAM, and JupiterOne all shipping products that pulled connectors, deduped assets, and drew a graph. Gartner then called CAASM and EASM "obsolete before plateau" on the 2025 SecOps Hype Cycle and rolled the discipline into the first Exposure Assessment Platform Magic Quadrant. Consolidation kept moving through 2026: Arctic Wolf acquired Sevco in February 2026, and Tenable had already absorbed Vulcan a year earlier. Asset joining is a feature of exposure platforms now, not a standalone product.

Underneath the category name the precedent is older. ServiceNow shipped its Identification and Reconciliation Engine (IRE) to keep the CMDB from splitting one server into three CIs, with precedence and merge rules baked in. Cartography, the CNCF project originally released by Lyft, is the open source asset graph that draws AWS, GCP, and identity relationships in Neo4j. On the scoring side, Tenable's Asset Criticality Rating pairs with VPR and Qualys TruRisk ACS weights the final score. Even the phrase "identity graph" we borrow from martech, where entity resolution over people, cookies, and devices has been patented for years in filings like US10848516.

What is still on the table is narrow. First, no open specification exists for asset identity keys, merge precedence, or identity confidence the way OCSF gave the industry a shared shape for detection data; every vendor's join logic is proprietary. Second, the gap between a CMDB IRE and a CAASM platform has never been written as a practitioner blueprint, so teams either buy a product or wire a graph without a reference. Third, resolution confidence, meaning how sure the graph is that two identifiers describe the same asset, is not a first class scoring input in any shipping product we can find, even though ambiguity is the condition that ruins prioritization.

Identity as a graph, not a schema

Stop forcing every source into one flat asset row and instead model identity as relationships between identifiers. A hostname resolves to an IP for a window, an instance runs an image at a moment in time, an image contains packages by digest, and a package produces findings against a CVE. Above that, an application depends on one or more instances, a business process owns an application, and a person owns the business process. Every question a remediation team actually asks lives on one of those edges: which business service is affected, who gets the ticket, is this the same host after last night's autoscale, is this package running in production or only baked into a build image nobody ships.

Durable identifiers, everything else as observation

Not every identifier deserves the same trust. Cloud instance IDs, image digests, Package URLs, Kubernetes UIDs, EDR agent IDs, and CMDB CIs are durable, in the sense that the platform issuing them treats them as primary keys and does not reuse them casually. Hostnames, IPs, MAC addresses, and DNS names are mutable, and in cloud and container environments they rotate on a schedule scanners rarely track.

The rule the graph enforces is that durable identifiers own identity and mutable ones are observations attached to it. Two observations of the same IP on different days are not evidence of the same asset; two runs of the same image digest are. That inversion alone kills the loudest class of false duplicates.

A minimum viable graph in five nodes

You do not need a full enterprise ontology to earn trust back. Five node types is enough:

• Asset. The durable identity of a host, workload, or device.
• Application. The deployable unit an asset participates in.
• Package. The software component an asset or application carries, keyed by purl or digest.
• Finding. A vulnerability, misconfiguration, or exposure observed against an asset or a package.
• Owner. The business owner and technical owner tied to an application or asset.

Six edges connect them: asset runs application, application uses package, package has finding, asset has finding, application owned by owner, asset placed in network zone. That is the shape a vulnerability program needs to answer who fixes this, where does it actually run, is it a duplicate, and does anyone still care, without inventing a new data model per source.

Merge rules, decay, and conflict

Merge logic is where CAASM platforms earn their license and where homegrown graphs quietly rot. Three moves carry the weight.

Precedence. Declare a total order over the identifier types you consume so a conflict has an answer. Cloud instance ID beats hostname, hostname beats IP, and the newest EDR device ID for a given cloud instance wins over an older one. Check that order into version control the same way you would a firewall policy; the moment it lives in someone's head it is already drifting.

Decay. Every observation carries a last seen timestamp, and the merge engine has to distrust identifiers that have not been observed inside a window you set per source. A hostname the DNS resolver has not returned for thirty days is not the same signal as one that answered this morning; treating them the same is how retired hosts end up on the crown jewel report.

Conflict handling. When two durable identifiers disagree, the graph does not silently pick one. It emits a conflict node and lowers the resolution confidence for both. The remediation queue then treats findings against a conflicted identity differently, which is where scoring comes in.

Confidence as a scoring input

TRIS style scoring already respects business criticality, and Tenable ACR and Qualys ACS both weight asset value into the final score. What we have not seen anywhere is identity resolution confidence as a first class scoring input. If the graph is ninety eight percent certain a finding is attached to a production crown jewel, the score reflects that. When the graph is fifty percent certain because the IP drifted, the hostname was reused, and the last EDR heartbeat was nine days ago, the score should be discounted rather than pretend the ambiguity is not there. Confidence is the knob that keeps the queue honest under real world drift.

Seven failure modes worth designing against

1. Treating the CMDB as ground truth. It is a system of record, not observation, and its freshness depends on humans updating it.
2. Deduping by IP only. Cloud reuses IPs by the minute; hostnames rotate on redeploy.
3. Ignoring ephemeral workloads. Serverless functions and short lived pods produce findings that never map back to an asset.
4. Losing application ownership. If the graph knows a finding but not who owns the application, mobilization stalls at triage.
5. Keeping retired assets in SLA reports. Nothing tanks executive trust faster than a critical against a decommissioned host.
6. Treating scanner output as inventory. A scanner sees what it can reach, not what exists.
7. Skipping the SBOM to runtime link. A vulnerable package in a build image nothing runs is not the same exposure as one in a live pod, and the graph is the only place that link honestly lives.

What a team can build this quarter

Starting from a spreadsheet inventory, a team can be usefully further along in ninety days. Draw the five node types on a whiteboard and pick a durable identifier key for each. Import the two sources you trust most into a graph store, whether Neo4j, DuckDB with recursive CTEs, or Postgres with edges as rows. Put precedence order and per source decay windows into config so the rules can change without a deploy. Wire one downstream (the remediation queue or the score) to read from the graph instead of raw scanner output. Interesting ambiguities show up the day you turn it on, and the graph becomes the first place in the program where you can honestly measure how much of the exposure picture you trust. Our local-first CTEM architecture from last week assumes exactly this identity layer underneath it.

CVEasy is built with the identity graph as the spine, and TRIS uses resolution confidence as a scoring input so ambiguous identities cannot drown out the ones a team can actually act on.