What is scanner finding merge across targets?

Scanner finding merge across targets is the scanner-side discipline that recognises when the same underlying vulnerability instance has been detected on multiple distinct targets (many hosts running the same OS image, many containers built from the same base image, many endpoints behind the same load balancer, many services that import the same library version, many web applications served by the same identity provider configuration) and surfaces those detections as a coherent cluster while preserving the per-target identity each detection carries. It is not deduplication. Deduplication collapses two records that describe the same instance on the same target at the same authentication context into one record. Merge across targets keeps each per-target detection visible but binds them under one cluster signature so leadership reads cluster cardinality, owner attribution names the cluster owner alongside the per-target owners, the fix conversation runs against one root cause, and the audit citation reads the cluster as one finding family that was contained across the fleet.

How is cross-target merge different from per-target deduplication?

Per-target deduplication operates on one target at a time. The same SQL injection at five parameters of one endpoint on one host is one finding with five trigger evidence rows; the same missing security header on twenty pages of one application on one host is one finding with twenty affected URLs. The cleanup happens before the finding leaves the target. Cross-target merge operates above target boundaries. The same Log4j CVE detected on three hundred Java services across the fleet is three hundred per-target records bound to one cluster signature; the same RDS instance type misconfiguration detected on twelve database instances across two AWS accounts is twelve per-target records bound to one cluster signature. The per-target records stay so the team can answer "which exact host still has it" and the cluster record stays so leadership can answer "how many systems were affected and is the root cause fixed". Programmes that try to do per-target dedup at fleet scale lose the per-target identity that retest and ownership depend on; programmes that try to do cross-target merge by collapsing per-target records lose the cardinality signal that risk and remediation planning depend on.

How is cross-target merge different from the merge-and-supersede workflow?

The two pages cover sequential layers of one chain. The merge-and-supersede workflow on the engagement record is the operational discipline that decides which surviving record carries the identity when two findings overlap and which decision input names the survivor. The scanner-side discipline this page covers is everything that has to be true about the scanner output before the workflow can fire defensibly. The cluster signature has to be carried on each per-target detection so the workflow can group them. The signature has to be deterministic across recurring scans so the cluster does not re-form with a different identity every cycle. The version of the signature has to bind to the version of the affected component so a library upgrade or a config template revision creates a new cluster identity rather than mutating the existing one. When the scanner side carries the cluster signature, the workflow operates on a coherent cluster and the merge decision reads as one operating event. When the scanner side does not carry the signature, the workflow has to reconstruct the cluster from search-substring guesses and the audit trail reads as a series of one-off decisions.

What signatures actually identify a cross-target cluster?

Five signatures cover most of what shows up. The component coordinate signature binds findings that share an exact package name plus version (org.apache.logging.log4j:log4j-core:2.14.0 across every Java service that depends on it). The base image digest signature binds findings that share an exact container image digest (sha256 hash of the base layer across every container built from it). The OS image signature binds findings that share an exact OS image identifier (the AMI id, the GCE image name, the Azure marketplace image plus version across every host built from it). The configuration template signature binds findings that share an exact rendered configuration (the IaC module output hash, the load balancer rule template hash, the identity provider SAML configuration hash across every asset configured from it). The rule reference signature binds findings emitted by the same scanner rule against multiple targets with identical evidence shape (Semgrep rule identifier plus the rule pack version across every repository the rule fired in). A cluster signature that is just the finding title or the CWE alone is too coarse; the same logical weakness shows up across unrelated root causes. A cluster signature that is just the affected_asset alone is too narrow; the same root cause never groups. The five signatures above each anchor a deterministic match key that recurring scans inherit without rewriting cluster identity.

How should recurring scans inherit cluster identity?

Cluster identity inheritance follows the same rule as per-finding identity inheritance, with one extra layer. The per-target finding match key (workspace plus template plus canonical asset reference) inherits the prior assignment, status, and override across recurring scans. The cluster signature on each per-target finding inherits the cluster membership across recurring scans, so the recurring detection lands on the same cluster identity as the prior cycle. The cluster membership is read from the per-target finding signature, not stored as a separate cluster record that has to be reconstructed on each scan. The extra layer is the cluster lifecycle event log: when the cluster signature changes (library version upgrade, base image rebuild, configuration template revision, rule pack revision), the prior cluster identity stays on the historical record and the new cluster identity starts on the next detection. Programmes that key cluster identity to a free-text rollup name produce clusters that drift between scan cycles; programmes that key cluster identity to the structural signature produce clusters that stay coherent across cycles without per-cycle reconciliation work.

