What is scanner output normalised asset resolution and why does it matter?

Normalised asset resolution is the discipline of mapping the asset identifier each scanner emits onto one canonical asset key the workspace operates against. The same logical asset shows up in scanner output under many different identifiers: an external scan reports a hostname, a port, and a URL path; an authenticated scan reports the same hostname with a different credential profile; a code scan reports a repository slug and a file path; an SBOM scan reports a package coordinate inside a container image; a container scan reports an image digest; a cloud configuration scan reports a cloud resource identifier; an internal scan reports an IP and a host fingerprint; a third-party import reports a free-text asset string that may or may not normalise to anything. Without resolution, the workspace runs five concurrent ownership lookups, five severity aggregations, five retest paths, and five audit conversations against the same underlying exposure. With resolution, every finding against the asset inherits the same owner, the same SLA band, the same remediation history, and the same audit trail. The discipline is operational, not cosmetic; routing, dedup, retest, closure, and reporting all depend on it.

How is asset resolution different from asset binding?

Asset binding is the per-scanner question: which canonical reference does this scanner type emit, and how does that reference attach to the finding record. External scans bind through a verified domain, authenticated scans bind through the same domain plus a credential profile, code scans bind through a connected repository, container scans bind through an image digest, cloud scans bind through a cloud resource identifier. Each scanner type uses its own canonical key by design. Asset resolution is the cross-scanner question: when the same logical asset appears under different keys across scanner types, how does the workspace turn the divergent keys into one record so dedup, ownership lookup, severity aggregation, retest binding, and audit reconstruction all operate against the same asset rather than against three or five parallel asset records. Asset binding decides the canonical key per scanner; asset resolution decides the canonical asset across scanners.

What are the most common asset identifier collisions in production scanner output?

Seven collision patterns cover most production cases. Hostname versus fully qualified domain name: app01 versus app01.internal.example.com referring to the same host. Hostname versus IP: app01.internal versus 10.0.4.12 for the same target on different scan sources. URL path variations: https://api.example.com/v1/users versus https://api.example.com/v1/users/ versus https://api.example.com/V1/USERS resolving to the same endpoint. Container image variations: registry.example.com/team/app:v3.2.1 versus registry.example.com/team/app@sha256:abc... versus team/app:latest pointing to the same image layer. Repository identifier drift: github.com/example/web-app versus example/web-app versus web-app picking up the same code asset. Cloud resource identifier variations: arn:aws:s3:::example-prod-bucket versus example-prod-bucket versus s3://example-prod-bucket. Package coordinate variations: lodash@4.17.21 versus npm:lodash:4.17.21 versus pkg:npm/lodash@4.17.21. Each pattern looks unambiguous to the operator who wrote the scan policy and ambiguous to the workspace consolidating output across five tools. Resolution policy names which form is canonical for each asset class.

Why does the workspace need a separate unresolved-asset queue?

Scanner output frequently contains asset references that do not normalise: a hostname not registered in the workspace, a repository slug for a recently transferred repo, a container image from a registry that is not in the workspace inventory, a cloud resource identifier from an account that joined the estate last week, a free-text affected_asset string from a third-party import. Treating these as new asset records on the fly multiplies the asset registry with low-quality entries and breaks the resolution discipline. Treating them as discardable silently drops findings that may represent real exposure. The unresolved-asset queue is the third path: scanner emissions whose asset reference does not resolve to a known canonical key land on a dedicated queue for a named triager. The triager decides per emission whether the reference is a typo to merge into an existing asset, an alias to register as an auxiliary identifier, a new asset to register as a fresh canonical key, a stale reference for a decommissioned asset to retire, or a scope artefact that should not have been scanned. The activity log records the triage decision so the resolution history is reconstructable.

How does asset resolution handle DNS aliases, hostname rotations, and IP changes?

