Yes. Many systems close a finding when the next scan does not report it. If that scan failed, timed out or covered less than before, findings vanish without any fix. Guard against it by closing findings only after a complete scan, and by checking scan health alongside the closure rate.
How it happens
Auto close logic usually reads: a finding that was open and is not seen in the latest scan is resolved. That rule assumes the latest scan looked at everything the previous one did. Real pipelines break that assumption in ordinary ways.
- A scan times out and uploads partial results.
- A lockfile moves, so the scanner finds no manifest and reports zero components.
- A credential expires and a registry or private package source cannot be read.
- A scan configuration change narrows the paths or ecosystems.
- A job is skipped, and the old results are kept but the dashboard shows the run as current.
Each of these can drop a repository from a hundred open findings to none overnight.
Signs in the data
- A sudden step down in open findings with no matching increase in fix commits or merged pull requests.
- Components counted per scan dropping sharply for a repository.
- Scan durations far shorter than usual.
- Repositories with zero components, which is rarely true.
- A spike in findings that later reopen.
Safer closure rules
- Require scan completeness. Record a status for each scan: complete, partial or failed. Only complete scans can close findings.
- Compare component counts. If the number of components in a scan falls below the previous scan by more than a set threshold, hold closures and raise an alert for review.
- Record the reason for closure. Use distinct states such as fixed by version change, removed component, suppressed, and not seen. "Not seen" should be a holding state with a delay, not a final one.
- Delay final closure. Wait for a second complete scan before marking not seen findings as resolved.
A quick audit you can run today
Take the findings closed in the last month. For each, find the evidence of the fix: a version change in the lockfile, a removed dependency, a code change. Sort them into supported and unsupported. A high unsupported share means your closure rate is partly an artefact of scan health, and the metric needs repair before it goes into any report.
Report the denominator of health
Alongside the closure rate, show the share of scans that completed successfully. Together they tell a truthful story. A closure rate that rises while the completion rate falls deserves a hard look.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Fix pull requests and version changes give independent evidence that a finding was closed because of a fix. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Should not seen findings reopen automatically?
Yes. If a later complete scan reports the finding again, reopen it and record that the earlier closure was not supported by a fix.
What is a quick sign of a broken scan?
A repository whose component count suddenly drops, often to zero, with no matching change in the code.
Last reviewed: 19 October 2026.