How should multi-owner clusters be handled at the scanner side?

Cross-target clusters almost always cross owners. The Log4j cluster touches every product team that ships a Java service. The base image cluster touches the platform team that builds the image and every workload team that runs containers from it. The OS image cluster touches the platform engineering team that bakes the AMI and every workload team that boots hosts from it. The configuration template cluster touches the team that maintains the template and every team that consumes its rendered output. The defensible pattern at the scanner side is the cluster carrying a primary owner (the team accountable for the root-cause fix at the source: the library maintainer, the image baker, the template author, the rule maintainer) plus a per-target owner on each child detection (the team accountable for adopting the fixed source on their target: the product team that updates their dependency, the workload team that rebuilds their containers, the workload team that re-bakes their hosts, the team that re-applies the configuration template). The cluster activity log records both layers so the audit reads the full accountability picture, the leadership rollup reads the cluster cardinality alongside per-team adoption progress, and the per-target retest evidence rolls up to the cluster closure decision.

How should imported third-party scanner output land into existing clusters?

Imported findings from Nessus, Burp Suite, CSV exports of CSPM tools, or manual entry from consultancy deliverables need the same cluster signature the native scanner output carries. The import workflow resolves the component coordinate, the image digest, the OS image identifier, or the configuration template hash where the source data exposes it, and binds the imported per-target finding to the existing cluster signature if one is present. Imported rows whose source data does not expose a structural signature land into the unowned-cluster queue, where the analyst confirms the cluster binding before the routing rule fires. The source-emitted cluster name (Nessus plugin family, Burp Suite issue type, vendor scan-report rollup label) stays on the evidence section so the audit chain reads the original vendor signal alongside the workspace cluster identity. Programmes that route imported rows on the vendor cluster name inherit a backlog where the same logical cluster lands with different identities depending on which tool fired first.

How does SecPortal support scanner finding merge across targets?

SecPortal stores each scanner-emitted finding against a verified_domains or connected_repos foreign key, a finding template identifier, and a canonical asset reference. The recurring detection identity that lets a per-target finding inherit prior workspace decisions is keyed to the workspace plus the template plus the canonical asset reference. The 300 plus finding templates ship with category strings, severity bands, and CVSS 3.1 vectors so the per-target identity is anchored to workspace values rather than to vendor signals. Bulk finding import (Nessus, Burp Suite, CSV exports of other tools) resolves each row against the asset register at ingest, so imported per-target rows land on the same canonical asset references as native scan output. The activity log captures every per-target finding event with the named actor and timestamp; CSV export of the activity log is available for evidence packaging. Finding overrides are keyed to the workspace, the template, and the target so per-target suppression and severity decisions travel with the recurring detection. Finding comments and collaboration record the per-target remediation conversation against the canonical record. Honest scope: SecPortal does not maintain a packaged SBOM cluster graph that auto-derives cluster signatures from a build pipeline; it does not maintain a packaged container registry digest graph that auto-binds image-derived clusters; it does not maintain a packaged CMDB beyond the verified_domains and connected_repos registers; it does not synchronously create cluster-level tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie through packaged connectors; it does not run an autonomous cluster engine that opens or closes clusters without human review at the workspace level. The cluster identity is operated as a workspace discipline against the structured per-target fields the platform exposes, with the cluster read constructed at query time from the per-target finding signatures rather than as a separate cluster surface that has to be kept in sync.

What failure modes does cross-target merge guard against?

