Retest & Closure is the phase that decides whether a vulnerability is genuinely gone. Instead of trusting a patch script’s exit code, SITEY re-runs the scanner that originally reported the finding against the original target, looks for that specific finding in the new results, and only writes the vulnerability to resolved when it fails to come back. Every attempt, whether it closes the finding, reopens it or fails to run, is stored as a retest task with its scanner, target, structured result and timestamps.
The problem
Most teams close vulnerabilities on faith. The remediation script returned zero, the ticket got a green checkmark, and the finding was marked fixed. Nobody re-scanned. Weeks later the next quarterly scan brings back the same CVE on the same host, and the whole triage and assignment cycle runs again on work that was already “done”.
The alternative, doing it properly by hand, is expensive enough that it is the first thing dropped when the backlog grows. For one finding an analyst has to log into the scanner console, build a scan against the right target, wait for it to finish, download the report, search it for the right plugin or issue name, check whether the port and endpoint still match, decide whether a similarly-named finding is the same finding, and then go back to the tracker and update the status by hand. Multiply that by a few hundred findings a month and retesting quietly becomes an assumption rather than a control.
The consequences land in three places.
The same finding gets triaged, assigned and patched again, because nobody proved the first fix actually held.
A “resolved” count that only ever meant “we believe so” is not a metric, it is a hope.
When an auditor asks how you know a critical finding was remediated, the answer is a comment in a ticket rather than a dated scan result.
How it works
- A completed fix flags the finding for retest
When a patch job that is linked to a finding reports success, SITEY does not close the vulnerability. It moves it to a dedicated awaiting retest status and appends a system comment recording which job ran and that verification is still required. The finding stays visible and countable in that state until a retest produces an answer.
- Scanner reachability is checked before any scan is launched
Before a retest scan starts, the module runs a connectivity check against the scanner it is about to use. What that check does depends on the engine: for Nessus it confirms the API answers, that scan templates are available and that a scan can be created; for Burp Suite it validates the stored API key against the version endpoint; for Acunetix it confirms the bundled scan script is present and runnable. The check retries up to ten times with a progressive backoff, and a circuit breaker ends that run early after five consecutive failures instead of continuing to hammer a scanner that is clearly down. If the scanner never becomes ready, the retest task is recorded as failed with the reason, and the vulnerability’s status is left untouched rather than being guessed at.
- The original scanner re-runs against the original target
Retest uses the engine that produced the finding. For Nessus it creates a scan from a template, launches it, polls until completion, and downloads the report. For OpenVAS it starts a task and waits in synchronous mode. For Acunetix it executes the bundled scan script and reads its JSON output. For Burp Suite it calls the REST API, and, this matters for web findings, it rebuilds the target URL from the stored HTTP request, re-attaching the original endpoint path and query parameters so the retest hits the same place the finding was reported on.
- The specific finding is matched, not the scan summary
A retest that just counts new results would close almost nothing. SITEY matches the individual finding. Nessus reports are parsed as XML and each report item is compared on CVE, plugin name and port, with only high and critical severities considered. Acunetix and Burp results are scored across name, URL/endpoint, parameter and severity, and at least two criteria must agree before a result counts as the same finding. A synonym table bridges naming differences between tools, so “XSS” and “Cross-Site Scripting”, or “SQLi” and “SQL Injection”, are recognised as the same class.
- Status is written back and the attempt is kept
If the finding is matched, the vulnerability is set back to open. If it is not, it is set to resolved. Either way a retest task row is persisted with its scanner, target, status, structured result and start and end times, and it appears in the finding’s retest history with running counts of fixed, still-open and failed attempts.
OpenVAS is the exception: its retest evaluates the rescan at scan level rather than finding by finding, so it keeps the vulnerability open whenever the rescan still returns results on that target.
What you can do
Run it from any finding’s detail page, then read back the recorded task: scanner, target, status, structured result, error and start and end times.
Retest findings from Nessus, Acunetix and Burp Suite with finding-level matching, and from OpenVAS with a scan-level rescan, in each case using the engine that reported them.
Manual mode resolves the host by exact IP membership and looks for a successfully completed patch job on that specific machine. If no agent can be resolved for the target IP, the finding is left open and flagged for a manual check rather than being closed.
See totals for fixed, still present and failed runs, so repeated attempts on the same finding are visible in one place.
Query a retest task’s status over the API, and call a health endpoint that lists the scanner types the retest service supports.
The autonomous engine uses retest as one of its verification layers, so a machine-driven fix still has to survive an independent check before it closes.
External pentesters stay scoped to their own manually-entered findings. They cannot retest anyone else’s.
An inconclusive verification is retried a bounded number of times, then routed to human review and explicitly recorded as “needs manual verification” rather than being counted as a failure or a success.
Who it is for
SOC analysts get an evidence trail instead of a claim, and can tell at a glance which “fixed” findings have actually been proven. System administrators and patch owners stop being asked to re-do work that was never verified, and get a clear signal when a fix genuinely did not take. CISOs get remediation numbers that mean something, because the resolved count is backed by scan results rather than closed tickets. Compliance officers get a dated, per-finding record of each verification attempt, kept in the platform and retrievable over the API. External pentesters can re-verify their own reported findings without being handed access to the whole estate.
Why it matters
Verification is the difference between a vulnerability programme and a vulnerability spreadsheet.
Without it, every metric you report is unfalsifiable, and the cost shows up as rework: the same finding triaged, assigned, planned and patched two or three times across reporting periods.
It also matters because automation without a trustworthy stop condition is dangerous. An autonomous remediation loop that believes its own success reports will happily mark an estate clean. SITEY’s verification path deliberately does the opposite: when a check reports the vulnerability is still open after a fix, it can automatically roll the change back from the pre-change snapshot, where one was taken, and hand the case to a human rather than closing it.
One specific failure mode is worth calling out, because it is the one that quietly corrupts closure data: vulnerability names repeat across a fleet. A finding named “SMBv1 Enabled” exists on dozens of hosts. Manual verification in SITEY binds evidence to the specific agent, preferring a direct vulnerability identifier link and falling back to a note match only within the same machine, so a fix completed on one server can never close the same-named finding on another.
Works with
- Patch Management, the fixes whose success Retest is there to prove, and the source of the completed jobs manual verification reads as evidence.
- Autonomous Operations, uses scanner retest as a verification layer, and triggers rollback and human escalation when verification says the finding is still open.
- Vulnerability Lifecycle: owns the statuses that retest writes: awaiting retest, open, resolved.
- Scanner Integrations, supplies the scanner connections that retest re-uses to re-run the original check.
Frequently asked questions
Which scanners can be retested automatically?
Nessus, Acunetix and Burp Suite each have a dedicated retest path that launches a scan and matches the specific finding in the results. OpenVAS also has a retest path that launches a rescan, but its outcome is judged at scan level rather than finding by finding. Manually entered findings, and findings from any source without a dedicated retest path, fall back to agent-based verification, which checks whether a completed remediation job exists on that exact host. If no agent can be resolved for the target IP, that check leaves the finding open and marks it as needing a manual check.
Does a retest close the finding by itself?
A retest run writes the status directly: matched means open, not matched means resolved. In the autonomous flow there are extra guards, if the verification says “closed” but the remediation batch actually failed with no successful jobs, closure is blocked and the case is escalated instead.
What happens if the scanner is unreachable when a retest runs?
The connectivity check retries with backoff and a circuit breaker. If the scanner still is not ready, the retest task is recorded as failed with the error message, and the vulnerability’s status is left exactly as it was. A retest that could not run never produces a closure.
Can a retest confuse two similar findings?
Matching is deliberately conservative. Nessus matches consider only high and critical severities and compare CVE, plugin name and port. Acunetix and Burp require at least two of name, endpoint, parameter and severity to agree. Agent-based verification requires the evidence to belong to the same host, and refuses to resolve a host when an IP is ambiguous rather than guessing. The OpenVAS path is the coarse one: because it does not compare finding by finding, it errs towards leaving the vulnerability open rather than closing it.
If your remediation numbers are built on closed tickets rather than re-run scans, Retest & Closure is the control that replaces the assumption with evidence, installed on your own infrastructure, using the scanners you already run. See what a full SITEY deployment includes on the pricing page.