Retests and fixes

Gateway 0.2.0-beta.49 and later close findings on proof. When your team fixes a finding, ask for a retest. If the retest proves the fix, the gateway closes the finding itself. Nobody has to check it again by hand. If a later scan, scheduled or not, finds the same finding, it is reopened. Every step is recorded and can be exported for your auditor.

Open Retests and fixes in the console, or from the scanner: open the session menu (the round button in the bottom-right corner) and choose Retests and fixes. Every role can see the view. Operators and administrators can ask for retests.

What closes a finding

• Only proof closes it. A finding is closed when a retest by the check that found it answers likely fixed. The gateway then sets the finding to resolved in the scanner. It records which retest proved the fix and who asked for that retest.
• These do not close it: a retest that is inconclusive, fails or reproduces the finding, and a verdict from the AI tier alone (the scanner never lets one say "fixed").
• A scan that no longer sees a finding does not close it. The changes view lists such findings as not seen this scan. They stay open until a retest proves them fixed.
• When a proof does not close the finding. If a scan saw the finding again after the retest began, or someone had already changed its status, the retest is recorded as proved fixed, not closed and the finding is left as it is.
• Closing by hand is still possible. People with the right role can still resolve a finding in the scanner, as before. Such changes are a person's triage decision, are recorded as such, and do not count as a closure by proof.

Ask for retests

1. In Open findings, tick the findings to retest. You can tick up to 100 per request. Use Target to show one application and Overdue only to show the findings past their SLA.
2. Click Retest selected. The answer says how many retests were queued and why any finding was not:
   • it is no longer open;
   • a retest of it is already queued;
   • the scanner has no single-request retest for that kind of finding (run a new scan instead);
   • it was found by a signed-in scan. A retest cannot sign in, so it would only ever be inconclusive. Run a fresh signed-in scan of the target with the same credential profile. If the finding is fixed, that scan does not find it again; if it does, retest the new scan's finding.

The scanner's own Retest button on a finding still works. The gateway follows those retests in the same way, so a proved fix closes the finding whichever way the retest was started.

From a terminal:

shakerscan api POST /_enterprise/retests '{"finding_ids":["<finding id>","<finding id>"]}'
shakerscan api GET '/_enterprise/retests?limit=50'

A token that acts for a person can ask for retests in that person's name, and the audit log says the request came through a token.

How queued retests run

• Slots. Each retest holds a licensed slot while it runs, like a scan. Queued retests start as slots free up, oldest first. With two or more licensed slots, one is always left for people.
• Waiting too long. A retest that cannot start within 24 hours (the slots stayed busy, or the scanner was down) is recorded as not retested and is not sent.
• Who it runs as. Each retest is sent as the person who asked for it, and the scanner records it as "person via retest queue".
• Authorization. A queued retest never records an authorization for its target. A passive retest needs none. An active retest runs only while the target has a standing authorization that a person recorded (Targets, Authorize). Without one it is refused and the reason is shown.
• When the person cannot run scans any more. If the person who asked was disabled, or lost the operator role, before the retest started, it is not sent.

Changes between scans

Choose a Target to see what its latest completed scan changed since the scan before it:

For recurring scans, History shows the same counts for every run. The counts are stored with the run when it finishes. In a terminal: shakerscan api GET '/_enterprise/findings/changes?target_id=<target id>', optionally with &scan_id=<scan id>.

SLA age

Each open finding shows how long it has been open, counted from when it was first seen. A finding that was reopened keeps its first-seen date. The cards at the top count the open findings of each severity and how many are past their SLA. The overdue findings are listed first.

The default SLAs are critical 7 days, high 30, medium 90 and low 180. Informational findings have no SLA. An administrator can change the SLAs at the bottom of the view; 0 means no SLA for that severity. The change is audited.

In a terminal: shakerscan api GET /_enterprise/findings/open lists the open findings with age_days, due_at and overdue, plus a summary per severity.

Evidence

Export (CSV) downloads every event in the chosen period (the last 90 days by default):

• each retest asked for, sent, refused and finished, with its outcome and the scanner's reason;
• each finding closed by proof, with the retest that proved the fix;
• each closed finding that a later scan found again, with that scan.

Each row names who acted and how (browser, token, or the retest queue). The header gives the organization, installation, licence, who generated the export, the SLAs in force and the period. The last line is the SHA-256 of the data rows. The JSON form (/_enterprise/retests/evidence?from=2026-07-01&to=2026-09-30&format=json) returns pages of 5,000 events; pass after=<next> for the next page. Each export is recorded in the audit log.

This is supporting evidence for PCI DSS 4.0 6.3.1 and 11.3, SOC 2 CC7.1 and ISO 27001:2022 A.8.8. It is not an ASV scan or a penetration test; your auditor or QSA decides.

Export findings

Retests and fixes, Export findings: the findings of the target chosen above (or all targets) as CSV or JSON, filtered by status (open by default; resolved, false positive, accepted risk or all) and severity. Each row: finding id, title, severity, status, target name and URL, URL, first and last seen, proof state, the latest retest (status, verdict, when), the Jira ticket made here and its link, and the link to the finding's page. Never evidence, request or response bodies, or secret values; a cell that starts like a spreadsheet formula is prefixed with '. Every role may export (the same findings every role reads), and so may a service token:

shakerscan api GET '/_enterprise/findings/export?format=json&status=active&severity=critical,high'
shakerscan api GET '/_enterprise/findings/export?format=csv&target_id=<target id>&status=active,resolved'

An export holds at most 20,000 findings (the header says truncated), each is audited (findings.export with its filters and the SHA-256 of its rows), and a person or token may export ten times per rate window.

Where it is stored, backup and rollback

• Where. The records are kept in workflow.sqlite3, together with the recurring scans. They hold identifiers, severities, states, times and the scanner's short reasons. They hold no finding titles, URLs or evidence: those stay in the scanner's database.
• Retention. Records are kept as long as the recurring scans' records (400 days by default). A finding's current closure is kept as long as it applies.
• Backup and restore. backup.sh and restore.sh include the file as they already do for recurring scans.
• Rolling back an update. A gateway update that is rolled back puts the file back as it was before the update. Retests and closures recorded during the update are then missing from the gateway's records, although the findings stay resolved in the scanner. Such a finding is not watched for reopening until it is closed again.