Most vulnerability management programs are judged by their finding counts. The dashboard shows thousands of open issues, a few of them critical, and the team spends its week arguing about which ones to fix first. That argument is usually unwinnable, because it skips a question that comes before any finding exists. What are you actually defending, and how confident are you that you can see all of it?
Attack surface management starts with that question. Before a single scan runs, before a single finding is triaged, you need a trustworthy record of every asset in your environment and a way to reason about which assets matter. A finding is only as meaningful as the asset it lives on. A critical vulnerability on a decommissioned test box is noise. The same vulnerability on an internet-facing payment gateway is an incident waiting to happen. The difference between the two is not in the finding. It is in the asset.
This guide treats asset inventory as the load-bearing foundation of a vulnerability program rather than a side table. It walks through how a defensible inventory gets built from many sources, how identifiers like IP addresses and hostnames are kept clean, how scanner signals enrich an asset without corrupting it, how ownership is resolved so that findings reach a human, how static and dynamic groups turn inventory into a targeting layer, how risk scoring ranks assets by real exposure, and how scan coverage proves that what you think you are scanning is actually being scanned. Every behavior described here reflects how PMAP models an asset, because an attack surface story is only useful if the platform behind it behaves the way the story claims.
If you are building or rebuilding a vulnerability management program, read this as the chapter that comes before triage. The rest of your program inherits whatever quality you establish here.
Why Asset Inventory Is the Foundation of Vulnerability Management
The asset inventory is the inventory backbone of a vulnerability program. In PMAP an asset is any manageable entity in a customer environment. That includes servers, workstations, network devices, cloud instances, applications, source-code repositories, databases, and IoT or SCADA devices. The list is deliberately broad, because modern attack surface is broad. The repository holding your build pipeline is an asset in the same sense that a domain controller is, and both can carry findings.
The reason inventory sits underneath everything is structural rather than philosophical. Every finding, every scan, and every risk score in PMAP ultimately resolves to an asset. A finding references the asset it was observed on. A scan imports findings and attributes them to assets. Analytics and reporting read asset data to produce the rankings leadership cares about. The asset domain sits upstream of findings, scans, integrations, reporting, and analytics, and downstream of the company tenant root, the license quota, and the teams and users who own work. If the asset layer is wrong, every layer above it inherits the error.
This is also where security frameworks place inventory. CIS Controls v8 makes inventory and control of enterprise assets its very first control, ahead of vulnerability management itself, precisely because you cannot defend what you cannot enumerate. NIST SP 800-53 treats the system component inventory under control CM-8 as a baseline requirement. The OWASP Attack Surface Analysis Cheat Sheet frames the same idea for applications, where the surface is the sum of entry points an attacker can reach. The common thread is that inventory is not preparatory work you finish and forget. It is a control you operate continuously, and a vulnerability program is only as honest as the inventory it stands on.
The rest of this article follows the work of turning a raw list of machines into that honest foundation. PMAP organizes vulnerability work around four motions. Findings are ingested, correlated, triaged, and remediated. Asset inventory lives at the very start of ingest, because a finding cannot be ingested without an asset to attach it to. Each section below describes a piece of inventory behavior you can verify rather than aspiration.
Building Inventory From Many Sources
No single source knows about every asset you own. The cloud console knows about your instances. The CMDB knows about your sanctioned infrastructure. Your network scanner discovers hosts that nobody registered. Your code platform knows about your repositories. A real inventory is the reconciliation of all of these, and the asset domain is built to absorb them without turning into a pile of duplicates.
There are three practical ways assets enter PMAP, and they coexist by design. The first is manual creation, where an engineer authors a single asset with its type, class, criticality, and type-specific detail. The second is bulk import, which is how most inventories actually get loaded. The bulk create endpoint accepts up to five thousand assets in a single request, and an optional NDJSON streaming mode flushes a live progress event for each row so an operator can watch a large import advance instead of staring at a frozen spinner. Crucially, per-row failures are collected rather than aborting the whole batch, so one malformed record does not sink an import of thousands. The third path is scanner-driven creation, where importing a scan populates assets automatically as findings arrive, so an asset that a scanner sees becomes an asset you can manage.
The hard part of multi-source ingest is not loading data. It is loading data twice without noticing. PMAP handles this at the point of creation with explicit duplicate resolution. On create, the service matches an incoming asset against the existing inventory by name and by each IP address within the same company. The outcome is controlled by a dup_action parameter. The default behavior rejects a duplicate with a clear conflict response, so nothing silently overwrites. Setting the action to skip returns the existing asset untouched, which is the safe choice for a re-run of the same import. Setting the action to update merges the new metadata into the existing asset, unions its tags, and adds any new IP addresses. This gives an integration a deterministic way to keep an asset current across repeated syncs rather than spawning a new row every time.
There is also a guard for the genuinely ambiguous case. If the incoming name matches one existing asset and the incoming IP matches a different existing asset, the service refuses to guess and returns an ambiguous-match error instead of merging two distinct machines into one. That refusal is a feature. Quietly collapsing two assets is exactly the kind of inventory corruption that surfaces months later as a finding attributed to the wrong system.
CMDB reconciliation deserves a specific mention, because it is where many programs try and fail to keep inventory honest. PMAP supports CMDB-style ingest through the same bulk create path, and connectors that push asset inventory use the update action to reconcile rather than re-create. The result is a single inventory that absorbs the CMDB as a source of record without being held hostage to it. When the CMDB is missing a host that a scanner discovered, the discovered asset still exists and still carries its findings. When the CMDB and a scanner disagree, the inventory has rules for which one wins, and those rules are covered in the enrichment section below.
IP, CIDR and Hostname Canonicalization
Identifiers are where inventories quietly rot. The same machine can be written as 10.10.235.181 in one tool, 010.010.235.181 in another, and reached by a hostname in a third. If your inventory treats those as different strings, you get duplicate assets, missed correlations, and findings that scatter across phantom records. Clean identifiers are not a cosmetic concern. They are the difference between an inventory you can join on and one you cannot.
PMAP manages IP addresses as a first-class sub-resource on each asset rather than a single text field. An asset can carry multiple IP addresses, each stored in canonical inet form. A dedup check across the company prevents the same IP from belonging to two assets at once, which keeps the network-to-asset mapping unambiguous. That one-IP-one-asset invariant is what lets a scan result that arrives keyed on an IP land on exactly the right asset.
The canonicalization itself runs before any comparison touches the database. When an exact search comes in, the handler normalizes IPs to their canonical form, stripping IPv4 leading zeros and IPv6 zone identifiers, and normalizes internationalized hostnames to lowercase punycode. This matters because naive substring matching produces false positives that are hard to spot. Without canonicalization, an ILIKE query for 10.10.235.181 can match 10.250.235.181 and quietly pull in the wrong asset. By reducing both the query and the stored value to a canonical representation first, the platform compares apples to apples and eliminates that class of error.
CIDR ranges enter the picture when you reason about networks rather than single hosts. PMAP supports CIDR-based selection through dynamic group rules, where a rule can match any asset whose IP address falls inside a given CIDR block. That capability is covered in detail when we reach asset groups, but it depends entirely on the canonicalization described here. You can only ask whether an address falls inside a range if every address is stored in a form that the range operator understands. Canonical identifiers are the unglamorous plumbing that makes everything downstream, from correlation to grouping to coverage, actually work.
Asset Enrichment From Scanner Signals
A freshly created asset is often a thin record. It might be little more than a name and an IP address. The detail that makes it useful for triage, such as which ports are open, which services are running, which operating system it runs, and which software is installed, usually arrives later from a scanner. Enrichment is the controlled process of folding those scanner signals into the asset without letting automated data trample what a human already knows.
In PMAP, enrichment is a sub-domain dedicated to exactly this problem. When a scanner reports details about a host, the enrichment merger silently folds open ports, services, technologies, software, operating system details, hostname, fully qualified domain name, and MAC address into the asset’s structured type_data. The word silent is intentional. Enrichment runs during ingestion, called internally by the scanner integrations rather than as a manual step, so an asset gets richer every time it is scanned without anyone curating it by hand.
The discipline that makes this safe is source precedence. Not every source is equally trustworthy, so enrichment enforces a strict priority order. Manual input outranks a rule, which outranks a runbook, which outranks a scanner, which outranks an import. The practical effect is that a scanner can never overwrite a field a human set manually, unless that field is explicitly unlocked. If you have hand-verified that a host is a production database, a scanner that misidentifies it does not get to relabel it. Precedence turns enrichment from a risky free-for-all into a layered system where the most authoritative source wins.
There is a deliberate boundary on what enrichment is even allowed to touch. Only a small, fixed set of field paths can be written by the merger. Those are open ports, services, technologies, software, operating system details, hostname, FQDN, and MAC. Any enrichment record that targets a path outside that allowlist is rejected at merge time. This is a containment decision. Enrichment is powerful precisely because it is automatic, and an automatic process that can write anywhere is a liability. Restricting it to a known set of technical fields means a scanner can flesh out an asset’s technical profile while staying away from the fields that define ownership, criticality, and tenancy.
When a scanner reports something that conflicts with a higher-precedence value rather than simply adding new detail, the merger does not silently pick a winner. It records the write with a conflict-pending outcome and leaves it for an administrator to review. No silent overwrites is the governing principle. The system would rather flag a disagreement than resolve it incorrectly, because an inventory that quietly drifts is worse than one that asks for a decision.
Field-Level Locking and Enrichment Audit
Source precedence answers which source should win in general. Field-level locking answers what to do when you want a specific value frozen regardless of what any scanner reports. Because enrichment operates at the level of individual fields, a field that has been set authoritatively stays protected until it is explicitly unlocked. That granularity is what lets a team trust automation. You can let scanners enrich freely while pinning the handful of fields you have verified by hand.
Every enrichment write is also accountable. The platform keeps a per-field audit log, and each write records its outcome as one of a fixed set of results. A write is recorded as applied when it lands, skipped because of a lock when precedence or locking blocked it, conflict-pending when it disagreed with a higher source, a user override when a human’s value held, or a no-op when the value was already current. An admin-only history endpoint exposes this per-field provenance for compliance review, so when an auditor asks why an asset records a particular operating system, there is a literal answer that names the source and the moment it was written. Enrichment that you cannot audit is enrichment you cannot defend. Recording every write and its outcome turns a black box into evidence.
Ownership: Users, Teams and Resolution
An asset that nobody owns is an asset whose findings nobody fixes. Ownership is the bridge between inventory and accountability, because it determines who gets notified when a vulnerability lands and who is on the hook to remediate it. PMAP treats ownership as a structured, polymorphic relationship rather than a single name field, which is what lets it model the messy reality of how organizations actually divide responsibility.
Each asset can carry multiple owners, and an owner can be either a user or a team. Every ownership binding records a role, drawn from owner, custodian, and approver, and a notify flag that controls whether that binding receives notifications. A team can own an asset while a specific individual is named custodian, and an approver can be attached without being paged on every finding. The notify flag is a precision tool. Setting it false silences notifications for a binding without removing the ownership record, so you can keep an accountable owner on the books while routing the actual alerts elsewhere. For sort and filter purposes, a denormalized primary owner is also kept on the asset, which preserves fast list operations while the full polymorphic ownership lives alongside it.
The part that makes ownership operational is resolution. When a new finding appears on an asset, the platform needs to decide who should be notified and pre-populated as the assignee. An owner resolver handles this, and it is exposed as a dry-run endpoint that the finding-create form calls to pre-fill the assignee picker. The resolver walks a multi-strategy path. It considers the explicit owner on the asset, then the owner inherited from the asset’s project, then the company default, so a finding on an unowned asset still reaches a sensible human rather than falling into a void. Because the endpoint is a dry run, an operator can see exactly who the resolver would pick before any notification fires, which removes the guesswork from assignment. By default the resolver only considers owners whose notify flag is set, with an option to include muted owners when the full picture is needed.
Resolution is where the foundation pays off most visibly. Clean inventory, accurate ownership, and a deterministic resolver mean a vulnerability that arrives at two in the morning lands in the inbox of someone who can act on it, without a human having to look up who runs which box. For a deeper view of how a resolved owner travels with a finding through triage and remediation, see our pillar on the vulnerability management lifecycle.
Static and Dynamic Asset Groups
Selecting individual assets every time you want to scope a scan, a report, or a dashboard is the kind of repetitive friction that makes a platform feel like work. Asset groups solve this by letting you define a collection once and reference it everywhere. A group is the targeting layer that sits between raw inventory and the operations that act on it, and PMAP supports two fundamentally different kinds.
A static group is hand-picked. Members are added and removed by explicit action, and the membership stays exactly as curated until someone changes it. Static groups suit collections defined by human judgment rather than a queryable property, such as the assets in scope for a specific engagement or a watchlist a team maintains by hand. Bulk member addition keeps static groups practical at scale, attaching up to five thousand assets to a group in a single call, with already-present members silently skipped so a re-run is safe.
A dynamic group is rule-driven, and this is where grouping becomes a living view of the attack surface. Instead of a fixed member list, a dynamic group stores a rule, and that rule is re-evaluated against the inventory every time the group is read. The membership is always current. As assets are created, retired, or re-tagged, a dynamic group’s contents shift to match without anyone touching it. A rule can match on company, asset type, asset class, criticality, location, and tags, where tag matching supports both any-of and all-of semantics. It can also match on a CIDR block, selecting every asset whose IP address falls inside the range, which is the network-level targeting the canonicalization section made possible. A dynamic group of every internet-facing web server, or every production database, or every host in a given subnet, maintains itself.
The behavior that makes dynamic rules trustworthy is preview. Before a rule is ever saved, an operator can submit it to a preview endpoint that evaluates the rule against the live inventory and returns the assets it would match, without creating anything. This closes the loop between intent and result. You can refine a rule, see exactly which assets it captures, and only commit it once the membership looks right. A targeting layer you cannot preview is a targeting layer you cannot trust, because a too-broad rule could quietly pull in assets that should never have been scanned. For a closer look at how groups feed scan targeting and consolidation, see our pillar on multi-vendor scan orchestration.
Asset Risk Scoring Explained
Once inventory is clean and grouped, the next question is which assets deserve attention first. Counting open findings does not answer that. A host with forty informational findings is not riskier than a host with one exploitable critical finding on an internet-facing service. Asset risk scoring exists to turn the raw finding picture into a ranked view of exposure, so that prioritization reflects danger rather than volume.
In PMAP, risk is expressed at the asset level. Each asset carries a risk score and a finding summary that breaks active findings down by severity, from urgent and critical through high, medium, and low. That severity-banded summary is the raw material of scoring. An asset’s risk is a function of the severity and count of the findings it actually carries, which means risk rises as serious findings accumulate and falls as they are remediated. Because the score lives on the asset, the inventory itself becomes sortable by exposure. You can rank your entire attack surface from most to least dangerous and work down that list rather than guessing.
Two asset attributes shape how risk should be read. The first is criticality, a property of the asset that captures how much the business cares about it independent of its current findings. The second is the internal-versus-external distinction, recorded as a flag on every asset. An external, internet-facing asset is reachable by an attacker in a way an internal one is not, and that reachability is exactly what attack surface management is about. The same vulnerability carries different real-world risk depending on whether the asset sits behind the perimeter or in front of it. Keeping criticality and the internal flag as first-class fields lets risk be understood in context rather than as a raw number.
It is worth being precise about scope here. This article covers asset-level risk, the score that ranks individual machines so you know where to start. Program-level and board-level risk reporting, where asset scores roll up into organizational rankings and trends for leadership, is a distinct concern with its own treatment. The asset-level foundation described here is what those higher views are built from, but the rollup, the trend lines, and the executive narrative belong to the analytics and reporting layer rather than the inventory.
Scan Coverage and the Wave Matrix
A clean, owned, risk-scored inventory still has a blind spot until you can answer one more question. Are these assets actually being scanned, and what has changed each time they were? Coverage is the proof that your attack surface is observed rather than merely listed. An asset you have inventoried but never scanned is a known unknown, and the whole point of foundation work is to eliminate those.
PMAP answers the coverage question at the asset level with two complementary views. Scan coverage is an aggregated view of which integrations and scanners have produced findings for a given asset. It tells you, for any single asset, which tools have actually looked at it. That is the direct answer to whether a host is in your scanning rotation or quietly falling through the cracks. An asset that no integration has ever produced a finding for is a coverage gap you can see and close, rather than a gap you discover during an incident.
The wave matrix goes deeper, into change over time. It is a per-asset cross-tabulation of findings against scan waves. For a single asset, the matrix lays out every finding it has carried across the rows and every scan wave across the columns, and each cell shows that finding’s state in that wave. A finding can be open, closed, reopened, or absent in any given wave. The result is a literal map of how the asset’s exposure evolved scan by scan. You can see a finding appear in one wave, persist through the next, vanish after a remediation, and watch for whether it returns. A finding that closes and then reopens several waves later is a regression the matrix makes obvious, where a flat list of current findings would hide it entirely.
This change-over-time view is what separates a snapshot inventory from a living one. Coverage tells you that an asset is being watched. The wave matrix tells you the story of what that watching has revealed. Scan coverage also appears in the orchestration story from a different angle, where the emphasis is on routing many scanners into one pipeline. Here the lens is the asset, asking what each asset has been subjected to and how its findings moved. The two perspectives complement each other, and the orchestration view is covered in our pillar on multi-vendor scan orchestration.
Faceted Filtering at Inventory Scale
A foundation is only usable if you can navigate it. A real enterprise inventory is not a few hundred neat rows. It is tens of thousands of heterogeneous assets, and finding the right slice of them quickly is a daily operational need. Faceted filtering is what keeps inventory navigable at that scale, turning a wall of assets into a surface you can interrogate.
PMAP exposes a faceted filter sidebar that provides aggregated counts across the dimensions that matter, including asset type, class, environment, criticality, company, internal or external, active or inactive, and whether the asset has findings. The detail that makes faceting genuinely useful is that each facet excludes its own filter when computing counts. That means a multi-select stays coherent. When you select two criticality levels, the criticality counts still show all options rather than collapsing to only what you selected, so you can broaden or narrow without losing your place. Faceting that double-counts its own selection is confusing in exactly the situations where you most need clarity.
Beneath the facets sits a rich filtering surface for precise queries. You can filter on type, class, criticality, tags, environment, open ports, services, operating system family and name, MAC address, and on presence conditions such as has-IP, has-owner, and has-findings, alongside the internal and active flags. Several of these filters reach into the structured type_data and JSONB fields that enrichment populates, so a question like which Linux hosts expose a particular port becomes a direct query rather than a manual hunt. The point is that all the structure built up in earlier sections, the canonical identifiers, the enriched technical profile, the ownership bindings, and the risk summary, becomes searchable here. A foundation you can filter precisely is a foundation that answers questions instead of just storing them. When a filtered view is one you return to often, it can be saved, which keeps a recurring slice of inventory one click away.
Multi-Tenant Scope and Subsidiary Roll-Up
Everything described so far assumes a boundary. In a holding company or a managed security provider, that boundary is everything, because one tenant’s assets must never bleed into another’s view. Multi-tenancy is not a feature bolted onto inventory. It is an invariant that every inventory operation has to honor, and PMAP enforces it at the query level rather than trusting the caller.
Every list, export, and facet query applies a scope filter derived from the authenticated context, so a user only ever sees the assets their tenant allows. Single-asset reads and mutations use a two-tier check. The system first verifies company membership, which is the cheap and common case, and falls back to a project-asset junction check for consultants who are scoped to a specific project rather than a whole company. When a check fails, the platform returns a not-found response rather than a forbidden one, which means an out-of-scope user cannot even confirm that an asset exists. Failing closed in this way is deliberate. The safe default for a tenancy boundary is to reveal nothing.
Bulk operations get their own guard. Before any bulk mutation runs, a single verification call rejects the entire batch if even one asset identifier sits outside the caller’s scope. This prevents a bulk update from becoming a tenancy leak, where a malformed batch quietly touches assets the caller should never reach. Platform administrators and global roles bypass these checks where appropriate, but for ordinary tenant-scoped users the boundary is absolute and enforced in SQL.
Holdings need to look across that boundary in a controlled way, and subsidiary roll-up is how PMAP handles it. An include_subsidiaries option widens the company filter to the full holding subtree, so a parent organization can view inventory across all of its subsidiaries in one pass without dissolving the boundaries between them. The default view stays scoped to a single tenant, and the roll-up is an explicit, opt-in widening rather than a leaky default. That combination, strict isolation by default and deliberate roll-up on demand, is what lets one console serve both a single subsidiary and the holding above it without compromising either.
How PMAP Anchors VM on Asset Truth
Step back from the individual capabilities and a single idea connects all of them. A vulnerability program is only as trustworthy as the asset layer beneath it, and PMAP is built to make that layer trustworthy on purpose. Every finding, scan, and risk score resolves to an asset, so the platform invests in getting the asset right before anything else has to depend on it.
That investment shows up as a chain of deliberate choices. Inventory is built from many sources without producing duplicates, because creation resolves matches and refuses to guess when an asset is ambiguous. Identifiers stay clean, because IPs and hostnames are canonicalized before any comparison. Assets grow richer over time, because enrichment folds in scanner signals under strict source precedence and a tight allowlist, with every write audited. Findings reach a human, because polymorphic ownership and a multi-strategy resolver decide who is accountable. Inventory becomes a targeting layer, because static and dynamic groups, with live preview, turn assets into reusable scopes. Prioritization reflects exposure, because risk scoring ranks assets by the severity of what they actually carry. Observation is provable, because scan coverage and the wave matrix show what has been scanned and how it changed. And none of it crosses a tenant boundary, because scope is enforced in the query itself.
The result is an attack surface you can defend rather than a list you maintain. When the inventory is honest, triage stops being an argument about which findings are real and becomes a ranked walk down a list of real exposure. That is the payoff of treating asset inventory as the foundation rather than an afterthought. The rest of the program inherits the quality you build here.
If you want the condensed, reference version of everything above, read the asset inventory and risk management datasheet. It maps the inventory, enrichment, grouping, risk scoring, and coverage capabilities onto the foundation your vulnerability program needs.
Frequently Asked Questions
What is the difference between asset inventory and attack surface management?
Asset inventory is the record of every manageable entity in your environment. Attack surface management is what you do with that record to understand exposure. In PMAP the two are tightly linked, because the inventory carries the attributes that define surface, such as the internal-versus-external flag, criticality, and the enriched technical profile of open ports and services. Inventory is the data. Attack surface management is the reasoning about which of those assets an attacker can reach and which ones matter most if they do.
How does PMAP avoid creating duplicate assets when importing from multiple sources?
On every create, the service matches the incoming asset against existing inventory by name and by each IP address within the same company. A dup_action parameter controls the outcome. The default rejects a duplicate, the skip action returns the existing asset unchanged, and the update action merges metadata, unions tags, and adds new IPs into the existing record. If the name matches one asset and an IP matches a different asset, the service refuses to guess and returns an ambiguous-match error rather than collapsing two distinct machines into one. This is what lets a CMDB sync, a scanner import, and a manual entry coexist without duplicating the inventory.
What is the difference between a static and a dynamic asset group?
A static group has hand-picked membership that stays exactly as curated until someone changes it. A dynamic group stores a rule that is re-evaluated against the inventory every time the group is read, so its membership is always current. Dynamic rules can match on company, asset type, class, criticality, location, tags with any-of or all-of semantics, and on a CIDR block. Before saving a dynamic rule, you can preview exactly which assets it would match against the live inventory, so you can refine the rule before committing it.
How is an asset’s risk score calculated?
An asset’s risk score is a function of the severity and count of the active findings it actually carries. Each asset keeps a finding summary that breaks active findings down by severity, and that severity-banded picture is the raw material of the score. Risk rises as serious findings accumulate and falls as they are remediated. Two contextual attributes shape how the score should be read. Criticality captures how much the business cares about the asset independent of its findings, and the internal-versus-external flag captures whether an attacker can reach it. Asset-level scoring ranks individual machines, while program-level and board-level risk reporting rolls those scores up in the analytics and reporting layer.
What does scan coverage tell me that a finding list does not?
A finding list tells you what has been discovered. Scan coverage tells you whether an asset is actually being looked at, by showing which integrations and scanners have produced findings for it. An asset that no integration has ever scanned is a coverage gap you can see and close, which a finding list cannot reveal because an unscanned asset simply has no findings to show. The wave matrix extends this into change over time, laying out each finding against each scan wave and marking it open, closed, reopened, or absent, so a regression that returns several waves later becomes visible instead of hidden.
How does PMAP keep one tenant’s assets isolated from another’s?
Every list, export, and facet query applies a scope filter derived from the authenticated context, enforced in SQL rather than trusted to the caller. Single-asset reads use a two-tier check of company membership and then a project junction, and a failed check returns not-found rather than forbidden, so an out-of-scope user cannot even confirm an asset exists. Bulk operations reject the entire batch if any single identifier falls outside the caller’s scope. For holdings, an explicit subsidiary roll-up option widens the view to the full holding subtree on demand, while the default stays scoped to a single tenant.
Can asset enrichment overwrite data my team has set manually?
No, not unless you explicitly allow it. Enrichment enforces a strict source precedence where manual input outranks rules, runbooks, scanners, and imports. A scanner can never overwrite a manually set field unless that field is unlocked. Enrichment is also restricted to a fixed allowlist of technical fields, namely open ports, services, technologies, software, operating system details, hostname, FQDN, and MAC, so it cannot touch ownership, criticality, or tenancy. When a scanner value conflicts with a higher-precedence one, the write is recorded as conflict-pending for an administrator to review rather than applied silently, and every enrichment write is captured in a per-field audit log.
