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

# Severity model

> Severity ranks the impact of a finding, not how confident the model is. Use it to triage bugs consistently.

# Severity model

Severity describes impact. It does not describe the model's confidence.

A finding can be low severity with high confidence, or critical severity with lower confidence. Severity answers: "How bad would this be if it is real and ships to production?"

## Severity levels

| Severity | Meaning | Examples |
| - | - | - |
| Critical | No special access needed and catastrophic impact | Platform or all-tenant takeover, a secret that grants privileged or cross-tenant access, remote code execution without a privileged account, SSRF that reads cloud credentials. |
| High | Needs an account, or the blast radius is one tenant | Another tenant's records read or changed, auth bypass to a privileged account, injection that reads or changes data, a live secret in a response. |
| Medium | Real issue with a limited reach | Cross-workspace access within one tenant, ids or metadata leaked across a boundary, an effect that needs an already-privileged user, missing rate limit on a sensitive endpoint, functional regression. |
| Low | Hygiene or experience issue that matters mainly as part of a larger chain | A 500 with no data exposure, verbose errors, weak cookie flags, minor UI bug. |
| Info | Useful observation, not a bug by itself | Technology or version disclosure, attack surface note. |

## Reach caps impact

Severity is the worst realistic outcome, capped by who can reach it and how far it goes:

* **Who can trigger it**: anyone, any signed-in account, or only a privileged account; from the internet or only an internal surface. An effect only an admin or an internal surface can reach is medium at most.
* **How far it reaches**: one user, one tenant, or every tenant. Crossing a tenant boundary is what makes a finding high or critical. The same effect within one tenant is medium.
* **What was shown**: a real record body rates higher than ids or an empty list, which rate higher than an error with no data.

Code scan findings are rated the same way. A second pass re-derives severity from reachability instead of carrying the scanner's headline rating, so a vulnerable package used only in tests or tooling is not filed as critical.

## Severity vs confidence

Confidence is the model's belief that the finding is valid. Severity is the impact if it is valid.

Qodex keeps these separate so a finding can be filtered, sorted, and triaged by impact without hiding uncertainty.

## Evidence guard

High and critical findings need stronger evidence. Qodex will not file a high or critical finding from exploration without captured proof of the failure.

This prevents a stale selector from becoming a false critical issue.

## Change severity yourself

Your team has the final say. Open a finding on the Findings page, pick a new **Severity** under **Review**, write why, and click **Save**. A severity change needs a reason. The list then shows a **set** mark beside that severity so readers can tell a person's decision from the agent's rating, and a finding your team already reviewed keeps your severity when it is seen again.

Click the **Severity** column header to sort the list worst first.

## Security scenarios

Security testing uses inverted semantics: pass means the app blocked the attack, and fail means the app may be vulnerable.

Severity for security findings reflects the impact of the successful attack. A BOLA issue that reads another tenant's records is high because it crosses the tenant boundary, even if the test itself is a simple request. The same read between two workspaces of one tenant is medium.

## Related

> [card] [Failure classification](https://qodex.ai/docs/findings-failure-classification.md)
>
> Learn what happens before a finding is filed.

> [card] [Inverted semantics](https://qodex.ai/docs/security-testing-inverted-semantics.md)
>
> Understand security pass and fail behavior.

> [card] [Triage workflow](https://qodex.ai/docs/findings-triage-workflow.md)
>
> Use severity to filter and prioritize findings.

> [card] [Findings concept](https://qodex.ai/docs/concepts-findings.md)
>
> Read the shorter overview.


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