DNS aliases, hostname rotations, and IP changes are routine in production and are the leading cause of asset record splits. The resolution model treats the canonical identifier as the long-lived key and the auxiliary identifiers as resolvable aliases. For a host with a canonical FQDN of app01.internal.example.com, the workspace records the short hostname (app01), the current IP set, and any DNS aliases (api.example.com if the host fronts that record) as auxiliary identifiers that resolve to the same canonical key. When a scanner emits against any of these forms, the resolution rule maps the emission back to the canonical asset record. When the IP set changes (a rotation, a re-IP, a region move), the auxiliary identifier list updates but the canonical key holds and existing findings remain bound. When the FQDN changes (a domain reorganisation, a rebrand), the change event is recorded on the activity log with the previous canonical key and the new canonical key, and findings re-bind through the migration record rather than splitting the asset across two records. The discipline lives on the resolution policy, not on the scanner emission.

How does asset resolution handle container images, image digests, and tag rotations?

Container images carry two identifier classes that need different resolution rules. The image digest (sha256:abc...) is the immutable canonical key for a specific layer set; the image tag (v3.2.1, prod, latest) is a mutable label that points at different digests over time. The resolution model treats the digest as the canonical key for a specific image instance and the tagged reference as an auxiliary lookup that resolves to the current digest at the moment of the scan. A finding emitted against registry.example.com/team/app:v3.2.1 with no digest attached resolves to whichever digest the tag was pointing at when the scan ran; the finding record carries both the tag reference and the resolved digest so the scan reproducibility survives the tag rotating. A finding emitted against the digest directly resolves to the same canonical key regardless of which tag now points at it. When the image is rebuilt and a fresh digest replaces the previous one, the resolution rule decides whether the new digest is a new asset record (the image identity changed) or a new version of the existing asset record (the image is logically the same; the version is the rolling property). The workspace policy chooses; the choice is documented per image class.

How does asset resolution handle source-emitted versus platform-canonical references?

The defensible model preserves both. The source-emitted reference is whatever the scanner returned verbatim: the raw hostname string, the raw URL, the raw image tag, the raw repository slug, the raw cloud resource identifier. The platform-canonical reference is the resolved canonical key the workspace operates against. Both live on the finding record. The source-emitted reference is the audit evidence that the original scan output is reproducible: an auditor reading the finding can trace it back to the exact scanner emission. The platform-canonical reference is the operating handle for dedup, routing, severity aggregation, and retest. When a workspace stores only the source-emitted string, the resolution layer has to re-run on every read and the canonical key drifts between readers. When a workspace stores only the platform-canonical reference, the audit trail loses the original emission and an auditor cannot verify the resolution decision. Storing both is the cleanest model; the source string is immutable, the canonical key updates through documented change events.

How does SecPortal handle scanner output asset resolution?

SecPortal binds scan executions to specific asset classes through structured foreign keys. External and authenticated scan executions bind to a verified_domains entry through a domain_id foreign key on the scan_executions table; the domain is registered once in the workspace through DNS, file, or meta tag verification, and every scan run carries the domain_id plus the workspace_id. Code scan executions bind to a connected_repos entry through a repo_id foreign key on the code_scan_executions table; the connected repo is OAuth-bound to the workspace and carries the organisation and repository name. Findings produced by either path carry the engagement_id reference (which carries the workspace_id) and an affected_asset field that captures the source-emitted reference verbatim. The finding template library covers 300+ canonical finding types with a stable template identifier, so recurring detections of the same template against the same target match across scan cycles. Finding overrides are keyed to the workspace, the finding template identifier, and the scan target, so suppression and severity-override decisions inherit across scan cycles without re-applying. Bulk imports of Nessus, Burp Suite, and CSV exports use a reusable column mapping that lands the asset reference into the same affected_asset field with the same recurring-detection match. Honest framing: SecPortal does not ship a built-in cross-scanner asset registry that normalises every host, IP, URL, image digest, repository slug, and cloud resource identifier into one global canonical record; the resolution discipline runs against the verified_domains entry for external and authenticated scans, the connected_repos entry for code scans, and the import-time column mapping for third-party output. Programmes needing a wider cross-asset registry layer typically maintain that layer outside the workspace and land the resolved canonical key into the affected_asset field at import time so the same recurring-detection match logic continues to operate.

How do compliance frameworks read asset resolution evidence?