Five failure modes show up across most enterprise programmes. A cluster identity built from free-text rollup labels (the analyst types "log4j" on each per-target finding manually) drifts between scan cycles and across analysts, so the cluster cardinality is unreliable and the audit cannot reproduce the cluster membership. A cluster identity built from the finding template alone (every SQL injection across every service becomes one cluster) collapses unrelated root causes, hides the per-component fix surface, and produces a leadership report where one cluster name covers ten unrelated remediation conversations. A cluster identity that propagates per-target suppression to the cluster (one false positive closes the cluster on every other host) loses the targets that still carry the finding, and the audit reads a closed cluster while exposed hosts remain. A cluster identity that does not version on source component change (the Log4j 2.14 cluster mutates into the Log4j 2.17 cluster instead of closing-and-reopening) loses the closure signal for the original component version and inherits a cluster that conflates two different exposures. A cluster identity that does not bind imported third-party scanner output (the Nessus per-host Log4j detections land as separate findings outside the existing Log4j cluster) splits one root-cause conversation across two cluster identities and the audit reads two parallel remediation efforts that were actually one. The defensible programme structures the scanner side so each of these failure modes surfaces as a named pattern with a recorded recovery path rather than as silent backlog the team has to reconstruct from chat logs at fieldwork.

← Back to Scanner Information

Scanner guide15 min read

Scanner Finding Merge Across Targets

One root cause can show up on three hundred targets. The Log4j CVE detected on every Java service that imports the library. The kernel CVE detected on every host built from one OS image. The TLS configuration drift detected on every load balancer rendered from one template. The identity-provider misconfiguration detected on every service that federates through one configuration. Each of those is a fleet-wide cluster, not three hundred independent findings. The scanner side of cross-target merge is everything that has to be true about scanner output before the leadership rollup, the audit citation, and the routing conversation can read the cluster as one finding family while still answering "which exact target still carries it" on every per-target row.

This guide covers the boundary between per-target deduplication and cross-target merge, the five cluster signatures that produce a deterministic match key, how recurring scans inherit cluster identity without rewriting cluster membership, how multi-owner clusters carry a primary owner at the root cause alongside per-target adoption owners, how per-target suppression and severity override interact with cluster identity, how imported third-party scanner output binds into existing clusters, how cluster identity versions when the source component changes, and how ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, and NIST CSF 2.0 read the cluster artefact chain.

What cross-target merge is and what it is not

Cross-target merge is a read on the per-target finding population, not a separate cluster surface that the workspace has to keep in sync. Each per-target finding carries a structural signature that ties it to a root cause; the cluster is the set of per-target findings that share the same signature at a point in time. The cluster read answers cardinality, owner attribution at the root, and adoption progress; the per-target findings answer which exact target still carries the finding, who owns the per-target adoption decision, and what evidence the retest will rest on.

The discipline is not deduplication. Per-target deduplication collapses two records that describe the same instance of the same weakness on the same target at the same authentication context into one record. The cleanup happens before the finding leaves the target; the scanner output deduplication guide covers per-target dedup mechanics. Cross-target merge sits above target boundaries: the per-target records stay distinct, and the cluster signature binds them under one root-cause identity that leadership and audit read.

The discipline is also not the merge-and-supersede workflow on the engagement record, which is the operational decision about which surviving record carries the identity when two findings overlap. The vulnerability finding merge and supersede workflow operates on top of the scanner-side cluster discipline. When the scanner side carries the cluster signature, the workflow operates on a coherent cluster; when the scanner side does not, the workflow has to reconstruct the cluster from substring searches and analyst memory.

The five cluster signatures that anchor cross-target identity

A defensible cluster signature is structural, not a label. The five signatures below cover most of what enterprise programmes need to group across targets; each one binds per-target findings to a deterministic match key that recurring scans inherit without rewriting cluster identity.

Signature	Match key	Example cluster
Component coordinate	Package ecosystem plus name plus exact version (org.apache.logging.log4j:log4j-core:2.14.0).	Same CVE detected on every Java service that depends on the vulnerable package version.
Base image digest	sha256 digest of the base layer (sha256:1a2b3c...).	Same kernel-level CVE detected on every container built from one base image.
OS image identifier	Cloud-provider image identifier plus version (ami-0abc...; gce-image-name; azure-image-publisher/offer/sku/version).	Same OS package CVE detected on every host built from one AMI before the patched AMI rebake.
Configuration template	Hash of the rendered configuration (IaC module output hash, load balancer rule template hash, SAML configuration hash).	Same TLS posture drift detected on every load balancer rendered from one Terraform module before the module version bump.
Rule reference	Scanner rule identifier plus rule pack version (semgrep rule id plus pack revision).	Same Semgrep finding emitted against every repository the rule fired in after a rule pack update.

