> ## Documentation Index
> Fetch the complete documentation index at: https://gecko.security/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# False positives and missing context

> Dismiss findings that don't apply, and give Gecko the context it needs so they don't come back.

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:

| Status | Use it when |
| - | - |
| **False Positive** | The path isn't exploitable. Gecko got it wrong. |
| **Accepted Risk** | The issue is real, but you've decided not to fix it. |

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](https://gecko.security/docs/api-reference/introduction.md) or an [AI agent](https://gecko.security/docs/ai-tools/overview.md), a
reason is required and is logged with the status change.

> [!NOTE]
>
> 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](https://gecko.security/docs/concepts/rescans.md#your-triage-decisions-persist).

## 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:

```text Examples theme={null}
All /internal/* routes are only reachable from the VPC and sit behind the
api-gateway service, which validates the session JWT before forwarding.

Tenant scoping is enforced in TenantRepository.find(); handlers that call it
are not IDOR-vulnerable even though they take an id from the URL.

We never deploy this repository as a server. It's a CLI used by engineers on
their own machines.
```

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](https://gecko.security/docs/scanning/rules.md) for plan and permission
details.

## Scan related code together

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.

> [!TIP]
>
> 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](https://gecko.security/docs/connect/other-inputs.md).

## 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](https://gecko.security/docs/concepts/findings.md#vulnerability-types).
  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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.