Auditors read asset resolution through four artefacts. The resolution policy (the canonical identifier per asset class, the normalisation rules, the alias resolution rules, the conflict resolution rule, the unresolved-asset queue handling) is the policy evidence reviewed at audit kickoff; it answers how the team decides which asset reference is canonical. The finding-to-asset resolution chain (the source-emitted reference, the platform-canonical reference, the resolution decision history) is the operating evidence sampled at fieldwork; it answers whether the policy was applied to specific findings. The unresolved-asset queue history (which references landed unresolved, which were merged into existing assets, which were registered as fresh canonical keys, which were retired) is the discipline evidence read across the observation period; it answers whether the team treats unresolved references as a controlled triage activity rather than as silent drift. The asset change-event log (rename events, transfer events, decommission events, image rebuilds, cloud resource migrations) is the lifecycle evidence; it answers whether the resolution layer survives asset estate changes. ISO 27001 Annex A 5.9 and 8.8 read the chain as inventory and vulnerability management evidence; SOC 2 CC4.1 and CC7.1 read it as monitoring and risk treatment evidence; PCI DSS 6.3.3 and 11.3 and 12.5.1 read it as ranking, recurring scan, and asset inventory evidence; NIST 800-53 CM-8 and RA-5 read it as system component inventory and vulnerability monitoring; NIST CSF 2.0 ID.AM reads it as asset management; CIS Controls v8.1 control 1 and 2 read it as inventory of enterprise assets and software assets.

What is the cleanest pattern for re-binding findings when an asset identifier changes?

The cleanest pattern records the change as a deliberate event rather than as a silent rewrite. When an FQDN changes through a domain reorganisation, a repository moves through a transfer, a container image is rebuilt with a fresh digest, or a cloud resource is migrated, the resolution policy fires a change event on the asset record. The change event carries the previous canonical key, the new canonical key, the trigger (rename, transfer, rebuild, migration), the timestamp, the acting user where applicable, and a count of bound findings. Existing open findings re-bind through the change event by updating the canonical reference on the record while preserving the source-emitted reference verbatim and writing the previous canonical key to the activity log as the migration anchor. The retest path continues to operate against the new canonical key; the audit lookback can reconstruct the binding history from the activity log. Wrong patterns include silently rewriting the affected_asset field with no event record (the audit trail loses the change), closing the old finding and opening a fresh one on the new identifier (the lifecycle history splits and ages reset), or holding both records open in parallel (the queue accumulates duplicate findings that no remediation owner can untangle).

← Back to Scanner Information

Scanner guide15 min read

Scanner Output Normalised Asset Resolution

The same asset shows up under five different identifiers across five scanners. Without an explicit resolution layer the workspace operates against five parallel asset records, ownership lookups split, severity aggregation fragments, and audit reconstruction breaks at fieldwork. Hostnames versus fully qualified names, URLs with and without trailing slashes, container tags versus image digests, repository slugs versus organisation-qualified slugs, cloud resource ARNs versus short names, package coordinates in three different syntaxes. Each variation looks unambiguous to the scanner that emitted it and ambiguous to the workspace consolidating output across the stack.

This guide covers how to model the canonical asset key per asset class, what a defensible resolution policy carries, how to route unresolved scanner emissions through a triage queue rather than auto-creating low-quality asset records, how DNS rotations and image rebuilds re-bind without splitting the finding lifecycle, how to preserve source-emitted references alongside platform-canonical references so audit evidence reproduces, and how internal vulnerability management teams, AppSec engineers, cloud security operators, and security engineering leaders read the resolution chain as control evidence for ISO 27001 Annex A 5.9 and 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.3 and 11.3 and 12.5.1, NIST 800-53 CM-8 and RA-5, NIST CSF 2.0 ID.AM, and CIS Controls v8.1 controls 1 and 2.

Asset resolution sits between scanner emission and finding record

Resolution is the layer that maps the asset identifier each scanner emits onto the canonical asset key the workspace operates against. It is not the same as asset binding, not the same as finding deduplication, and not the same as ownership lookup. All three depend on resolution working first.

Resolution versus binding

