Skip to main content
Gecko only reports a finding when it has traced a path from attacker-controlled input to a dangerous operation and is confident the path is real. Most false positives come from context Gecko can’t see in the code it was given: a check that lives in another service, a gateway in front of the app, or a deployment assumption. This guide covers how to dismiss those findings and how to supply that context.

​
Dismiss a finding

Open the finding, click the status in its header, and choose: The status applies immediately. Record the reason as a note on the Activity tab (“Leave a note…”) so the next reviewer knows why. When you dismiss through the API or an AI agent, a reason is required and is logged with the status change.
Dismissals persist. Gecko tracks each finding across scans by its fingerprint, so a False Positive stays closed and hidden when a later scan finds the same issue, and an Accepted Risk keeps its status. See Re-scans and fix detection.

​
Teach Gecko what it can’t see

If the same kind of false positive keeps showing up, for example across several endpoints or repositories, write a rule instead of dismissing each one. Rules are plain-language instructions that every scan reads, including pull request scans. Create them in the sidebar under Context > Rules > Create Rule:
  • Rule title: a short name, for example “Auth is enforced at the gateway”.
  • Description: what Gecko should know or look for, in your own words.
  • Repositories: All repositories, or only the ones the rule applies to.
Good rules state a fact about your environment and where it’s enforced:
Examples
Rules can also ask Gecko to look harder at something specific to your code, such as “Flag any query that doesn’t filter by organization_id.” Rules apply to scans that run after you save them. Re-scan to see their effect on existing results. See Rules for plan and permission details. When the check that makes a path safe lives in a different repository, such as a shared auth library or an API gateway, scan the repositories together in one multi-repo scan. Click New Scan, then Add Repository for each related repository (up to 20). Gecko analyzes the repositories as one system, so a check in one can rule out a path in another. Each finding still belongs to the repository its code is in.
Scan connected repositories rather than uploaded ZIP files when you can. A ZIP is a one-time snapshot. A connected repository can be scanned on a schedule, scanned on every pull request, and rechecked by fix detection. See Other inputs.

​
Why a scan found fewer issues than you expected

Gecko is tuned for precision over recall. A finding is saved only if the agent rates its confidence 9 or higher out of 10 and its own false-positive check passes. That means:
  • A scan with zero findings is a normal result for well-defended code.
  • A known issue may be missing if Gecko couldn’t prove the full path, often because the source or the sink lives in code that wasn’t part of the scan. Add the related repository to a multi-repo scan, or add a rule that points Gecko at it.
  • Gecko focuses on seven server-side vulnerability classes. Issues outside them, such as dependency CVEs or secrets in code, aren’t reported.
If you expected a specific issue and Gecko didn’t report it, share the scan link with Gecko support. Missed findings are the most useful feedback for tuning the scanner.