After an AI fix, rescan the branch and compare with the baseline in three buckets. Closed means the finding is gone. New means the fix introduced something. Unchanged means it did nothing for that item. Merge only when the target is closed and new findings are explained.
Set a baseline first
You cannot read a diff of results without a starting point. Run the scan on the base branch, save the output, and note the scanner version and configuration. Then run the same scan, same configuration, on the fix branch.
A mismatch in tool version or ruleset can fake both fixes and regressions. Keep them identical.
Read the three buckets
| Bucket | Meaning | Action |
|---|---|---|
| Closed | Present before, absent now | Confirm it is the target finding, and check why it closed |
| New | Absent before, present now | Treat as a regression from the change until proven otherwise |
| Unchanged | Present in both | Fine for unrelated findings, a failure if it is the target |
Three traps to watch
- The finding closed for the wrong reason. A scan can stop reporting something because the file moved, a rule was skipped, or the scan failed to parse a file. Check that the scan completed without errors and covered the same files. A failed scan can look like a fixed vulnerability.
- A moved finding. The same weakness may now be reported on a new line or in a new file with a different identifier. Read the new findings before calling the old one closed.
- A suppression. A comment or configuration entry that silences the scanner closes the finding without changing the behavior. Search the diff for ignore markers. See AI fix silences the scanner.
Do two checks for dependency fixes
For dependency changes, compare the resolved dependency list before and after, not just the manifest. A bump of one package can change several transitive ones. The OSV format records affected ranges with introduced and fixed events, so you can confirm that each package that was flagged is now at or above its fixed event.
OWASP's guidance on secure coding with AI recommends running dependency auditing tools on AI generated dependency lists before merging, and failing the pipeline on known vulnerabilities regardless of who wrote the change.
Record the result
Paste the three bucket counts into the pull request, with the names of the target finding and any new ones. If you keep a decision log, add the outcome. It becomes useful when you want to know how often fixes close what they claim to.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings move between states, which is the same bookkeeping you do by hand after a rescan.
Safeguard's scans and policies can run on pull requests, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
The target finding disappeared. Can I merge?
Only after checking the scan completed, the finding was not suppressed, and it did not move. Then look at new findings.
Sources
Last reviewed: 19 October 2026.