Asset binding is the per-scanner question: which canonical reference does this scanner type emit (verified domain for external scans, connected repository for code scans, image digest for container scans, cloud resource identifier for cloud scans), and how does that reference attach to the finding. Resolution is the cross-scanner question: when the same logical asset appears under different keys across scanner types, which key is canonical for the workspace and how do divergent emissions reconcile to one record. Binding decides the canonical key per scanner; resolution decides the canonical asset across scanners.

Resolution versus finding deduplication

Finding deduplication operates at the finding level: when two scanners detect the same vulnerability against the same target, the dedup rule decides which detection becomes the canonical finding record. Dedup assumes the asset is already resolved. Resolution operates one layer earlier: when two scanners report against the same logical asset under different identifiers, the resolution rule decides which identifier is canonical and which scanner emissions belong to the same asset record. A workspace running dedup without resolution merges findings only when the asset string matches verbatim and silently produces parallel asset records.

Resolution versus ownership lookup

Ownership lookup is the routing question: which named owner does this finding go to. Ownership joins through the asset record. If the asset record has split into three parallel records under three different identifiers, ownership has to be resolved three times and may resolve to three different owners. Resolution turns ownership lookup into one join rather than three. The asset-ownership-mapping workflow runs against the canonical key that resolution produced.

Resolution versus audit reconstruction

Audit reconstruction reads the finding back to the underlying scanner emission and from the emission to the actual asset that produced it. Without resolution, the same asset under five identifiers reads as five different audit threads; the auditor cannot tell whether the five threads represent one exposure with five detections or five exposures with no consolidation discipline. Resolution collapses the threads to one and surfaces the multi-scanner detection history as evidence of coverage rather than as evidence of record fragmentation.

Seven asset identifier collisions that recur in production

The seven patterns below cover most production cases. Each one looks unambiguous to the operator who wrote the scan policy and ambiguous to the workspace consolidating output. The resolution policy names which form is canonical for each asset class and how the other forms map back.

Collision class	Example divergence	Canonical form
Hostname vs FQDN	app01 versus app01.internal.example.com for the same host.	FQDN; short names register as auxiliary lookups.
Hostname vs IP	app01.internal versus 10.0.4.12 for the same target.	FQDN; IP registers as the current address-set property.
URL path variations	Trailing slash, case folding, percent encoding, query order.	Normalised path per RFC 3986 with documented stripping rules.
Container tag vs digest	team/app:v3.2.1 versus team/app@sha256:abc... versus team/app:latest.	Image digest; tag references resolve to the digest at scan time.
Repository slug variants	github.com/example/app versus example/app versus app.	Fully qualified host plus organisation plus repository name.
Cloud resource forms	ARN versus short name versus URI form.	Provider-specific canonical identifier (ARN, full resource path).
Package coordinate variants	lodash@4.17.21 versus npm:lodash:4.17.21 versus pkg:npm/lodash@4.17.21.	Package URL (purl) syntax with ecosystem qualifier.

The policy choice is workspace-specific. A workspace that runs primarily on AWS will land on ARN as the canonical cloud reference; a workspace on Azure will land on the resource ID format; a workspace on GCP will land on the qualified resource path. The choice is published once and applied consistently across every scan ingestion.

Six elements of a defensible resolution policy

The policy is the workspace document that names how scanner emissions become canonical asset references. The six elements below cover most operating cases. The policy lives on the workspace, not inside any one scanner.

Canonical identifier format per asset class

One format per class: hosts use FQDN, URLs use a normalised form, container images use image digest, repositories use a fully qualified slug, cloud resources use the provider-specific canonical identifier, package coordinates use the package URL syntax. The format is published in workspace documents and operators reference it when adding new asset classes to the resolution policy.

Normalisation rule set

The literal transforms applied to every scanner emission before lookup: case folding for hostnames and URL hosts (lowercase), trailing-slash handling for URL paths, default-port stripping for URLs, query parameter handling (sorted, filtered, preserved), fragment removal for URLs, DNS suffix expansion for short hostnames, tag-to-digest resolution for container references, registry-prefix handling for container and package identifiers. Each transform is documented so two operators arriving at the same emission produce the same canonical key.

Alias resolution rules

