Asset Model

hxEASM keeps Scope and Asset as separate domain concepts.

Scope is customer-provided scan/discovery input and configuration. The existing scopes table, approval workflow, and scope APIs remain intact; the former URL scope type is now named webapp.

Asset is an observed or managed attack-surface entity that belongs to an organization.

Canonical Asset Types

Canonical Asset types are exactly:

Type	Meaning
`organization`	System-managed organization root Asset
`domain`	Registered/root domain observed for the organization
`subdomain`	Hostname under a domain
`ip`	Observed IP address
`service`	Network service represented as `host:port/protocol`
`webapp`	HTTP(S) origin, represented as `scheme://host[:non-default-port]`
`certificate`	TLS certificate identified by SHA-256 fingerprint

The organization Asset is created automatically for each organization. Its stable identity is organization:<organization_uuid> in normalized_value; its display value follows the organization name. It is hidden from normal inventory and dashboard counts, but it is the Asset Graph root and can be used as a fallback association for organization-level Threats.

Scopes

Scopes remain the authoritative model for scan input. Scope types may still include values that are not canonical Asset types, such as cidr, ip_range, asn, and org_name. HTTP(S) scope input uses webapp, not url.

Domain and IP can exist as both Scope records and Asset records. The Scope record represents customer intent/input; the Asset record represents observed attack-surface state.

ip_range Scope records are stored as a single approved scope value such as 10.0.0.1-10.0.0.254. At scan execution time, the worker expands valid IPv4 ranges into individual ip plugin targets. It does not create IP Assets, does not create additional Scope rows, and does not alter CIDR behavior. CIDR scopes remain CIDR inputs. The runtime expansion limit is 65,536 IPs per range and 65,536 unique expanded IP range targets per scan.

Removed Asset Types

The following are no longer canonical Assets:

Old type	New representation
`url`	Replaced by `webapp`; new create/restore paths must use `webapp` directly
`path`	`webapp.metadata.web.paths` where a parent WebApp is known
`parameter`	`webapp.metadata.web.parameters` where a parent WebApp is known
`technology`	`service.metadata.technologies` or `webapp.metadata.web.technologies`
`port`	Folded into `service` values and metadata
`cidr`	Scope/configuration or intermediate discovery context
`ip_range`	Scope/configuration or intermediate discovery context
`asn`	Scope/configuration or intermediate discovery context

New production code must not emit removed Asset types. Old backup imports that contain removed Asset types are rejected instead of silently reintroducing obsolete inventory.

Identity Rules

Type	Identity
`organization`	`organization:<organization_uuid>`
`domain`	normalized FQDN
`subdomain`	normalized FQDN
`ip`	canonical IP address
`service`	host or IP + port + protocol, for example `203.0.113.10:443/tcp`
`webapp`	scheme + normalized hostname + effective non-default port
`certificate`	SHA-256 certificate fingerprint

WebApp is an origin, not a page. For example https://example.com, https://example.com/, https://example.com:443, and https://example.com/admin?id=1 all identify the same WebApp Asset: https://example.com. The path /admin and parameter id belong under metadata.web.

Graph Model

The canonical graph is rooted at the Organization Asset:

Organization
  |
 owns
  v
Domain
  |
 contains
  v
Subdomain
  |
 resolves_to
  v
IP
  |
 exposes
  v
Service
  |
 serves
  v
WebApp
  |
 has_certificate
  v
Certificate

Paths, parameters, technologies, CIDRs, ASNs, IP ranges, and standalone ports are not normal graph nodes.

Threats are not Asset Graph nodes. The Threat types remain vulnerability, data_leak, misconfiguration, phishing, and employee; vulnerability is never an Asset type.

Threat Association

Every Threat has an Asset association. A specific affected Asset is preferred. Organization-level Threats such as employee exposure, broad phishing, or data leaks can use the Organization Asset as a fallback when there is no more specific infrastructure Asset.

Future Asset History Hook

Richer scanner-driven change history should hook into the Asset upsert/metadata merge path, after canonical identity resolution and before metadata persistence. That is the right point to compare previous metadata with normalized incoming metadata for events such as WebApp path changes, technology changes, certificate renewal, service fingerprint changes, or rediscovery.