A signature that is just the finding title or the CWE alone is too coarse; the same logical weakness clusters across unrelated root causes. A signature that is just the affected_asset alone is too narrow; the same root cause never groups. The five structural signatures above each anchor a match key the scanner side can carry on every per-target detection without analyst input on each scan cycle.

Five failure modes the scanner side has to guard against

Cluster identity discipline is not optional once the fleet has more than a handful of shared sources. The five failure modes below cover most of what surfaces at audit fieldwork as a cluster the team cannot reproduce.

Cluster identity built from free-text rollup labels

The analyst types "log4j" on each per-target finding manually. Three weeks later a different analyst types "Log4j", "log4j 2.14", or "log4j-core". The cluster cardinality is unreliable and the audit cannot reproduce the cluster membership from the structured fields alone. The right pattern is a structural signature (the component coordinate, the image digest, the OS image identifier, the configuration template hash, the rule reference) carried as a typed field, not a free-text rollup label.

Cluster identity built from finding template alone

Every SQL injection across every service becomes one cluster. Every missing security header across every web property becomes one cluster. Unrelated root causes collapse into one cluster name, the per-component fix surface is hidden, and the leadership report shows one cluster covering ten different remediation conversations. The right pattern is the finding template plus a structural signature that binds findings to a shared root cause; the template alone is the weakness class, not the cluster identity.

Per-target suppression propagating to the cluster

One per-target finding closes as a false positive on one host and the workspace propagates the closure to every other per-target finding in the cluster. The cluster reads as closed while exposed hosts still carry the finding. The right pattern is per-target suppression staying per-target; the cluster cardinality decrements by one and the cluster record continues to reflect the remaining exposed targets. Cluster-level suppression is a separate, deliberate workspace decision that requires its own rationale and audit trail.

Cluster identity not versioning on source change

The Log4j 2.14 cluster mutates into the Log4j 2.17 cluster instead of closing and a new cluster opening for 2.17 if 2.17 also turns out to be vulnerable. The closure signal for the original component version is lost and the cluster conflates two different exposures. The right pattern is the cluster signature including the version coordinate; a version change closes the prior cluster identity and opens a new one with its own remediation lifecycle.

Imported scanner output landing outside the cluster

The Nessus per-host Log4j detections imported from a CSV export land as stand-alone findings outside the existing Log4j cluster because the import did not carry the component coordinate to the canonical record. One root cause conversation splits across two cluster identities and the audit reads two parallel remediation efforts that were actually one. The right pattern is the import workflow exposing the cluster signature where the source data supports it, and an unowned-cluster queue catching imported rows whose signature cannot be resolved before they auto-bind to the wrong cluster.

How cluster identity inherits across recurring scans

Cluster identity inheritance follows the same rule as per-finding identity inheritance, with one extra layer. The per-target finding match key (workspace plus template plus canonical asset reference) inherits the prior assignment, status, and override across recurring scans; the scanner finding routing and owner assignment guide covers the per-finding inheritance discipline. The cluster signature carried on each per-target finding inherits the cluster membership across recurring scans, so the recurring detection lands on the same cluster identity as the prior cycle without the team having to reattach cluster membership manually.

The mechanism is the cluster signature being a deterministic property of the per-target detection rather than a stored cluster record that has to be maintained in parallel. When the scanner emits a finding against a Java service with a Log4j 2.14 dependency, the per-target finding carries the component coordinate signature org.apache.logging.log4j:log4j-core:2.14.0. The cluster read at query time returns every per-target finding with that signature; the cluster does not have to be opened, closed, or maintained as a separate record. When the team rebuilds the service on Log4j 2.17, the next scan produces a per-target finding without the 2.14 signature, the per-target record closes as the dependency is no longer present, and the cluster cardinality decrements automatically.

The extra layer is the cluster lifecycle event log. When the cluster signature changes (library version upgrade, base image rebuild, configuration template revision, rule pack revision), the prior cluster identity stays on the historical record and the new cluster identity starts on the next detection. The activity log records the source-component event so the audit reads the cluster lifecycle as a sequence of named events rather than as silent mutation between cycles. For the wider lifecycle of how scanner output produces continuity rather than churn across recurring scans, the scan baseline and trend comparison guide covers the recurring detection mechanics each cluster member inherits from.

