Scanner Finding Cross-Engagement Search and Recall
A finding written into one engagement has to stay findable from outside that engagement, weeks later, when leadership asks a portfolio question, when the auditor samples a cohort, when a new advisory triggers a fleet sweep, or when a recurring detection has to inherit the prior workspace decisions on the same template against the same asset. The scanner side of cross-engagement search and recall is the discipline that produces the structured per-finding fields the workspace-wide search and the cohort workflows depend on; without that discipline, the recall surface fragments and every cohort question reads as analyst reconstruction from chat logs.
This guide covers the boundary between per-engagement search and cross-engagement recall, the six structured per-finding fields the recall surface depends on, how recurring detection title stability prevents free-text fragmentation, how imported third-party scanner output enters the recall catalogue without breaking workspace identity, how finding overrides and the exception lifecycle inherit from the recall surface, the five failure modes that break recallability, and how ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, CIS Controls, and DORA read the recall artefact chain at audit fieldwork.
What cross-engagement recall is and what it is not
Cross-engagement recall is a read on the structured per-finding fields the scanner output writes once at detection time. Each per-finding record carries a workspace identifier, an engagement identifier, a finding template identifier, a title, a category, an affected asset reference, a severity band, a CVSS vector, and a control reference. The recall surface answers cohort questions that range across engagements (which open criticals carry the same CWE across every active engagement), questions that range across time (which findings of this template closed in the last twelve months), and questions that range across sources (which authenticated-scan findings match the same template as a manually filed pentest finding). The mechanism is the workspace-scoped lookup at query time, not a separate index the team has to maintain in parallel.
The discipline is not the cross-engagement finding search workflow on the use-case side, which is the operational layer that runs the cohort questions and routes the result sets to leadership, audit, and SLA review. The cross-engagement finding search use case covers the workflow mechanics; this guide covers what the scanner side has to write for that workflow to fire defensibly.
The discipline is also not the global search palette feature, which is the workspace-scoped lookup surface at the Cmd+K interface boundary. The global search feature covers the palette mechanics, the two-character minimum, the debounce, and the workspace-scoped query construction; this guide covers what the per-finding fields have to look like for the workspace-scoped lookup to return useful matches across every cohort question the workflow runs.
The six structured fields that carry the recall load
Six per-finding fields drive the recall surface. Each one has to be a deterministic property of the template-and-asset pair at detection time, not a free-form sentence an analyst writes per engagement. The fields below match the structured columns on the findings table; the discipline is making sure each one is written consistently on every per-finding row.
| Field | What it carries | What the recall surface reads it for |
|---|---|---|
| Title | Stable, template-keyed substring that names the weakness in the workspace catalogue. | Workspace-wide substring search and cohort questions that name the weakness. |
| Template identifier | Type-level identity that ties the finding to one entry in the workspace template catalogue. | Template-keyed cohort questions (“every Insecure Direct Object Reference finding closed in the last quarter”). |
| Category | Workspace controlled-vocabulary tag that groups findings by class. | Class-keyed cohort questions (“every authentication-class finding across the workspace”). |
| Affected asset reference | Canonical asset reference bound to the verified_domains or connected_repos register entry. | Asset-keyed cohort questions (“every open finding on prod-api.example.com across engagements”). |
| Severity band and CVSS vector | Risk-level identity from the workspace severity catalogue plus the CVSS 3.1 vector. | Severity-keyed cohort questions (“every open critical across active engagements”). |
| Control reference | Compliance-control identity that ties the finding to one entry in the workspace control catalogue. | Control-keyed cohort questions (“every finding mapped to ISO 27001 Annex A 8.8 in the audit window”). |
A workspace whose scanner output writes all six fields consistently has a recall surface that returns the same cohort on every run. A workspace whose scanner output leaves any of these fields free-text or absent inherits a recall surface that requires analyst reconstruction at every cohort question and an audit conversation the team cannot defend. The scanner finding tag and label taxonomy guide covers the controlled-vocabulary discipline the category and control-reference fields read against.
Five failure modes that break cross-engagement recall
Five failure modes show up at fieldwork as a cohort the team cannot reconstruct. Each one is silent: the workspace appears to operate normally until the cohort question is asked, the result set comes back fragmented, and the team has to fall back on chat logs and analyst memory to fill in the gaps.
Free-text finding titles drifting across analysts and cycles
The same vulnerability class is written as “Outdated jQuery 1.7.2”, “jQuery outdated library”, “Outdated jQuery library detected on /admin”, or “jQuery 1.7.2 end of life” across different engagements and across recurring scan cycles. The substring search for “outdated jquery” returns a fragmented cohort and the recurring detection identity reads as separate findings instead of one. The right pattern is the title keying to the template name plus the canonical asset reference deterministically; recurring detections inherit the title from the prior cycle rather than re-generating a sentence the scanner composes each time.
Per-engagement free-text categories drifting across analysts
The same weakness class is tagged “auth bypass” in one engagement, “authentication bypass” in another, and “broken auth” in a third. The category-keyed cohort question cannot group these as one class, the class-level severity calibration fragments, and the leadership rollup undercounts the exposure surface. The right pattern is the workspace operating a controlled vocabulary the category field reads against; the analyst picks from the catalogue rather than typing a label.
Per-engagement free-text asset references drifting across analysts
The same host is named “prod-api.example.com” in one engagement, “api.example.com (prod)” in another, and “api-prod.example.com” in a third. The asset-keyed cohort question cannot recall every finding bound to the host because the references do not normalise. The right pattern is each asset reference resolving against the verified_domains or connected_repos register at detection time, so the canonical reference is the one stored on the finding rather than the free-form note the analyst types.
Imported third-party rows landing with vendor-native identity
A Nessus row imports as “Nessus Plugin 12345 - Apache HTTP Server outdated” while the native scanner writes “Apache HTTP Server Outdated Version” for the same weakness against the same asset. The recall surface fragments across native and imported findings of the same class because the imported row landed without resolving against the workspace template catalogue and the asset register. The right pattern is the import workflow translating the imported title to the template-keyed title, the imported asset reference to the canonical reference, and the imported severity to the workspace severity band before the row reaches the recall surface; the vendor-native identity stays on the evidence section as source provenance.
Scanner output rewriting the finding title on every cycle
The scanner emits “Outdated jQuery 1.7.2 detected on 2026-04-02 by scan run 8821” on cycle one and “Outdated jQuery 1.7.2 detected on 2026-04-09 by scan run 8847” on cycle two. The recurring detection reads as a new finding on every cycle, the inheritance for assignment, status, and override fails, and the cohort question “every open critical jQuery finding” returns one row per cycle instead of one row per asset. The right pattern is the title carrying the template name plus the canonical asset reference only; the scan run identifier and the detection timestamp belong on the scan execution record and the evidence section, not on the finding title.
How recurring detection identity protects recall continuity
Recurring detection identity is the property that a scanner firing the same template against the same asset at the same authentication context produces one finding with multiple detections over time, not many separate findings that each get a new title. The match key is the workspace plus the template plus the canonical asset reference; recurring scans that hit the same key inherit the prior assignment, status, severity override, and title.
When recurring detection identity is durable, the recall surface answers historical cohort questions cleanly: every open critical jQuery finding across active engagements returns one row per asset rather than one row per scan cycle; every verified-fixed SQL injection finding closed in the audit window returns the closure event with the original detection date and the original assignment chain; every recurring detection of an authenticated-scan finding inherits the prior workspace severity override rather than reverting to the template default each cycle. The scanner finding aging and staleness guide covers the first_seen and last_seen mechanics that anchor the inheritance.
When recurring detection identity drifts (the scanner rewrites the title each cycle, the asset reference normalises differently across cycles, the category string mutates), the recall surface fragments alongside the identity drift. The cohort question becomes a substring guess against partially overlapping titles, the audit sample cannot reproduce, and the override register loses the finding identity underneath it. The discipline is the title and the structured fields being deterministic properties of the template-and-asset pair, not free-form sentences written per cycle.
How imported third-party scanner output joins the recall catalogue
Imported scanner output (Nessus, Burp Suite, CSV exports of CSPM and container scanners, manual entry from consultancy deliverables) has to join the recall surface through the same structured fields the native scanner writes. The discipline is the import workflow doing the resolution at ingest, not at audit fieldwork.
Title resolution against the template catalogue
Each imported row resolves its source title against the workspace template catalogue. The Burp Suite “SQL injection” issue type binds to the SQL Injection template; the Nessus “SSL/TLS Self-Signed Certificate” plugin binds to the Self-Signed TLS Certificate template; the vendor-native identity stays on the evidence section so the audit chain reads the original source signal alongside the workspace title. Imported rows whose source title does not resolve to a template enter a triage queue rather than landing on the recall surface with a free-text title.
Asset reference resolution against the register
Each imported row resolves its source asset reference against the verified_domains or connected_repos register. Hostnames, URLs, file paths, and repository references map to the corresponding register entry; the source-emitted reference is preserved on the evidence section for provenance. The scanner finding asset binding guide covers the asset binding chain that lets the per-finding identity attach to a durable register entry before the recall surface reads it.
Severity normalisation into the workspace catalogue
Each imported severity translates into the workspace severity band through a documented mapping. The vendor-native severity (Nessus Critical, Burp Suite High, CSPM Severe) stays on the evidence section while the per-finding severity field carries the workspace band the routing rule and the cohort question read against. The scanner output severity normalisation guide covers the band-mapping discipline.
Triage queue for unresolved rows
Imported rows whose template, asset reference, or severity cannot be resolved at ingest enter a triage queue. The analyst confirms the binding (resolve to an existing template, open a new template entry, resolve to an existing asset, add the asset to the register, normalise the severity into the workspace band) before the row reaches the recall surface. Programmes that bypass the triage queue and let imports land free-text fragment the recall surface across every cohort question that touches the imported source.
How the recall surface pairs with overrides and exception lifecycle
Finding overrides (false positive, accepted risk, severity adjustment, deferral) and the exception lifecycle sit on top of the recall surface, not alongside it. The override decision is recorded against the per-finding identity that the recall surface depends on; the same workspace-plus-template-plus-asset match key carries the override across recurring scans, so the override travels with the recurring detection rather than reset on every cycle.
Cohort questions that span overrides and the recall surface return clean result sets when both layers read the same structured fields. The leadership rollup “every open critical finding except the accepted-risk overrides” reads the recall surface joined against the override state; the audit cohort “every false-positive override across the workspace” reads the override register joined against the recall surface. The scanner finding suppression and deferral controls guide covers the override decision mechanics, and the scanner finding exception lifecycle and expiry guide covers the lifecycle the override runs through after the decision is recorded.
When the recall surface fragments through free-text title drift or asset reference drift, the override register fragments with it because the override is keyed to the same identity. The defensible programme keeps both layers reading the same structured fields. The recall surface answers substring and cohort queries; the override register answers decision-history questions; the activity log carries the trace evidence that ties decisions to named actors and timestamps.
How compliance frameworks read cross-engagement recall evidence
Auditors read recall evidence through three artefact classes. The recall policy is the operating discipline that bounds which fields the workspace writes, which controlled vocabularies the category and template strings come from, and how imported scanner output translates into the workspace catalogue. The recall sample is the controlled query the auditor runs at fieldwork and the result set the workspace produces against it. The recall trace is the activity log that reproduces how each finding in the result set was created, by whom, and against which scan execution.
| Framework | Where it reads recall evidence |
|---|---|
| ISO 27001:2022 | Annex A 8.8 technical vulnerability management reads recall as proof that the workspace operates against a consistent finding catalogue rather than per-engagement triage; Annex A 5.30 ICT readiness reads recall as proof that recurring exposure history is reproducible. |
| SOC 2 | CC4.1 monitoring controls and CC7.1 detection of system events read recall cohort cardinality as fleet-wide exposure evidence; CC4.2 communication of monitoring results reads recall sampling as the basis for leadership reporting. |
| PCI DSS v4.0 | 6.3.3 ranking and risk-based remediation reads recall by severity and template; 11.3 internal and external scans read recall cardinality across recurring scan cycles; 11.4 vulnerability scans of changes read recall continuity through recurring detection identity. |
| NIST SP 800-53 Rev. 5 | RA-5 vulnerability monitoring reads recall as the system-wide vulnerability identity record; SI-2 flaw remediation reads recall as the cross-engagement evidence that flaws were tracked to closure; CA-7 continuous monitoring reads recall as the evidence that the workspace tracks recurring exposure consistently. |
| NIST CSF 2.0 | ID.RA risk assessment reads recall cardinality across engagements as portfolio-level exposure; RS.MI mitigation reads recall closure curve as the cross-engagement remediation evidence. |
| CIS Controls v8.1 | Control 7 continuous vulnerability management reads recall as the per-template tracking evidence; Control 17 incident response management reads recall as the cross-engagement context the responder reads when investigating a related incident. |
| DORA | Article 9 protection and prevention reads recall continuity as the cross-engagement evidence of the workspace operating one identity per vulnerability; Article 25 ICT third-party risk reads recall as the evidence that imported third-party scanner output joins the workspace catalogue without identity loss. |
A workspace whose recall surface returns a different cohort on each run because of free-text drift in titles, categories, or asset references fails every one of these readings. The discipline is not optional for programmes that operate at portfolio scale; it is the artefact chain that the audit reads as proof the team operates one identity per vulnerability instance rather than ad-hoc per-engagement triage.
How SecPortal supports scanner finding cross-engagement search and recall
SecPortal stores each scanner-emitted finding with the structured per-finding fields the recall surface sits on top of. The mechanism is consistent across external, authenticated, and code scan surfaces; the register entry and the source class differ by surface but the per-finding identity is the same shape.
Workspace-scoped global search at the API boundary
The global search endpoint runs at the workspace_id boundary against the clients, engagements, and findings tables. Each query is scoped to the authenticated profile's workspace, so a workspace operator cannot return matches from another tenant even if a query string would otherwise hit a similarly named engagement on a different workspace. The findings query matches against the title field with an ILIKE substring pattern, returns up to five matches per type, and deep-links each finding result to the parent engagement scoped to the finding. The global search feature covers the palette mechanics and the role-aware client lookup branch.
300 plus finding templates carry the structured field defaults
The findings catalogue ships with 300 plus templates that pre-set the category, the severity band, and the CVSS 3.1 vector for each weakness class. When a scanner module emits a finding against a template, the per-finding identity inherits those workspace-controlled values at detection time rather than depending on analyst free-text. The recall surface reads the same controlled vocabulary across every engagement because every finding written from the catalogue shares the catalogue's category, severity, and CVSS values.
Recurring detection identity inherits across cycles
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 asset match the prior finding and inherit the prior title, category, severity band, assignment, and override state rather than producing a new free-text title each cycle. The continuous monitoring feature covers the recurring scan cadence the recall continuity depends on.
Bulk finding import resolves into the workspace catalogue
Bulk imports from Nessus, Burp Suite, and CSV exports of other tools resolve each row against the workspace template catalogue and the asset register at ingest. Imported titles bind to the template-keyed title; imported asset references bind to the canonical reference; imported severities translate into the workspace severity band; vendor-native identifiers stay on the evidence section for provenance. The bulk finding import feature covers the import workflow.
Findings management exposes the structured catalogue
The findings management surface lets the workspace operate on the structured per-finding fields through cross-engagement and per-engagement views, with filters against the status group, severity band, category, and assignment. The findings management feature covers the data model the recall surface reads against.
Activity log captures the recall trace
The activity log records every per-finding event (creation, assignment, status change, severity adjustment, override, comment, retest) with the named actor, the timestamp, and the engagement reference. The recall trace at audit fieldwork reads the activity log against the structured per-finding fields to reproduce how each finding in a cohort result set was created and operated. CSV export of the activity log is available for evidence packaging. The activity log feature covers the audit trail mechanism.
Overrides travel with the recurring detection identity
Finding overrides (false positive, accepted risk, severity adjustment, category revision) are keyed to the same workspace plus template plus asset reference match key as the recurring detection identity. The override travels with the recurring detection across cycles rather than reset on every scan, and the cohort question “every open critical except accepted-risk overrides” reads the recall surface joined against the override state. The finding overrides feature covers the override mechanism.
Honest scope: SecPortal global search at the Cmd+K palette currently matches against finding titles only with an ILIKE substring pattern, not against finding description bodies, finding category strings, finding severity bands, or finding control references through the palette itself. Cohort questions that range across non-title fields are answered through the findings list filters on the per-engagement and cross-engagement workflows rather than through the global palette. SecPortal does not ship a packaged full-text search backend, a vendor-managed external search index, or a synchronous cross-tenant search surface. SecPortal does not synchronously push the recall surface to ticketing systems through packaged Jira, ServiceNow, Slack, PagerDuty, or Opsgenie connectors. The recall discipline is operated as a workspace pattern against the structured per-finding fields the platform exposes; the recall surface itself is constructed at query time from those fields rather than as a separate index that has to be kept in sync.
An operational checklist
When designing scanner output
- The finding title is a deterministic property of the template name and the canonical asset reference; the scanner does not embed scan run identifiers, timestamps, or scanner version numbers in the title.
- The category string comes from a controlled workspace vocabulary; the analyst picks from the catalogue rather than typing a label.
- The affected asset reference resolves against the verified_domains or connected_repos register at detection time; the canonical reference is the one stored on the finding.
- The severity band and the CVSS 3.1 vector come from the finding template defaults; per-engagement severity overrides are recorded against the finding identity rather than embedded in the title.
- The control_ref field carries the workspace-controlled compliance-control identity; cohort questions that range across control families read this field directly.
At scanner output
- Each per-finding row carries the workspace identifier, the engagement identifier, the finding template identifier, the title, the category, the affected asset reference, the severity band, the CVSS vector, and the control reference.
- Recurring detections inherit the per-finding identity across cycles; the scanner does not rewrite the title on every cycle.
- Imported third-party rows resolve against the template catalogue and the asset register at ingest; unresolved rows enter a triage queue rather than landing free-text on the recall surface.
- Vendor-native identifiers (Burp Suite issue id, Nessus plugin id, vendor finding id) stay on the evidence section so the audit chain reads source provenance alongside workspace identity.
At cohort question time
- Workspace-wide cohort questions read the structured per-finding fields directly; the analyst does not reconstruct the cohort from substring guesses against free-text titles.
- Status group, severity band, category, and assignment filters compose against the recall surface; the result set is reproducible from the same query against the same workspace state.
- The activity log carries the trace evidence for each finding in the cohort; the audit reads the cohort result set against the per-finding activity history.
At recall hygiene review
- A quarterly or twice-yearly hygiene review runs the workspace cohort questions and confirms the result sets against a sample reconciliation; title drift, category drift, and asset reference drift are caught before they fragment longer-horizon cohorts.
- Imported third-party rows are sampled against their vendor-native source to confirm the resolution at ingest still holds after template catalogue updates or register changes.
- The hygiene review decisions are captured against the activity log so the audit reads recall maintenance as a controlled operating activity rather than as an ad-hoc cleanup.
Where this fits in the wider scanner evidence chain
Cross-engagement search and recall sits on top of several scanner-side disciplines. Asset binding produces the canonical asset reference each per-finding identity attaches to. The category taxonomy produces the workspace-controlled vocabulary the recall surface reads against. Severity normalisation produces the workspace severity band each per-finding row carries. Per-target deduplication and cross-target merge produce the recurring detection identity that lets per-finding inheritance work. Suppression and exception lifecycle produce the override decisions that travel with the recurring detection rather than reset on every scan.
For the upstream asset binding chain, the scanner finding asset binding guide covers the register entries and the failure modes that break the binding. For the controlled-vocabulary discipline the category field reads against, the scanner finding tag and label taxonomy guide covers the workspace category catalogue. For the per-target deduplication discipline that protects the recurring detection identity, the scanner output deduplication guide covers the per-target collapse mechanics.
For the cross-target cluster identity that lets a single root cause group across many per-finding rows, the scanner finding merge across targets guide covers the cluster signature discipline. For the workflow side that runs the cross-engagement cohort questions against the recall surface, the cross-engagement finding search use case covers the operational layer.
Scope and limitations
Cross-engagement search and recall only works when the per-finding records are durable and the structured fields carry deterministic values across recurring scans and imports. Programmes that store findings in spreadsheets, in scanner UIs that reset asset references on rule updates, or in workflow tools without typed category and asset reference fields cannot operate the recall surface at all. The leverage point is consolidating findings into a workspace with stable foreign keys, a controlled vocabulary, and template-keyed identities before attempting to govern cross-engagement recall.
SecPortal global search at the Cmd+K palette runs against finding titles only with an ILIKE substring pattern, not against finding description bodies, category strings, severity bands, or control references through the palette. Cohort questions that range across non-title fields are answered through the findings list filters on the per-engagement and cross-engagement workflows. SecPortal does not ship a packaged full-text search backend, a vendor-managed external search index, or a synchronous cross-tenant search surface. Programmes that need richer search mechanics beyond title substring matching currently operate that capability outside the platform and attach the artefact to the finding using document management so the audit chain stays in one record.
For the analytical view of how the recall surface pairs with the deduplication and merge economics that govern finding inflow hygiene, the security finding deduplication economics research covers the per-target carrying cost analysis the recall surface depends on for cohort reproducibility. For the cross-target cluster economics that pair to the recall surface, the scanner finding merge economics research covers the budget frame.
Frequently Asked Questions
Run cross-engagement finding recall 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-finding identity fields that cross-engagement recall sits on top of. Recurring detections inherit per-finding state across cycles, imported scanner output resolves to the same canonical record, and the activity log captures every per-finding event so the recall surface is reproducible at audit fieldwork without rebuilding cohorts from chat logs.