Skip to main content
Gecko scans the same repository many times: on demand, on a schedule, and on every pull request. This page explains what each new scan does to the findings you already have, so you can predict when a finding stays open, closes, or comes back.

​
A finding is tracked across scans

Every finding has a fingerprint built from its vulnerability type and the code it lands in. When a later scan reports the same issue in the same repository, Gecko updates the existing finding instead of creating a new one:
  • Last seen moves to the new scan.
  • The status, notes, tickets, and activity history stay on the finding.
  • A longer or better-proven call chain replaces the old one.
Because identity is per repository, the same issue found by a single-repo scan and later by a multi-repo scan is still one finding.

​
A scan not finding something does not close it

Gecko’s analysis is agent-driven, so two scans of the same code do not always report exactly the same set of issues. For that reason, a deep scan that simply doesn’t report a finding leaves it Open. A finding only moves to Fixed when there is positive evidence that it’s gone. There are four ways that happens:

​
Fix detection

Fix detection is an opt-in setting that rechecks your open findings every time a deep scan runs, and closes the ones that have been fixed in the code. Turn it on in Settings > Scanning, under Scanner: Fix detection (“Re-verify open findings on each scan and automatically mark the ones that have been fixed”). It’s available on the Pro and Enterprise plans and is off by default. When a deep scan (manual, scheduled, or API) finishes, Gecko:
1

Collects candidates

Every Open finding in the scanned repositories that this scan did not report again.
2

Skips findings a person owns

A finding is left alone if it has a linked ticket, has a fix in progress, or isn’t Open (for example In Progress, False Positive, or Accepted Risk). Findings that came from a pull request that hasn’t merged are also skipped, because that code isn’t on the scanned branch.
3

Re-reads the code

An agent revisits the original source-to-sink path on the scanned commit and decides whether the vulnerability is still reachable.
4

Closes only on strong evidence

The finding is marked Fixed only when the verdict is high-confidence and backed by evidence from the code. Anything uncertain stays Open.
Each closure is logged on the finding’s Activity tab with Gecko as the actor, the explanation of why the path is no longer exploitable, and the commit that fixed it (linked for single-repo scans).
Fix detection runs on deep scans only. Pull request scans close findings their own way, described below.
Fix detection checks the branch that was scanned. To confirm a fix you merged into main, scan main (or let its schedule run), not the feature branch the fix was written on.

​
Pull request rescans

A PR scan reviews the changes in one pull request. When the PR is scanned again, for example after you push a fix to it, findings from that PR that the new scan no longer reports are marked Fixed with the note “Marked fixed after a pull request scan no longer detected this finding.” Whether new pushes trigger a rescan depends on PR Scan Trigger in Settings > Pull Requests: Every Push rescans on each commit, PR Open & Reopen (the default) scans when the PR opens or is reopened.

​
Regressions reopen findings

If a finding is Fixed and a later scan detects it again, Gecko reopens it and logs “Reopened after a scan detected this finding again.” The finding keeps its history, so you can see when it was fixed and when it came back.

​
Your triage decisions persist

Statuses you set by hand survive future scans:
  • False Positive findings stay closed and hidden when the issue is detected again. They are never reopened automatically.
  • Accepted Risk findings keep their status when detected again.
  • In Progress findings are not touched by fix detection.
See False positives and missing context for how to stop Gecko from reporting the same false positive in the first place.

​
At a glance