The auxiliary identifiers that map to the canonical key without changing it: short hostnames mapping to FQDN, DNS aliases (CNAME chains) mapping to the canonical host, current IP addresses mapping to the host, tag references mapping to the current image digest, deprecated repository names mapping to the current slug. The alias map is workspace data and updates through documented change events rather than ad hoc edits.

Conflict resolution rule

What the workspace does when two scanner emissions map to the same canonical key but disagree on a secondary attribute: different ports on the same host, different file paths on the same repository, different layers on the same image digest, different sub-paths on the same URL. The rule decides whether the secondary attribute becomes part of the canonical key (extending the resolution) or stays as a property of the finding (preserving the resolution). The rule is per asset class and documented in policy.

Unresolved-asset queue handling

The named workflow for scanner emissions whose asset reference does not resolve to a known canonical key. The queue lives on the workspace, a named triager reviews it on a documented cadence, and each emission receives a deliberate decision (merge into existing asset, register as auxiliary alias, register as new canonical key, retire as stale reference, mark as scope artefact). The triage decision lands on the activity log so the resolution history is reconstructable.

Change-event handler

The behaviour when an asset identifier changes: DNS rename, repository transfer, container image rebuild, cloud resource migration. The handler records the change as a deliberate event on the asset record with the previous canonical key, the new canonical key, the trigger, the timestamp, and the count of bound findings. Existing findings re-bind through the change event rather than splitting into parallel records or losing the lifecycle history.

Source-emitted and platform-canonical references both live on the record

The defensible model preserves both. The source-emitted reference is whatever the scanner returned verbatim; it is the audit anchor that confirms the original scan output is reproducible. The platform-canonical reference is the resolved key the workspace operates against; it is the operating handle for dedup, routing, severity aggregation, and retest. Storing one and inferring the other on every read produces drift; storing both produces an audit-defensible record that operations can run against.

Reference type	What it captures	When it changes
Source-emitted	The raw string the scanner returned, captured verbatim and unmodified.	Never. It is the immutable audit anchor for the original scan output.
Platform-canonical	The resolved canonical key the workspace operates against, derived through the resolution policy.	Through documented change events (rename, transfer, rebuild, migration); never silently.
Asset register identifier	The stable foreign key into the workspace asset record; survives identifier rotations.	Only when an asset is genuinely retired and a fresh asset register entry replaces it.
Resolution decision history	The activity-log record of every triage decision and change event applied to the asset.	Append-only; entries accumulate as the resolution layer operates over time.

A workspace that holds the source-emitted reference, the platform-canonical reference, the asset register identifier, and the resolution decision history on every finding survives ISO 27001 Annex A 5.9 inventory sampling, SOC 2 CC4.1 monitoring control walkthroughs, PCI DSS 12.5.1 asset inventory tests, and NIST 800-53 CM-8 system component inventory reviews without record archaeology.

DNS rotations, image rebuilds, and cloud migrations as change events

Asset identifiers rotate routinely in production. Hostnames change through DNS reorganisations, repositories transfer between organisations, container images rebuild with fresh digests, cloud resources migrate across accounts. Each rotation is a resolution event the policy has to handle deliberately. The wrong response is silently rewriting the affected_asset string; the right response is recording the change as a named event with the migration anchor on the activity log.

DNS rename or alias rotation

The canonical FQDN changes or a CNAME chain rotates. The change event records the previous FQDN, the new FQDN, the rename trigger, and the auxiliary alias updates. Findings bound to the previous FQDN re-bind through the change event by updating the platform-canonical reference while preserving the source-emitted string. The activity log carries the rename as a discrete entry rather than as a silent rewrite.

Repository transfer or rename

A repository moves between organisations through a transfer, is renamed, or is forked into a successor. The change event records the previous slug, the new slug, the transfer reason, and any organisation context change. Code findings bound to the previous slug re-bind through the change event; file path references inside the repository are preserved through the affected_asset field. The repository connection in the workspace updates to point at the new identifier through the OAuth-bound link.

Container image rebuild

A fresh image digest replaces the previous one because of a code change, base-image update, or build pipeline rerun. The resolution policy decides per asset class whether the new digest is a new asset record (image identity changed) or a new version of the existing asset record (image is logically the same). The change event records the previous digest, the new digest, the rebuild trigger, and the version increment. Findings bound to the previous digest follow the policy: either they retire with the previous image version or they re-bind to the new digest with a version note on the record.