Multi-owner clusters and the primary-plus-adoption pattern

Cross-target clusters almost always cross owners. The Log4j cluster touches every product team that ships a Java service. The base image cluster touches the platform team that builds the image and every workload team that runs containers from it. The OS image cluster touches the platform engineering team that bakes the AMI and every workload team that boots hosts from it. The configuration template cluster touches the team that maintains the template and every team that consumes its rendered output. The rule reference cluster touches the team that maintains the rule and every repository owner whose code triggered the rule.

The defensible pattern at the scanner side is the cluster carrying a primary owner at the root cause alongside a per-target owner on each child detection. The primary cluster owner is the team accountable for the root-cause fix at the source (the library maintainer who upgrades the library; the image baker who rebuilds the base image with a patched layer; the template author who revises the configuration; the rule maintainer who tunes the rule). The per-target owner on each child detection is the team accountable for adopting the fixed source on their target (the product team that updates their dependency manifest and ships a new build; the workload team that rebuilds their containers from the new base image; the workload team that re-bakes their hosts on the new AMI; the team that re-applies the configuration template to their asset). For the workspace discipline that runs the routing rule against per-target owners, the security finding ownership and routing use case covers the operational layer.

The cluster activity log records both layers so the audit reads the full accountability picture, the leadership rollup reads the cluster cardinality alongside per-team adoption progress, and the per-target retest evidence rolls up to the cluster closure decision. Programmes that hard-collapse multi-owner clusters to one default owner lose the per-team adoption signal; programmes that fan out the cluster into separate per-owner sub-clusters lose the root-cause conversation. Primary-plus-adoption keeps both intact on one cluster identity.

How suppression and severity override interact with cluster identity

Per-target suppression and per-target severity override are workspace decisions on the per-target finding, not on the cluster. A per-target finding closed as a false positive on one host decrements the cluster cardinality and the cluster record reflects that one fewer target carries the finding; the cluster itself does not close. A per-target severity override on one host (the host is in a different criticality band than the cluster default) does not change the cluster severity; each per-target finding carries its own workspace severity that the routing rule reads, while the cluster severity is the workspace severity for the cluster identity at the root.

The override and suppression mechanics are documented separately. The scanner finding suppression and deferral controls guide covers the per-target suppression mechanism, including how suppression travels with the recurring detection on the same target without re-application each cycle. The cluster-level severity decision (the workspace deliberately bands the cluster differently from the per-target findings because the cluster cardinality changes the risk picture) is a separate workspace event with its own rationale and audit trail; it does not flow automatically from per-target overrides.

Programmes that propagate per-target suppression to the cluster lose visibility on the targets that still carry the finding and the audit reads a closed cluster while exposed hosts remain. Programmes that propagate per-target severity overrides to the cluster lose the per-target accountability the routing rule depends on. Keeping cluster identity as a read on aggregate per-target state, while still allowing cluster-level severity calibration as a deliberate workspace decision, preserves both layers.

How imported third-party scanner output binds into clusters

Findings imported from Nessus, Burp Suite, CSV exports of CSPM tools, container scanner exports, or manual entry from consultancy deliverables need the same cluster signature the native scanner output carries. The import workflow resolves the component coordinate, the image digest, the OS image identifier, or the configuration template hash where the source data exposes it, and binds the imported per-target finding to the existing cluster signature if one is present.

Asset binding at import time

Each imported row is resolved against the asset register at ingest. Hostnames, URLs, file paths, and repository references map to the corresponding verified domain or connected repository entry, with the source-emitted reference preserved on the evidence section. The scanner finding asset binding guide covers the asset binding chain that lets the per-target identity attach to a durable register entry before the cluster read fires.

Cluster signature resolution at import time

Where the source data exposes a component coordinate, an image digest, an OS image identifier, or a configuration template hash, the import workflow carries that signature onto the per-target finding so the cluster read picks it up. The source-emitted cluster name (Nessus plugin family, Burp Suite issue type, vendor scan-report rollup label) stays on the evidence section so the audit chain reads the original vendor signal alongside the workspace cluster identity.

