Rescans and fix verification
How a rescan decides a finding is fixed, what may change a status, and how statuses are exported to ServiceNow.
You fixed something and want the finding closed. This page is what to do, and how to read what comes back.
Confirm a fix
- 01Push the fix
Commit it to the branch you want scanned. ScanSuite reads the code as it stands in that branch.
- 02Select the findings you fixed
On the Vulnerabilities page, tick their rows and click Rescan N findings. The static analysis form opens in Verify Fixes mode with those findings and their product filled in.
- 03Start the scan
A Verify Fixes run reads only the files those findings live in. The scan page shows its progress, and the scan log narrates each decision as it is made.
- 04Read the Status column
Every finding you selected has been reassessed. The table below says what each outcome means.
How to read the result
| What you see | What it means | What to do |
|---|---|---|
| Resolved, with a verified label | An agent read the code and pointed at the lines that fixed it. | Nothing. Hover the verified label for the evidence, or read the closure line in the scan log. |
| Still Open after a fix | The agent looked and still sees the defect, or could not tell either way. | Open the finding and read the verdict in its lifecycle notes. It usually names the line it is still unhappy about. |
| Open, marked red with reopened | It was resolved before and this scan found it again. | Treat it as a regression — the fix was reverted, or it never covered this path. |
| Not in the scan report at all | It was already open and was simply found again. Reports carry only new and reopened findings. | Nothing. The finding is unchanged in the list. |
| Risk Accepted or False Positive | A decision made by the team. Scans never change these, in either direction. | Nothing. Only a person can move them. |
Each confirmation, miss and closure is also recorded in the finding's History, with a link to the scan, and the scan's page counts the findings it closed under auto-closed.
A scan going quiet never closes anything on its own. When a file is analysed and a finding no longer appears, an agent opens the current source and decides. It closes the finding only when it can quote the code that fixed it, or when the file is gone. A finding only the cross-file hunt reported is left out of this unless you select it for a Verify Fixes run.
Which rescan to run
| Mode | What it reassesses | When to use it |
|---|---|---|
| Verify Fixes | The findings you selected, and nothing else. | Day-to-day remediation. Cheapest, and it cannot close a finding you did not tick. |
| Full scan | Every finding in the repository. | A release check, or after a large refactor. One run can close many findings at once. |
| Custom Scope, Incremental Scan, Monitor Changes | Whatever the scope covers. | Routine scanning. These need two quiet scans before a finding is verified, because a narrow scope is weaker evidence. |
Prefer Verify Fixes while you are remediating. It reads a handful of files instead of a repository, and a finding that merely shares a file with one you selected is left alone.
A Verify Fixes run reassesses, and can close, only the findings it was asked about; the log says how many of them it is reassessing. Other findings in the same files are never closed by it. The form also switches off Secrets Detection, Dependency Check, Git history and the cross-file hunt, which look beyond the listed files; you can switch them back on.
Rerun in Scan History repeats a Verify Fixes run with the same findings.
What a scan may do to a status
| Status | What a rescan may do |
|---|---|
| Open, In Progress | Can be resolved by verification, on evidence. |
| Resolved | Reopens automatically if the defect is detected again, and the stale closure evidence is cleared. |
| Risk Accepted, False Positive | Never changed by a scan. |
Every automatic change records how it happened, so you can always tell a closure the scanner justified from one a person made.
Turning automatic closure off
Closing verified fixes is on by default. It is a team setting: on the Teams page, AI tab, How AI handles findings card, set Close findings that are verified as fixed to Off. With it off, rescans still reassess and still log their verdicts — you just have to close findings yourself, and the Verify Fixes form and the scan log will say up front that the run cannot close anything.
This setting covers AI SAST findings. Stored Semgrep findings have their own switch, Close findings a rescan no longer reports, in the Scanner findings in Vulnerabilities card on the Scanning tab.
Reading the scan log
The run names findings rather than counting them, so a decision you disagree with can be traced to the code behind it:
Reassessing only the 1 finding(s) this scan was asked to verify, of 1 selected.
Finding reconciliation: 0 confirmed, 1 covered but not reported (1 at or over the
1-miss threshold), 0 held by an analyst decision, 0 already resolved and still not
reported, 0 outside this scan's coverage.
Verifying 1 finding(s) that this scan covered but did not report: test-java-sast-c4d1f672fc16
Finding test-java-sast-c4d1f672fc16 closed as fixed: fixed (high confidence) |
src/main/java/com/scalesec/vulnado/User.java:40-47 uses the parameterized query
"select * from users where username = ? limit 1" and binds un with setString(1, un).
Fix verification: 1 closed on source-backed evidence, 0 still present, 0 left open and
unverified.| Log term | Meaning |
|---|---|
| confirmed | Reported again by this scan. Stays open. |
| covered but not reported | Analysed and not found. Once a finding reaches the mode's miss threshold, it goes to verification. |
| held by an analyst decision | Risk Accepted or False Positive. Left alone. |
| already resolved and still not reported | Already closed, and this scan agrees. Nothing to do. |
| outside this scan's coverage | The file was not analysed, so the scan concludes nothing about it. |
Sending statuses to ServiceNow
ScanSuite does not connect to ServiceNow; the exchange is a file.
- 01Export
Select a product on the Vulnerabilities page, then Export → ServiceNow XLSX. Each row carries the finding's tracking id as its Vulnerability ID.
- 02Import into ServiceNow
Use the normal import process. Nothing about this step is ScanSuite-specific.
One file does both jobs: open and in-progress findings go as Open, and findings ScanSuite has verified as fixed go as Fixed, so one upload raises what is new and closes what is done. Risk Accepted and False Positive findings are left out, because those decisions belong to the ServiceNow workflow.
The tracking id is assigned once and never recomputed, so the same string names the finding in the console, the scan log, the JSON report and the ticket.
Where this fits
Vulnerability Management covers how findings arrive and who owns them. For the scan modes themselves, see Executing the AI-powered scan and Scheduling periodic and incremental scans.
Last reviewed 2026-09-30