Cloud resource migration

A cloud resource moves across accounts, regions, or providers and the canonical identifier changes. The change event records the previous canonical identifier, the new canonical identifier, the migration trigger, and any cross-account ownership change. Findings bound to the previous identifier re-bind through the change event; the auxiliary identifier list updates with any legacy ARNs or short names that may continue to appear in scanner output during the cutover window.

The change-event discipline is itself audit evidence. A workspace that can show every asset identifier change as a deliberate event on the activity log reads as a controlled inventory programme; a workspace whose affected_asset field is rewritten silently reads as a record without lineage. The first form survives ISO 27001 Annex A 5.9 and 8.8 fieldwork; the second does not.

Five anti-patterns that fragment the asset record

Each pattern produces parallel asset records under different identifiers and breaks dedup, ownership, severity aggregation, and audit reconstruction. The shared root cause is treating the scanner-emitted string as the asset reference rather than as raw input to a resolution layer.

Free-text affected_asset everywhere

The workspace stores only the raw string the scanner returned. The same host appears as five strings across five tools; the same image appears as three references across two scanners; the same cloud resource appears as ARN and short name on the same finding row. Dedup matches only on verbatim equality; ownership lookup runs five times and resolves to five different owners. The fix is the platform-canonical reference as a separate field with the resolution policy applied at ingest.

Auto-create on unrecognised reference

Every scanner emission whose asset reference does not resolve to a known canonical key automatically creates a fresh asset record. The asset register multiplies with low-quality entries that are typos, aliases, or recently-transferred references. Ownership lookup fails on the new records; reporting double-counts the estate. The fix is the unresolved-asset queue with named triage instead of automatic creation.

Silent rewrite on identifier change

When an asset identifier changes the workspace silently rewrites the affected_asset field on every bound finding. The audit trail loses the change; later readers cannot tell whether the rewrite was an alias resolution, a rename event, or a rebinding mistake. The fix is the change-event log with the previous canonical key, the new canonical key, and the migration trigger captured at the moment of change.

Close-and-reopen on rebinding

When an asset identifier changes the workspace closes the existing finding on the old identifier and opens a fresh finding on the new identifier. The lifecycle history splits; the age resets; the audit reading shows two short-lived findings in place of one long-running exposure. The fix is in-place re-binding through the change event so the finding record carries the full history.

Resolution policy inferred from scanner defaults

The workspace has no published resolution policy; the canonical form for each asset class is whatever the dominant scanner happened to emit. When a second scanner enters the stack with different defaults, the resolution layer collapses. The fix is a workspace-level policy that names the canonical form per asset class explicitly, independent of any one scanner.

How compliance frameworks read resolution evidence

The same resolution record reads through several frameworks as different control evidence. The mapping below covers the most common readings auditors run at fieldwork.

Framework clause	What auditors read for
ISO 27001 Annex A 5.9, 8.8	Inventory of information and other associated assets, and technical vulnerability management. Resolution is read as the discipline that lets the inventory and the finding record join through one canonical key.
SOC 2 CC4.1, CC7.1	Monitoring controls and risk treatment. Resolution evidence shows monitoring detections trace back to the same asset record across cycles rather than to parallel asset entries that fragment the risk view.
PCI DSS 6.3.3, 11.3, 12.5.1	Ranking, recurring scan evidence, and inventory of system components. Auditors read the resolution policy alongside the scan record to confirm that recurring scans against the same in-scope asset produce one consolidated finding rather than divergent emissions across tools.
NIST 800-53 CM-8, RA-5	System component inventory and vulnerability monitoring. Resolution is read as evidence the inventory survives renames, transfers, and migrations and that vulnerability findings inherit through the canonical key rather than splitting across stale identifiers.
NIST CSF 2.0 ID.AM	Asset management. Resolution evidence shows the asset register is the source of truth and divergent scanner-emitted strings resolve back to register entries rather than producing parallel inventories per scanner.
CIS Controls v8.1 controls 1, 2	Inventory of enterprise assets and software assets. Resolution is read as the operational discipline that keeps the inventory accurate over time across DNS rotations, image rebuilds, repository transfers, and cloud migrations.
DORA Article 8	ICT asset inventory and classification. Resolution evidence supports the requirement that ICT-related risks read against a consistent asset record across tools and observation periods.