Unowned-cluster queue for unresolved imports

Imported rows whose source data does not expose a structural signature land into an unowned-cluster queue, where the analyst confirms the cluster binding before the routing rule fires. The queue requires a recorded decision per row (bind to an existing cluster, open a new cluster with a named signature, leave the finding as a per-target only with no cluster membership documented). The activity log captures the decision so the cluster membership reads as a controlled workflow rather than as silent auto-binding.

Category translation alongside cluster identity

The source-emitted tag translates to the workspace controlled vocabulary through a documented mapping; the source-emitted tag stays on the evidence section so the audit chain stays intact. The scanner finding tag and label taxonomy guide covers the workspace taxonomy the routing and cluster identity layers read.

Cluster lifecycle and versioning on source change

Cluster identity has to version when the source component changes. The discipline is the same shape as the routing rule revision pattern: prior identity preserved, new identity effective from the next detection, change rationale captured against the source-component event. Treating the cluster identity as a live label that mutates silently produces audit conversations the team cannot answer; treating it as a versioned artefact with effective dates produces a lifecycle the audit can read.

Source event	Cluster lifecycle outcome
Library version upgrade	Prior cluster identity (component coordinate with old version) closes when no per-target findings carry the old version. A new cluster opens only if the new version is independently vulnerable.
Base image rebuild	Prior cluster identity (image digest with old hash) closes when no per-target findings reference the old digest. A new cluster opens only if the rebuilt image carries a new vulnerable layer.
OS image rebake	Prior cluster identity (AMI id with old version) closes when no per-target findings reference the old image. A new cluster opens only if the rebaked image carries a new vulnerable package.
Configuration template revision	Prior cluster identity (template hash with old output) closes when no per-target findings reference the old hash. A new cluster opens only if the revised template carries a new misconfiguration.
Rule pack update	Prior cluster identity (rule reference plus pack version) closes when the rule no longer fires on any target. A new cluster opens only if the updated rule fires on new targets.

The lifecycle event log captures each transition with a timestamp and the named source event. Audit fieldwork reads the lifecycle as a sequence of deliberate decisions rather than as silent mutation across cycles. The discipline pairs to the wider trend analysis on the engagement record; the trend reads the closure curve for each cluster identity over time, and the leadership rollup reads cluster cardinality changes against cluster lifecycle events to separate root-cause fixes from scope shifts.

Where this fits in the wider scanner evidence chain

Cross-target merge sits on top of several scanner-side disciplines. Asset binding produces the canonical asset reference each per-target finding attaches to. The taxonomy produces the workspace category that the per-target routing reads against. Severity normalisation produces the workspace severity band each per-target finding carries. Per-target deduplication produces the recurring detection identity that lets per-target inheritance work. Suppression and override produce the per-target workspace decisions that travel with each child detection rather than reset on every scan. The cluster signature sits on top of all of these and reads them as the input to the cross-target identity.

For the upstream asset binding chain that resolves the canonical reference each per-target finding inherits, the scanner finding asset binding guide covers the asset register entries and the failure modes that break the binding. For the per-target identity that each child detection inherits across recurring scans, the scanner output deduplication guide covers the per-target deduplication discipline. For the operational workflow that decides which surviving record carries the identity when two records overlap, the vulnerability finding merge and supersede workflow covers the workflow side.

For the analytical view of when rolling up cross-target findings into one cluster pays in budget terms, the scanner finding merge economics research covers the cost-benefit picture that pairs to the scanner-side discipline this guide covers. For the per-target deduplication economics that pair to the cluster economics, the security finding deduplication economics research covers the per-target carrying cost analysis that complements the cluster carrying cost analysis.

How compliance frameworks read cross-target cluster identity

Auditors read clusters through three artefact classes: the cluster signature policy, the cluster-level remediation record, and the cluster activity log. Each artefact answers a different question. The policy is the operating discipline that bounds which signatures the workspace clusters against and how clusters version; the remediation record is the proof that the root-cause fix tracked to closure across the fleet; the activity log is the trace evidence that reproduces the cluster membership and lifecycle.

