# Findings & severity

> What a finding contains, how severity and confidence are decided, and what to do with one.

A finding is a vulnerability RedNest can back with evidence. If it can't show how an attacker gets in, the path through your code and what they get, it doesn't report it.

## What a finding contains

- **Title, severity and confidence**, and a CWE tag when one fits.
- **What the attacker gets**, in one plain sentence.
- **Who can exploit it**: anyone on the internet, any signed-in user, an insider, or an admin.
- **Entry point**: the route, handler, job or command where the attack starts.
- **Attack path**: each step from the entry point to the vulnerable code, with its file, line and a short code excerpt, linked to the line on GitHub.
- **Proof of concept**: the request, payload or input that triggers it.
- **The fix**: what to change, what the fix must guarantee, what it must not break, and a regression test that reproduces the attack.
- **A fix prompt** for your coding agent. See [Fixing with your agent](https://rednest.tech/docs/fixing).
- **Where it came from**: the pull request review or deep scan that found it, and when it was first and last seen.

## Severity

Severity is **who can exploit it × what they get**.

| Severity | Meaning |
| --- | --- |
| Critical | Unauthenticated remote code execution, takeover of any account, access to a whole data store, or taking money or paid service at will |
| High | Any signed-in user can read or change other people's data, escalate their privileges, obtain secrets, or get paid features or credits for free; or one cheap request forces you into far more work or spend |
| Medium | Exploitable, but with limited impact or uncommon preconditions; or an endpoint meant to be public has no rate limit in the application |
| Low | Defence in depth: worth fixing, not directly exploitable for much |

Two rules keep severity honest:

- A finding has to harm someone other than the attacker. Breaking your own account isn't a vulnerability.
- An endpoint that is public by design and has no rate limit is medium at most. It is rated higher only when the missing limit enables something worse, such as brute-forcing logins or running up your bills.

RedNest uses CWE tags but not CVSS scores. Severity is shown as a four-step heat meter in the dashboard.

## Confidence

Confidence is separate from severity. It says how sure the skeptic is that the attack works, after trying to disprove it: **high**, **medium** or **low**.

Low-confidence findings are hidden by default. They are never posted on pull requests, never fail a Check and never trigger an email. To see them, turn on **low confidence** in the [Findings](https://rednest.tech/dashboard/findings) filters.

## Statuses

| Status | Meaning |
| --- | --- |
| Open | Still exploitable, as far as RedNest knows |
| Fixed | A fix check showed the attack path is gone, or someone pressed **Mark fixed** |
| Dismissed | Someone dismissed it as a false positive, an accepted risk, or won't fix |

- Dismissing asks for a reason. If a later scan finds the same finding again, it stays dismissed and doesn't fail pull request Checks. A change that makes it look like a different finding can still raise it again (see [Duplicates](#duplicates)).
- **Reopen** puts a fixed or dismissed finding back to open.
- **Code moved** means a fix check couldn't find the cited code any more. The finding stays open, and the mark clears when a later scan finds the same finding again.

## When code excerpts are deleted

A finding's code excerpts, and the stored fix prompt that quotes them, are deleted when:

- the finding is fixed or dismissed (a dismissed finding stays without code even if a later scan finds it again)
- its repository is removed from the GitHub App's installation
- the App is uninstalled or suspended

The finding itself stays, so your history and counts survive. A reopened finding has no excerpts, and a fix prompt written without code, until a later scan finds it again. A fixed finding that comes back gets its excerpts back with it.

## Duplicates

The same vulnerability found again, by a later pull request or deep scan, updates the existing finding instead of creating a new one. RedNest recognizes it by the kind of issue, the file and function with the vulnerable code, and that code itself, not by line numbers. Moving code within a file doesn't create a duplicate, but moving it to another file or function, or editing the vulnerable line, can show up as a new finding.

## The Findings screen

[Findings](https://rednest.tech/dashboard/findings) lists open, fixed and dismissed findings across every repository you can push to. Filter by severity and repository, and turn low-confidence findings on or off. Each finding's page has the full attack path, the proof of concept and the fix. Open findings also have the fix prompt and the **Mark fixed** and **Dismiss** actions; fixed and dismissed ones have **Reopen**. **Copy N findings** hands everything the list shows to your coding agent, or copies it as Markdown or JSON; see [Many findings at once](https://rednest.tech/docs/fixing#many-findings-at-once).