The pattern across frameworks is consistent. A resolution record that captures the canonical key per asset class, the source-emitted references, the alias map, the change-event log, and the unresolved-queue history reads as a controlled inventory and vulnerability management programme. A workspace whose affected_asset field is one free-text string read as missing data fails the same reviews.

How SecPortal handles scanner output asset resolution

SecPortal binds scan executions to specific asset classes through structured foreign keys at the platform layer. External and authenticated scan executions bind to a verified domain entry through a domain_id foreign key on the scan_executions table; the domain is registered once in the workspace through DNS, file, or meta tag verification, and every scan run carries the domain_id plus the workspace_id. The verified domain is the canonical anchor for external and authenticated scanner output against that asset class.

Code scan executions bind to a connected repository entry through a repo_id foreign key on the code_scan_executions table. The repository connection is OAuth-bound to the workspace and carries the organisation and repository name, so code findings inherit the organisation context through the binding rather than requiring per-finding rewriting when an organisation reorganisation occurs.

Findings produced by either path carry the engagement_id reference (which carries the workspace_id) and an affected_asset field that captures the source-emitted reference verbatim. The findings management feature covers 300+ canonical finding types with a stable template identifier; recurring detections of the same template against the same target match across scan cycles rather than producing duplicate records. Bulk imports of Nessus, Burp Suite, and CSV exports use a reusable column mapping that lands the asset reference into the same affected_asset field and inherits the same recurring-detection match. The activity log captures every state transition on the engagement record with CSV export for audit evidence preparation, including the rebinding decisions and the manual asset reconciliation triage outcomes the operator records.

Honest framing: SecPortal does not ship a built-in cross-scanner asset registry that normalises every host, IP, URL, image digest, repository slug, and cloud resource identifier into one global canonical record. The platform binds external and authenticated scans through verified_domains, code scans through connected_repos, and third-party imports through the affected_asset field with reusable column mapping at ingest time. Programmes needing a wider cross-asset registry layer typically maintain that layer outside the workspace (often as a CMDB or an asset management spreadsheet owned by IT or security operations) and land the resolved canonical key into the affected_asset field at import time so the recurring-detection match logic continues to operate against one consistent reference. The recurring-detection key on the workspace plus finding template plus target tuple, the workspace-level activity log, the structured finding state machine, and the foreign-key bindings for external and code scans give the workspace the anchors that a resolution discipline needs to be defensible; the resolution policy itself lives in workspace documents and is operated by named owners under team management role-based access control. There is no Jira, ServiceNow, Slack, SIEM, SOAR, CMDB sync, or directory-service integration that performs cross-system asset reconciliation automatically.

Where resolution fits alongside related disciplines

Resolution is one decision inside a wider scanner output processing chain. The pages below cover the disciplines that resolution interacts with and the workflows that resolution feeds into.

Scanner finding to asset binding: the per-scanner canonical-key model. Asset binding decides which reference each scanner type uses; resolution decides how divergent references across scanner types reconcile to one record.
Scanner output deduplication: the finding-level merge discipline. Dedup operates on findings whose asset is already resolved; resolution provides the asset reference dedup runs against.
Scanner finding aging and staleness: the temporal lifecycle discipline. Asset reference movement is one of the six structural causes of staleness; clean resolution prevents the staleness signal from firing when the identifier rotates but the asset remains.
Scanner output severity normalisation: the severity scale reconciliation discipline. Severity normalisation operates per finding; resolution operates per asset and is the prior step that decides which findings even belong on the same asset.
Scanner evidence chain from scan to finding: the seven-layer audit chain. Asset binding sits on layer three and the resolution record sits inside the source-emitted and platform-canonical layer four.
Scan scoping and target selection: the upstream scope policy. The asset register the resolution layer joins through is the same register scope policy reads against.
Asset ownership mapping for findings: the routing layer that joins through the canonical asset key. Ownership lookup fails when the same asset has split into parallel records under divergent identifiers, which is the problem resolution solves.
Asset decommissioning and finding retirement: the explicit retirement-with-verification path. A retirement decision against the canonical key retires every bound finding in one operation rather than running parallel closures across split records.
Vulnerability finding intake: the intake discipline that captures source-emitted references at the moment of entry and applies the resolution policy before the finding becomes operational.
Security debt portfolio management: the steering-cycle view. Aged-debt tranches read against the canonical asset key; a tranche split across parallel asset records understates concentration risk.