Framework	Where it reads cluster identity
ISO 27001:2022	Annex A 8.8 technical vulnerability management; Annex A 8.28 secure coding (for rule-reference cluster lifecycle); Annex A 5.9 inventory and ownership of information and other associated assets.
SOC 2	CC4.1 monitoring controls and CC7.1 detection of system events read cluster cardinality as fleet-wide exposure evidence; CC8.1 change management reads cluster lifecycle on source-component updates.
PCI DSS v4.0	6.3.3 ranking and risk-based remediation reads cluster severity calibration; 11.3 internal and external scans read cluster cardinality across recurring scan cycles.
NIST SP 800-53 Rev. 5	RA-5 vulnerability monitoring reads cluster cardinality; SI-2 flaw remediation reads per-target adoption against cluster identity; CM-8 system component inventory reads cluster membership against the asset register.
NIST CSF 2.0	ID.RA risk assessment reads cluster cardinality as fleet-wide exposure; RS.MI mitigation reads cluster closure curve as root-cause fix evidence.
CIS Controls v8.1	Control 7 continuous vulnerability management reads cluster cardinality and the per-target adoption rate; Control 16 application software security reads rule-reference cluster activity.
DORA	Article 8 identification of ICT assets reads cluster membership against the asset register; Article 9 protection and prevention reads cluster severity calibration and root-cause closure evidence.

A cluster record that cannot answer how many targets the cluster touched at any given moment, which per-target findings were closed against the cluster, how the cluster signature versioned over time, and what evidence supports the cluster closure decision fails every one of these readings. The discipline is not optional for programmes that operate at fleet scale; it is the cluster artefact chain that the audit reads as proof the team operates root-cause remediation rather than per-host firefighting.

How SecPortal supports scanner finding merge across targets

SecPortal stores each scanner-emitted finding with the structured per-target fields that the cluster read sits on top of. The mechanism is consistent across external, authenticated, and code surfaces; the register entry and the source class differ by surface.

Per-target finding identity as the cluster substrate

Every per-target finding carries an asset binding through a verified_domains or connected_repos foreign key, a finding template identifier, a category string, a severity band, an engagement reference, a source class (external, authenticated, code, manual, imported), and a scan execution reference where applicable. The 300 plus finding templates ship with pre-set categories, severity bands, and CVSS 3.1 vectors so the per-target identity is anchored to workspace values rather than to vendor signals. The findings management feature covers the data model the cluster read constructs against.

Recurring detection identity inherits per-target state

Finding identity is keyed to the workspace, the finding template identifier, and the canonical asset reference. Recurring detections of the same template against the same target match the existing per-target finding so the cluster membership inherits without rewriting cluster identity. The continuous monitoring feature covers the recurring scan cadence each cluster member inherits from.

Imported scanner output resolves to the same canonical record

Bulk imports from Nessus, Burp Suite, and CSV exports of other tools resolve each row against the asset register at ingest time. Where the source data exposes a component coordinate, an image digest, an OS image identifier, or a configuration template hash, the import workflow carries that signature onto the per-target finding so the cluster read picks up the imported per-target findings under the same cluster identity as the native scan output. The bulk finding import feature covers the import workflow.

Per-target overrides do not propagate to the cluster

Finding overrides (false positive, accepted risk, severity adjustment, category revision) are keyed to the workspace, the template, and the target so per-target decisions stay per-target. The cluster read decrements cardinality when a per-target finding closes; the cluster severity stays as the workspace severity for the cluster identity, separate from per-target severity overrides. The finding overrides feature covers the override mechanism that travels with each per-target identity.

Activity log captures cluster lifecycle events

The activity log records every per-target finding event (assignment, status change, severity adjustment, suppression, override) with the named actor, the timestamp, and the engagement reference. The cluster lifecycle events (source component upgrade, base image rebuild, OS image rebake, configuration template revision, rule pack update) read against the per-target finding closure curve to reproduce cluster lifecycle from the activity stream. CSV export of the activity log is available for evidence packaging. The activity log feature covers the audit trail mechanism.

Finding comments hold the cluster conversation

The cluster-level remediation conversation runs across per-target finding comments and collaboration threads. The conversation references the cluster signature explicitly so the audit trail reads the discussion against the cluster identity rather than across disconnected per-target threads. The finding comments and collaboration feature covers the discussion model.

