Vulnerability finding merge and supersede workflow
one identity per underlying issue across every source
Consolidate duplicate vulnerability finding records into one identity-coherent record without losing the closure narrative, the audit trail, or the queue position. The workflow runs on the workspace findings view with status group, severity, and substring filters surfacing the duplicate candidates, the finding state model carrying the closure states the supersession uses, the finding overrides primitive holding the durable upstream suppression for recurring scanner re-detections, and the activity log capturing every merge decision as a named operational action.
No credit card required. Free plan available forever.
One identity per underlying vulnerability across every scanner, every engagement, every cycle
Vulnerability programmes that grow past one or two scanners, one or two engagements, and one or two intake sources accumulate parallel finding records that describe the same underlying issue. Two scanners report the same TLS misconfiguration on the same host. A manual pentest writeup overlaps with an authenticated scan finding on the same endpoint. A third-party pentest report from an external firm imports findings the internal team has already logged. A bulk CSV import lands rows the workspace already carries. The next-cycle scanner detection of a previously closed finding arrives as a fresh record instead of reopening the original. Without a deliberate merge-and-supersede discipline, the open queue grows past the actual workload, the leadership scorecard inflates, the named-owner queue splits across parallel rows, and the audit reads parallel records as separate evidence.
SecPortal carries the merge-and-supersede discipline through the workspace findings record. The cross-engagement view surfaces duplicate candidates through the substring search composed with the status group, severity, and category filters; the finding status enum carries the closure states the supersession uses; the finding overrides primitive holds the durable upstream suppression for recurring scanner re-detections; the activity log writes the merge decision on the workspace audit. The discipline described here pairs to the cross-engagement finding search cohort assembly that surfaces the candidates, the scanner output deduplication ingest discipline that operates upstream at the per-scanner boundary, the deduplication economics research that measures the cost of parallel records, the scanner finding merge economics research that pairs the carrying cost of un-merged related-finding clusters against the discipline cost of running cross-target merge governance, and the reopen-and-regression workflow that handles the special case of next-cycle re-detections.
Seven merge scenarios the discipline resolves
Duplicate finding records arrive through structurally distinct paths. Each scenario below is a recurring path the cross-engagement view exposes and the merge discipline closes into one identity-coherent record.
Same underlying vulnerability detected by two scanners on the same asset
The external scanner reports a TLS misconfiguration on the public endpoint, and the authenticated scanner reports the same TLS misconfiguration on the same target hours later. The cross-engagement view returns two records that describe one underlying issue. The merge discipline selects the surviving record (typically the earlier authenticated scan with stronger evidence), supersedes the second record into a closed status, and writes the surviving record id on the closed record so the audit trail reads as one operating decision rather than as a parallel pair of open findings.
Manual pentest finding overlaps with an automated scanner finding
The tester writes a manual SQL injection finding on /api/orders during a scoped engagement. A subsequent authenticated scan against the same target produces a generic SQL injection record on the same endpoint with weaker evidence. The manual finding carries the validated reproduction steps, the calibrated CVSS vector, and the named tester; the scanner finding adds nothing the manual record does not already hold. The merge discipline keeps the manual finding as the surviving record and supersedes the scanner finding without losing the scan evidence on the activity log.
Third-party pentest report imports overlap with internal records
An external firm delivers a report covering systems that the internal AppSec team has separately scanned. Two or three findings overlap. The third-party report carries the vendor methodology and the contract attestation; the internal records carry the live remediation queue and the deeper evidence. The merge discipline names the surviving record (usually the internal record because it is the operating queue), references the vendor report attribution on the surviving record so the external report context is preserved, and supersedes the duplicate vendor-imported finding into a closed status with the link back to the surviving record.
Scanner re-detection across cycles produces a new record instead of reopening the original
The original finding closed on the previous cycle with a verified fix, and the next scanner run produces a fresh finding on the same target and the same finding template. Without merge discipline the new record looks like a separate finding; with merge discipline the next-cycle detection is recognised as a regression that reopens the original record rather than as a new finding. The cross-engagement view returns one finding with a reopened state and an appended scan-evidence reference, not two records with different identities.
Finding intake from bulk import collides with an existing record
Bulk finding import lands a CSV from a legacy spreadsheet or a prior scanner export, and one of the imported rows describes a finding the workspace already carries. The intake duplicate flag fires at the column-mapping step; the merge discipline names the existing record as the surviving record, attaches the imported source data as evidence on the surviving finding, and the duplicate row closes with the link to the surviving record rather than landing as a fresh open finding.
Two findings record the same issue at different granularities
One finding is written as the broad weakness (cross-site scripting affects the customer portal); the second finding is written as the specific instance (reflected XSS on the support search form). The merge discipline decides which level of granularity the workspace operates at, then keeps the chosen record as the surviving identity. The opposing record either closes with the surviving record link or is rewritten to merge its evidence into the surviving record working notes so the granularity choice is documented.
Superseded finding when scope changes or the asset retires
An open finding becomes irrelevant because the affected asset retired, the application path is removed, the dependency is replaced with a different package, or the system is decommissioned outside the workspace. The merge-and-supersede discipline closes the superseded record to not_applicable with the supersession reason recorded on the closed finding and an activity log entry that names the supersession event. The surviving identity is the absence of the finding; the closed record documents why the original record no longer holds.
Four decision inputs the merge discipline reads
The choice of which record survives and which records close is not arbitrary. Evidence quality, queue position, engagement attribution, and granularity convention decide the surviving identity, in that order.
Which record carries the strongest evidence
Evidence quality is the first decision input. A finding with a documented reproduction, a calibrated CVSS 3.1 vector, a named tester attribution, and an attached request/response payload outranks a finding with only a generic scanner title and a default severity. The record with the stronger evidence becomes the surviving identity; the weaker record closes with the link to the surviving finding rather than the reverse. Cross-engagement finding search filtered to the substring or to the title pattern returns both records so the comparison runs against the actual evidence each record carries, not against the operator memory of which one was logged first.
Which record carries the live remediation queue
A finding that is already in_progress with a named owner, a target close date, and a remediation thread is the operating queue position. Replacing the operating queue position with a duplicate intake breaks the work-in-flight; the merge discipline keeps the in_progress record as the surviving identity even when the duplicate intake has a slightly more recent timestamp. The closed duplicate references the in_progress survivor so the audit trail reads continuously rather than splitting the remediation history across two records.
Which record sits inside the active engagement scope
Engagement attribution matters when the merge crosses two parent engagements. The surviving record is usually the one inside the in-flight engagement because the deliverable, the retest schedule, and the report draft all reference that engagement record. A duplicate logged inside a stale or closed engagement is the candidate for supersession because keeping it open creates a stranded record outside the deliverable boundary. The deep-link from the cross-engagement view to the parent engagement is the audit hand-off the merge decision documents.
Which record reflects the chosen granularity
Granularity is a deliberate workspace convention. Some programmes operate at the broad-weakness level (one finding per CWE per application) and treat each instance as an evidence row on the parent finding; some programmes operate at the per-instance level (one finding per affected endpoint) and treat the broad-weakness narrative as the description on each instance. The merge discipline applies the chosen convention consistently; the surviving record sits at the convention level, and the duplicates at the wrong granularity supersede into the surviving record.
Four closure states for the superseded record
The closure state on the closed duplicate matches the merge cause. The four states below are the operating choices the finding state model supports, each with a different audit reading.
not_applicable
The duplicate represents a finding that should not have entered the operating queue at all, the affected asset retired, the scope changed, the dependency was replaced with a different package, or the parent engagement was rolled back. Closing the duplicate as not_applicable signals to the workspace and to the audit that the record was never operationally valid, not that the underlying issue was fixed.
false_positive
The duplicate represents a scanner-side artefact that has no operational meaning, a tooling re-detection of a previously dismissed scan-time positive, a redundant intake from bulk import that the scanner-output deduplication discipline did not catch at ingest, or a vendor finding that the workspace has already validated as a false positive. The finding overrides primitive records the override decision with the (workspace, finding, target) uniqueness key so the next scanner re-detection inherits the same dismissal automatically.
resolved or closed
The duplicate represents a finding that the surviving record already remediated. The closure narrative on the duplicate cites the surviving record id, the date the surviving record was verified closed, and the retest evidence the surviving record carries. This is the most common closure state when the merge happens after the underlying issue has been fixed but before the duplicate intake was triaged out of the queue.
reopened on the surviving record
When the duplicate is the next-cycle scanner re-detection of a previously closed finding, the operating discipline reopens the original record rather than closing the new detection. The new detection scan-id, the new evidence, and the regression class are appended to the original record working notes, and the original finding moves from a closed status back to reopened. The duplicate detection record itself closes with the reference to the reopened original.
Seven failure modes that surface when merge discipline is missing
Workspaces without a deliberate merge-and-supersede convention drift into recurring failure modes. The seven below are the patterns that show up first.
Two parallel open records describe one underlying issue
Without deliberate merge discipline, the workspace accumulates parallel open records that look like two findings on the leadership scorecard, two findings on the audit response, and two slices of remediation effort on the named owner queue. The headline number on the board pack overstates the open work, the audit reads the parallel records as separate evidence rows, and the owner spends remediation time twice on the same underlying issue. The cross-engagement view exposes the parallel pair; the merge discipline collapses them into one identity-coherent record.
Survivor selection picks the weaker record because it landed last
A common mistake is treating the most recent record as the surviving identity simply because the timestamp is newer. The newer record may have weaker evidence, no named owner, no triage decision, and no remediation thread. Defaulting to the newer record discards the operating queue position the older record already holds. The decision input that matters is evidence strength, queue position, engagement attribution, and granularity convention, not arrival order.
The closed duplicate carries no reference to the surviving record
A duplicate closed with a generic status and no link back to the surviving record leaves the audit trail incomplete. Three months later the reviewer cannot reconstruct why the finding closed (was it actually fixed, was it a duplicate, was it a false positive), and the connection between the closed record and the surviving record is lost. The closure narrative on the duplicate must cite the surviving record id, the merge reason, and the date the decision was made.
Granularity drifts across the workspace without a chosen convention
Half the team logs findings at the CWE-per-application level and half logs at the per-endpoint level. The merge discipline cannot pick a surviving record consistently because the two records sit at different granularities by design. The fix is a documented workspace convention (broad weakness per application, or per affected endpoint, or per parameter) applied consistently at intake, so merge decisions read against one rule rather than against the operator preference of whoever logged the record.
Next-cycle scanner re-detections create a new record instead of reopening the original
When closure does not hold and the next scanner cycle detects the same issue, the new detection should reopen the original finding, not create a fresh record. Without the reopen-and-regression discipline, the workspace fills with closed/reopen pairs that look like distinct findings on the report. The reopened-state convention plus the supersede-the-new-detection rule keeps the identity continuous across closure cycles.
Merge actions happen off-platform and never land on the activity log
Two findings get merged in conversation on a chat channel, in a one-off spreadsheet, or in a triage stand-up note that does not write back to the workspace. The merge decision is real but the audit cannot read it: the workspace still shows both records, the chain of custody breaks at the unrecorded decision, and the next reviewer has to reconstruct the merge by reading meeting notes. Every merge decision must land in the workspace as a status change plus an activity log entry plus an updated working note on the surviving record.
Supersession reason missing or written as a single word
Closing a duplicate as not_applicable with the reason field blank, or with the reason written as duplicate without naming the surviving record, leaves the audit reading the closure as a procedural shortcut. The supersession reason should name the surviving record id, the merge decision input (stronger evidence, in_progress queue position, engagement attribution, granularity convention), and the operator who made the call. The activity log holds the audit chain; the closure narrative holds the human-readable reason.
Nine platform surfaces that carry the merge discipline
The merge-and-supersede workflow rides on top of nine SecPortal features. Each one carries a specific responsibility on the merge cycle; the discipline composes them into one auditable operating record.
Cross-engagement finding search
The dashboard findings view at /dashboard/findings is the surface where duplicate candidates surface. The title and engagement-title ILIKE substring search, the status group filter, the severity multi-filter, and the category multi-filter compose to return potentially-duplicate findings side by side. The joined engagement and client metadata on every row tells the merge decision which parent engagement, which client, and which scan source produced each candidate.
Findings management state model
The finding status enum carries the closure states the merge discipline uses (not_applicable, false_positive, resolved, closed, reopened). Each record transitions through the enum on a single state field; the surviving record stays in the open or in_progress flow, and the closed duplicate transitions to the chosen closure state. The state model is the workspace audit record for every merge decision.
Finding overrides
The scan_finding_overrides table carries (workspace, finding, target) uniqueness on false_positive and accepted_risk overrides. When the duplicate is a scanner re-detection that the workspace has previously dismissed, the override primitive records the dismissal so the next scanner cycle inherits the decision rather than re-creating the duplicate. The override is the durable suppression record above the per-finding closure.
Activity log
Every status change, every override write, and every working-note edit lands on the workspace activity log with the operator, the timestamp, and the before/after values where applicable. The merge decision becomes a named operational action the audit reads, not an off-platform conversation. The activity log itself exports as CSV through the activity-log feature so the merge cohort itself is auditable.
Document management for merge artefacts
When the merge decision involves attaching a vendor report excerpt, a scanner output dump, a screenshot of the cross-engagement view that surfaced the duplicate, or a written merge-decision rationale, the document management feature stores the artefact against the surviving record. The artefact carries the version, the upload timestamp, and the named uploader so the audit reads the supporting evidence alongside the closure narrative.
AI reports for merge documentation
When several merges happen across a cycle and the leadership report needs to summarise the consolidation work, the AI reports feature drafts the narrative section against the workspace record (number of merges, the surviving record cohort, the supersession reason distribution, the scanner-source attribution of the closed duplicates). The draft reads against the live record; the operator edits before publishing.
Team management RBAC
The five team roles (owner, admin, member, viewer, billing) govern which operator can write status changes, override decisions, and working-note edits on a finding. Merge actions sit inside the same RBAC boundary as any other state change; the role check runs before the write executes, so the merge audit trail names the operator with the role at the time of the decision.
Retesting workflows for the surviving record
When the surviving record is in the verified or compliant state, the retesting workflow re-validates the closure under the next engagement cycle. The retest result references the surviving record rather than the closed duplicates, so the closure-verification chain reads against one identity. The retesting feature carries the retest evidence as part of the surviving record history.
Multi-factor authentication
Merge decisions modify operational state across multiple findings. The MFA enforcement at the dashboard middleware boundary keeps the write protected behind the second-factor check so a stolen session cookie cannot drive bulk supersession across the workspace. The MFA boundary is workspace-wide and applies to every state change the merge discipline performs.
Twelve-step operating checklist for the merge cycle
Run the checklist on every merge action and on every merge cohort review. The checklist keeps the audit chain complete, the closure narratives consistent, and the leadership scorecard reconciliation honest.
- Surface duplicate candidates on the cross-engagement finding view by composing the substring search with the status group and severity filters so the cohort is the candidate pair, not the full workspace.
- Compare evidence quality, queue position, engagement attribution, and granularity convention across the candidate pair before choosing the surviving record.
- Name the surviving record explicitly in the working notes of the closed duplicate before the status change so the supersession reference is captured before the closure transition.
- Apply the closure state that matches the merge reason: not_applicable for scope or asset retirement, false_positive for scanner artefact, resolved or closed for already-remediated duplicate, reopened on the surviving record for next-cycle regression detection.
- Write the supersession reason as a structured note (surviving record id, decision input, operator, date), not as a one-word duplicate label.
- Use the finding overrides primitive when the duplicate is a recurring scanner re-detection so the next cycle inherits the dismissal automatically rather than re-creating the duplicate.
- Verify the activity log entry lands with both finding ids referenced on the workspace audit record before declaring the merge complete.
- Attach the merge-decision rationale to the surviving record through document management when the decision involved vendor reports, scanner outputs, screenshots, or operator reasoning that the audit chain needs.
- Confirm the cross-engagement view returns one open record across the substring search after the merge, not two, before stepping away from the workflow.
- Run the merge cohort review on a documented cadence (weekly during high-ingest periods, monthly during steady operations) to clear duplicate accumulation before the leadership scorecard reads against it.
- Reconcile the workspace findings count against the leadership scorecard number on every cycle; a count drift after a merge cycle indicates an incomplete supersession that needs re-running.
- Document the workspace granularity convention in a runbook so merge decisions read against one rule rather than against the operator preference of whoever logged the record.
How the merge record reads against audit frameworks
Auditors and assessors read the workspace inventory expecting one finding per underlying issue with a documented closure narrative on every closed record. The merge-and-supersede discipline produces the inventory and the narrative; the table below pairs the discipline output to the framework requirement the assessment cites.
| Framework reference | How the merge record reads against it |
|---|---|
| ISO 27001 Annex A 8.8 and A 5.36 | Management of technical vulnerabilities and compliance with policies for information security expect the entity to maintain one identity-coherent record per underlying vulnerability with a documented closure narrative. The merge-and-supersede discipline produces that record: the surviving identity remains as the operating row, and the closed duplicates carry the link back to the surviving record with the supersession reason on the activity log. |
| SOC 2 CC4.1 and CC7.1 | Monitoring of controls and detection of security events expect the entity to maintain an inventory of identified vulnerabilities and the response status of each. Parallel duplicate records distort the inventory count and the response status mix. The merge discipline keeps the inventory accurate; the cross-engagement cohort filtered to Open and Pending reads as the auditor s CC4.1 and CC7.1 evidence with one row per underlying issue. |
| PCI DSS 6.3.1 and 11.3 | Identifying and addressing security vulnerabilities and performing internal and external vulnerability scans expect the entity to track every identified vulnerability through to remediation. A QSA examining the remediation record reads better when one finding represents one vulnerability than when two records carry the same fix narrative. The merge discipline produces the one-finding-per-vulnerability record the assessment reads against. |
| NIST SP 800-53 RA-5 and CA-7 | Vulnerability scanning and continuous monitoring expect the organisation to maintain a single inventory of identified vulnerabilities and the operational status of each. The merge-and-supersede discipline produces the single-inventory view: each vulnerability is represented by one surviving record, the closed duplicates document the supersession on the audit chain, and the continuous monitoring strategy reads against the same identity cycle to cycle. |
| NIST CSF 2.0 ID.RA and DE.CM | Risk assessment and security continuous monitoring expect the organisation to identify and document risks against the asset inventory. Duplicate records distort the risk register; the merge discipline keeps the register clean. The cross-engagement cohort returns one finding per underlying issue, and the ID.RA-01 asset vulnerabilities identified evidence reads consistently across cycles. |
| CIS Controls v8.1 Control 7 | Continuous vulnerability management expects the organisation to maintain a process to identify, prioritise, document, and remediate vulnerabilities. The merge-and-supersede discipline is the documentation step the safeguard cites: every duplicate that closes carries the supersession reason and the surviving record reference so the remediation record reads continuously across closure cycles. |
Scope and honest limits of the workspace merge surface
SecPortal carries the merge discipline through composable primitives rather than through a dedicated merge engine. The honest limits below explain what the surface does and what it does not do so the buyer plans the discipline accurately.
No native parent_finding_id or merge_into column on the finding record
SecPortal does not ship a dedicated parent-pointer column on the finding table. The merge identity is documented through the surviving record working notes, the closure narrative on the duplicate, and the activity log entry that names both record ids. Programmes that need a machine-queryable parent pointer maintain a workspace convention (the surviving record id at the top of the closed duplicate working notes, prefixed with the same string) so the convention itself is queryable through the search input.
No automated similarity detection or AI-based duplicate suggestion at workspace level
The platform does not run a semantic similarity engine across the open finding cohort to suggest probable duplicates. The cross-engagement search returns substring matches; the duplicate detection runs through the operator reading the cohort and applying the merge convention. The scanner-output deduplication discipline operates at the per-scanner ingest level for the ingest cohort; workspace-level cross-source duplicate detection runs through the operator.
No one-click merge button that collapses two finding records with full history rewrite
There is no button on the finding detail view that rewrites the duplicate finding history into the surviving record and deletes the duplicate. The merge discipline preserves both records: the surviving record remains as the active identity, the duplicate closes with the supersession reason and the surviving record reference. The two records remain readable on the workspace; the audit reads the relationship from the closure narrative and the activity log rather than from a destructive merge that erases the duplicate record.
No cross-workspace federation; merge is workspace-scoped
Every merge decision applies inside one workspace. A security consultancy or enterprise running multiple workspaces does not see pooled duplicates across the tenant boundary. The workspace_id filter at every query plan enforces the boundary, and the activity log is workspace-scoped. Cross-workspace duplicate detection runs off-platform if it happens at all.
No automatic downstream notification of merge decisions to Jira, ServiceNow, or Slack
SecPortal does not ship native Jira, ServiceNow, Linear, Azure DevOps, Slack, or Teams integrations that auto-notify the downstream ticket of a merge or supersession. When the workspace tracks remediation tickets outside SecPortal, the merge decision is communicated by the operator on the downstream system as a parallel operational action. The merge audit trail on the workspace is complete; the downstream system reflects it through the operator, not through a webhook.
No retroactive history rewrite on the closed duplicate
The closure narrative, the activity log entries, and the working notes on the closed duplicate remain as they were written. The operating discipline does not back-edit the duplicate record once supersession is recorded; later corrections add new working-note entries with the new timestamp and the new reason rather than rewriting prior entries. The audit reads the sequence as it happened.
Who runs the merge discipline
Six audience perspectives on the same workflow. The merge discipline composes the cross-engagement view, the finding state model, the override primitive, the activity log, and the team RBAC into one auditable workspace record. Each audience below reads against the same record from a different angle.
Internal security teams
Keep one identity per underlying vulnerability across every scanner, every manual finding, every bulk import, and every external pentest intake. The cross-engagement view surfaces duplicate candidates; the merge discipline produces the clean inventory the next leadership cycle, the next audit response, and the next remediation cohort all read against.
Vulnerability management teams
Run the duplicate-clearing cohort review on a documented cadence so the open queue represents the actual work rather than parallel records of the same work. The merge discipline reduces the named-owner queue size, sharpens the SLA breach calculation, and keeps the leadership scorecard reading against the live identity.
AppSec teams
Reconcile the manual pentest writeup with the scanner re-detection on the same target without leaving parallel open records on the application. The merge discipline keeps the validated manual finding as the surviving record and supersedes the scanner-side duplicate, so the application security queue reads one row per underlying issue.
Security engineering teams
Drive targeted remediation campaigns on a specific weakness class without the campaign tracker reading double-counted records. The merge discipline names the surviving identity per underlying issue; the campaign progress reads against the one-row-per-vulnerability view.
GRC and compliance teams
Respond to audit fieldwork evidence requests with an inventory that carries one finding per underlying issue. The merge discipline produces the clean record the auditor reads; the closed duplicates carry the supersession trail on the activity log so the audit reads the consolidation work as a deliberate operating discipline.
CISOs and security operations leaders
Read the leadership scorecard against the actual open inventory rather than against a count inflated by parallel duplicate records. The merge discipline keeps the open count honest; the headline number on the board pack reconciles to the cross-engagement cohort it cites because both read from one identity per underlying issue.
Where the merge cohort hands off to the next operating discipline
The merge cohort review feeds into the broader vulnerability programme. The cleaned inventory reads back into the cohort assembly, the SLA calculation, the leadership scorecard, the audit fieldwork response, and the retesting validation cycle.
After the merge cohort review closes, the open queue reads against the live identity per underlying vulnerability. The workspace findings count on the dashboard reconciles to the leadership scorecard headline number; the audit fieldwork response reads against one row per underlying issue; the SLA breach calculation reads against one cycle clock per identity rather than two clocks for parallel records. The next steps below are the operating disciplines the cleaned inventory feeds.
- Cross-engagement finding search for the workspace-level cohort assembly that surfaced the duplicate candidates and now reads against one identity per underlying issue.
- Vulnerability backlog management for the four-aging-bucket queue discipline that reads cleaner once the parallel duplicates are gone.
- Vulnerability SLA management for the SLA cycle clock that runs against one identity per underlying issue rather than parallel clocks on duplicate records.
- Security leadership reporting for the leadership scorecard that reads the open count against the cleaned identity inventory.
- Audit fieldwork evidence request fulfilment for the audit response that reads against one finding per underlying issue with the supersession trail on the activity log.
- Security finding fix verification for the closure-gate proof of fix that reads against the surviving record, not the closed duplicate.
- Security finding reopen and regression handling for the special-case workflow that reopens an original record rather than letting the next-cycle re-detection land as a new finding.
- Vulnerability finding state lifecycle for the state model that carries the closure states (not_applicable, false_positive, resolved, closed, reopened) the supersession uses.
- Vulnerability finding intake for the inbound discipline that catches duplicates at intake before they enter the queue as parallel records.
- Vulnerability acceptance and exception management for the accepted-risk register that reads against the surviving record when supersession involves an accepted-risk override.
- Scanner output deduplication for the per-scanner ingest discipline that operates upstream of the workspace merge cycle.
- Security finding deduplication economics research for the measurement layer that quantifies the cost of parallel duplicate records on the operating queue.
Frequently asked questions
What is the difference between merge and supersede?
Merge is the operating decision that two existing finding records describe one underlying issue and should be consolidated into one identity-coherent record on the workspace. Supersede is the closure action on the duplicate: the duplicate closes with a reason that names the surviving record, the closure state matches the merge cause (not_applicable, false_positive, resolved or closed, reopened on the surviving record), and the activity log captures the relationship. Merge is the decision; supersede is the closure that records the decision on the workspace audit.
How is this different from scanner output deduplication?
Scanner output deduplication is the per-scanner ingest discipline that recognises the same scanner produced two output rows for the same underlying issue (the same SQL injection on five parameters, the same missing header on twenty pages, the same finding template against the same target across consecutive cycles) and collapses them at the intake fingerprint. The merge-and-supersede workflow described here is the workspace-level discipline that operates after intake when two existing finding records on the workspace describe one underlying issue, regardless of whether they came from the same scanner, different scanners, manual entry, bulk import, or third-party pentest reports. The ingest discipline runs at one boundary; the workspace discipline runs at the cross-source identity boundary.
Does SecPortal have a parent_finding_id or merge_into column on the finding record?
No. The finding table does not ship a dedicated parent-pointer column. The merge relationship is documented through the surviving record working notes, the closure narrative on the closed duplicate, and the activity log entry that names both record ids. Programmes that need a machine-queryable pointer maintain a workspace convention (a fixed string prefix on the closed-duplicate working notes followed by the surviving record id) so the convention itself is queryable through the cross-engagement search input.
Which closure state should the duplicate take?
The closure state matches the merge cause. not_applicable when the duplicate represents a finding the operating queue should never have carried (asset retired, scope changed, dependency replaced). false_positive when the duplicate is a scanner-side artefact or a re-ingest of a previously dismissed scan-time positive. resolved or closed when the surviving record has already remediated the underlying issue and the duplicate is the late-arriving intake. reopened on the surviving record when the duplicate is the next-cycle scanner re-detection of a previously closed finding, in which case the original is reopened rather than the new detection landing as a separate record.
How does merge-and-supersede compose with finding overrides?
Finding overrides write a (workspace, finding, target) uniqueness row that the next scanner cycle reads before re-creating a finding. When the duplicate is a recurring scanner re-detection that the workspace has previously dismissed (the original supersession closed the duplicate as false_positive), the finding overrides primitive records the dismissal at the (workspace, finding, target) key so the next cycle inherits the decision automatically. The override is the durable upstream suppression; the merge-and-supersede closure is the per-record audit trail.
Does the cross-engagement search detect duplicates automatically?
The cross-engagement search returns substring matches across the finding title and the engagement title; it does not run a semantic similarity engine or an AI suggestion layer on the open cohort. Duplicate candidates surface through the operator querying the right substring (a CWE shorthand, a finding-template title, a target path, a payload signature) and reading the returned cohort against the merge convention. The platform delivers the cohort; the merge decision runs through the operator with the workspace s granularity convention in mind.
Can SecPortal back-rewrite the duplicate finding history into the surviving record?
No. The duplicate record remains readable on the workspace with the closure narrative and the activity log entries it carried at the moment of supersession. The merge discipline is non-destructive: both records remain visible, the surviving record continues as the active identity, and the closed duplicate carries the link to the surviving record. The audit reads the relationship from the closure narrative and the activity log rather than from a destructive merge that erases the duplicate.
How does merge-and-supersede affect the leadership scorecard?
Parallel duplicate records inflate the open finding count, distort the severity distribution, and split the named-owner queue across two rows that represent one underlying issue. The merge discipline keeps the leadership scorecard reading against the live identity per underlying vulnerability. The headline number on the board pack reconciles to the cross-engagement cohort it cites because the cohort returns one row per identity rather than two for the same issue.
Does SecPortal notify downstream ticketing systems about a merge?
SecPortal does not ship native Jira, ServiceNow, Linear, Azure DevOps, Slack, or Teams integrations that auto-notify the downstream ticket when a finding is merged or superseded. When the workspace tracks remediation tickets in an external system, the operator communicates the merge decision on the downstream system as a parallel operational action. The merge audit trail on the workspace is complete; the downstream notification runs through the operator, not through a webhook.
What is the difference between supersession and reopen-and-regression?
Supersession applies when one of the two duplicate records is the operationally weaker or stranded record and should close in favour of the surviving identity. Reopen-and-regression applies when the duplicate is the next-cycle detection of a previously closed finding; the original record reopens with the new evidence appended, and the new detection record supersedes into a closure that points to the reopened original. Both disciplines run inside the same workspace state model; the choice depends on whether the original record is closed or open at the time of the duplicate intake.
How often should the merge cohort review run?
On a documented cadence tied to ingest volume. High-ingest workspaces (multiple scanners running daily, frequent bulk imports, active pentests in flight) run the review weekly; steady-state workspaces run it monthly. The review uses the cross-engagement finding search to assemble the candidate-duplicate cohort across the workspace, applies the merge convention against each pair, records the supersession on the workspace audit, and confirms the cross-engagement view returns one row per identity before closing the review.
How is the merge audit chain protected against tampering?
Every status change, every override write, and every working-note edit lands on the workspace activity log with the operator, the timestamp, and the before/after values where applicable. The activity log is append-only at the application layer; the workspace_id filter at the query plan enforces the tenant boundary. MFA enforcement at the dashboard middleware boundary keeps state changes behind the second-factor check. The team-role RBAC governs who can write the closure transition. Together these primitives keep the merge audit chain readable and defensible.
How it works in SecPortal
A streamlined workflow from start to finish.
Surface duplicate candidates on the cross-engagement view
Open the dashboard findings view and compose the substring search with the status group filter (Open and Pending), the severity multi-filter, and the category multi-filter to return potentially-duplicate finding pairs side by side. The joined engagement title, client company name, and scan source on every row carry the context each candidate brings to the merge decision.
Compare evidence quality and queue position across the candidate pair
Read the evidence on each candidate (CVSS 3.1 vector, reproduction steps, attached payload, named tester or scanner source, in_progress or open state, named owner). The surviving record is the one with stronger evidence, the active remediation queue position, and the engagement attribution inside the in-flight engagement. Granularity convention is the tie-breaker when evidence and queue position are comparable.
Name the surviving record explicitly before any closure transition
Write the surviving record id and the merge decision input in the working notes of the to-be-closed duplicate before the status change. Capturing the supersession reference before the closure transition ensures the activity log entry on the closure write reads against an already-documented decision rather than against a backfill.
Apply the closure state that matches the merge cause
Pick the closure state from the finding status enum: not_applicable for scope or asset retirement, false_positive for scanner artefact, resolved or closed for an already-remediated duplicate, reopened on the surviving record for next-cycle regression detection. The closure state is the audit read; the activity log entry captures the operator and the timestamp.
Persist the upstream suppression through finding overrides where appropriate
When the duplicate is a recurring scanner re-detection that the workspace has previously dismissed, write the finding overrides row with the (workspace, finding, target) uniqueness key. The override carries the dismissal forward so the next scanner cycle inherits the decision rather than re-creating the duplicate on the open queue.
Attach merge-decision rationale and supporting artefacts
Use document management to attach vendor report excerpts, scanner output dumps, screenshots of the cross-engagement view that surfaced the duplicate, or written merge rationale to the surviving record. Each artefact carries the version, the upload timestamp, and the named uploader so the audit reads the supporting evidence alongside the closure narrative.
Verify the cross-engagement view returns one identity per underlying issue
Re-run the substring search that surfaced the candidate pair and confirm the cross-engagement view now returns one open record rather than two. The verification step is the operational sign-off that the merge is complete; without it the supersession can land partially and leave both records open by accident.
Run the merge cohort review on a documented cadence
High-ingest workspaces (multiple scanners daily, frequent bulk imports, active pentests) run the merge cohort review weekly. Steady-state workspaces run it monthly. The review uses the cross-engagement view to assemble candidate-duplicate cohorts across the workspace, applies the merge convention to each pair, records the supersession on the workspace audit, and reconciles the workspace findings count to the leadership scorecard headline before closing the review.
Features that power this workflow
Vulnerability management software that tracks every finding
Finding overrides that survive every scan cycle
Every action recorded across the workspace
Document management for every security engagement
AI-powered reports in seconds, not days
Collaborate across your entire team
Multi-factor authentication on every workspace
Verify fixes and track reopens on the same finding record
Global search across every engagement, finding, and client
Compliance tracking without a full GRC platform
Bulk finding import bring your scanner data with you
Orchestrate every security engagement from start to finish
One identity per underlying vulnerability, with the audit chain intact
Run the merge-and-supersede discipline on the workspace findings view with the finding state model, the override primitive, and the activity log carrying every consolidation decision. Keep the leadership scorecard honest and the audit trail readable. Start free.
No credit card required. Free plan available forever.