For the analytical view on how scanner coverage interacts with the asset estate, the security tool coverage overlap research covers what overlapping scanner coverage produces when the asset record is split versus when it is resolved. For the upstream measurement-decomposition view on handoff latency between detection and engineering ownership, the security engineering handoff latency research covers how unresolved asset references inflate the routing-primitive evaluation segment of the handoff.

An operational checklist

When adopting the resolution policy

Publish the canonical identifier format per asset class in workspace documents.
Document the normalisation rule set (case folding, trailing-slash, default-port, query handling) for hostnames, URLs, image references, repository slugs, and cloud identifiers.
Capture the alias resolution table for known short hostnames, CNAME chains, deprecated repository names, and tag-to-digest mappings.
Name the workspace owner accountable for unresolved-asset triage and the cadence the queue is reviewed against.

On every scan ingestion

Capture the source-emitted reference verbatim into affected_asset before any rewriting.
Apply the normalisation rule set to derive the platform-canonical reference.
Look up the canonical reference against the workspace asset register; if no match, route to the unresolved-asset queue rather than auto-creating a fresh asset record.
For resolved findings, attach the canonical reference alongside the source-emitted reference on the finding record.

On unresolved-asset triage

Review the queue on the documented cadence with the named owner.
For each emission, decide: merge into an existing asset (alias), register a new alias to an existing asset, register a fresh canonical asset record, retire as a stale reference, mark as a scope artefact that should not have been scanned.
Record the decision on the activity log with the rationale and the acting user.
For decisions to register fresh canonical assets, capture the ownership mapping in the same workflow rather than letting the new asset enter the register without an owner.

On asset identifier change events

Record the change as a deliberate event with previous canonical key, new canonical key, trigger, and acting user.
Re-bind existing findings through the change event by updating the platform-canonical reference while preserving the source-emitted reference verbatim.
Update the auxiliary alias list so the previous identifier continues to resolve during any cutover window when stale scanner output may still emit the old form.
For decommissioning events, route bound findings through the explicit retirement-with-verification workflow rather than letting the finding close silently as the asset reference disappears.

Scope and limitations

Resolution discipline only works when the underlying scanner output captures a stable reference at all. Scanners that emit only ephemeral identifiers (a session-scoped scan target ID that rotates per run, an internal hash without any human-readable anchor) cannot feed a resolution layer without an upstream enrichment step. The leverage point is choosing scanners and import paths that preserve a recoverable source-emitted reference before applying the resolution policy.

Resolution is not a substitute for an asset register. The canonical key the resolution policy derives still has to live somewhere as a known asset record with ownership, classification, and lifecycle metadata. Programmes whose only asset record is the resolution layer itself confuse the operating handle with the inventory truth. The cleanest pattern keeps the asset register as the source of truth (whether in a workspace document, a spreadsheet, a CMDB, or a directory) and treats resolution as the layer that maps scanner emissions back to register entries.

For the broader vulnerability management lifecycle that resolution sits inside, the vulnerability management programme guide covers identification, ranking, treatment, and reporting as one end-to-end discipline. For the governance frame that names the accountable owner for inventory and resolution decisions, the ISO 27001 framework page covers how Annex A 5.9 expects inventory of information and other associated assets to operate as a controlled activity that the vulnerability programme reads against.

Frequently Asked Questions

Resolve scanner asset identifiers on one record

SecPortal binds external and authenticated scans through verified domains, code scans through connected repositories, and third-party imports through reusable column mapping, with a workspace-level activity log and recurring-detection matching so the same asset under five identifiers reads as one consolidated finding rather than five parallel records.

Start free See the asset binding model