Honest scope: SecPortal does not maintain a packaged SBOM cluster graph that auto-derives component coordinate clusters from a build pipeline. SecPortal does not maintain a packaged container registry digest graph that auto-binds image-derived clusters. SecPortal does not maintain a packaged OS image inventory beyond the asset references stored on the verified_domains and connected_repos registers and the engagement scope record. SecPortal does not synchronously create or update cluster-level tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie through packaged connectors. SecPortal does not run an autonomous cluster engine that opens or closes clusters without human review at the workspace level. The cluster identity is operated as a workspace discipline against the structured per-target fields the platform exposes; the cluster read is constructed at query time from the per-target finding signatures rather than as a separate cluster surface that has to be kept in sync.

An operational checklist

When designing the cluster signature

The signature is a structural property (component coordinate, image digest, OS image identifier, configuration template hash, rule reference) carried as a typed field, not a free-text rollup label.
The signature includes the version coordinate so a source-component change versions the cluster identity rather than mutating it silently.
The finding template alone is the weakness class, not the cluster identity; the cluster signature pairs the template with the structural root cause.
Each cluster signature has an explicit owner role (the team accountable for the root-cause fix at the source) recorded against the cluster identity.

At scanner output

Each per-target finding carries the cluster signature alongside the per-target identity fields.
Recurring detections inherit cluster membership without rewriting cluster identity.
Per-target suppression and severity override stay per-target; cluster-level decisions are deliberate workspace events with their own rationale.
Multi-owner clusters carry a primary owner at the root cause and a per-target owner on each child detection.

At cluster lifecycle

The cluster identity versions on library upgrade, base image rebuild, OS image rebake, configuration template revision, and rule pack update.
The lifecycle event log captures each transition with a timestamp and the named source-component event.
Imported third-party rows whose signature cannot be resolved enter an unowned-cluster queue rather than auto-binding to the wrong cluster identity.
The cluster closure decision rests on aggregate per-target finding closure, not on a separate cluster-level state field that has to be maintained in parallel.

At audit fieldwork

Cluster cardinality can be reconstructed from the structured per-target finding signatures at any point in time.
Cluster lifecycle reads as a sequence of named source-component events rather than as silent mutation between scan cycles.
Per-target adoption against each cluster identity reads against the per-target finding closure curve.
Multi-owner cluster activity reads both primary owner and per-target adoption against one cluster identity rather than across disconnected per-owner sub-clusters.

Scope and limitations

Cross-target merge only works when the per-target finding records are durable and the cluster signature carries onto each per-target detection deterministically. Programmes that store findings in spreadsheets, in scanner UIs that reset asset references on rule updates, or in workflow tools without typed signature fields cannot operate the cluster identity chain at all. The leverage point is consolidating findings into a workspace with stable foreign keys, a controlled vocabulary, and structural signature fields before attempting to govern the cluster identity.

SecPortal does not replace an enterprise SBOM platform, a container registry digest graph, a CMDB, or an autonomous cluster engine. The cluster identity is operated against the structured per-target fields the workspace exposes and the cluster read is constructed at query time from those fields. Where the wider enterprise stack carries cluster signatures through an SBOM-graph platform, an image-provenance registry, a CMDB inventory, or an IaC-module-output index, the mapping between those sources and the per-target signature fields on SecPortal findings is the team's discipline rather than a platform automation.

For the analytical view of how cross-target merge economics pair to the operational scanner-side discipline this guide covers, the scanner finding merge economics research covers the budget frame for when rolling up pays. For the routing discipline that each cluster member inherits its assignment from, the scanner finding routing and owner assignment guide covers the per-target ownership chain.

Frequently Asked Questions

Run cross-target finding clusters on a record auditors and security leaders can both read

SecPortal stores every scan execution and finding against verified asset register entries, with structured per-target identity fields that cross-target cluster reads sit on top of. Recurring detections inherit per-target state, imported scanner output resolves to the same canonical record, and the activity log captures every per-target event so the cluster identity is reproducible at audit fieldwork without reconstructing cluster membership from chat logs.

Start free See the merge workflow