Before
An analyst had to compare each resolved incident with its registered findings, request or track a targeted rescan, and return later to interpret the results. The analyst then copied the evidence into the register and incident, deciding whether to close the ticket or send it back to the owner.
How it works
- Retrieve vulnerability incidents and linked register findings, then determine whether each ticket needs a new scan, must wait, or is ready for verification.
- Compare completed targeted-scan detections with the affected host and vulnerability identifiers, classifying each finding as fixed, still present, or not verified.
- Update the register and incident automatically: close fully verified tickets, or reopen and document tickets with incomplete or inconclusive evidence.
Workflow details
- Identify candidates: A scheduled or on-demand run retrieves active vulnerability incidents, including resolved tickets, and matches them with their registered hosts, IP addresses, QIDs, and remediation states.
- Plan verification: For each resolved ticket, the workflow checks for a corresponding targeted scan launched after the latest resolution. It starts a scan when none exists or has failed, waits when a scan is still running, and proceeds to verification when results are complete. Tickets whose findings are already fixed by the daily scan can also be resolved for targeted confirmation.
- Compare evidence: Completed rescans are evaluated by host and vulnerability identifier. Each finding is classified as corrected, still present, or not verified when the host is absent from the scan, producing an evidence-based verdict for the ticket.
- Update records: Corrected findings are marked fixed in the register with the scan date. Tickets with complete remediation are closed with verification notes; partial, failed, or unverifiable results reopen the ticket with the remaining affected hosts and evidence recorded. Repeated reopenings can raise urgency and escalate the ticket to the team manager.
- Report outcomes: The workflow returns counts of closed, reopened, partially remediated, failed, and unverifiable tickets, along with fixed detection counts and an observed remediation time when available.
What changed
Verification now follows a repeatable evidence-based path: scan status and finding comparisons happen automatically, register updates are written from the verdict, and the incident state follows the result without a separate analyst handoff.
Work removed
Manually matching incidents to register findings, requesting and tracking rescans, checking scan completion, comparing detections by host and QID, copying evidence into records, and manually closing or reopening tickets.
Expected outcome
Each ticket requiring verification is designed to receive one consolidated evidence-based verdict, reducing repeated lookups and record updates while preventing closure based only on an owner’s declaration.
