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

# Read an Octopoda finding: severity, proof and location

> Understand each part of an Octopoda finding: its key and severity, what is wrong and why it matters, where it is in your code, and the proof behind it.

Each issue Octopoda proves becomes a finding with its own page in the web app. A finding tells you what is wrong, why it matters, where it is, how Octopoda proved it, and how to fix it. Open one from the **Findings** page, from a scan, from a pull request comment, or with `octopoda fix <key>` in the CLI.

## The parts of a finding

| Part | What it tells you |
| - | - |
| **Key** | A short ID such as `F-142`, unique in your account. Use it with `octopoda fix` and in your AI tool. |
| **Severity** | Critical, high, medium or low. See below. |
| **Status** | New, open, fixed, false positive or risk accepted. See [Triage findings](https://docs.octopoda.dev/findings/triage.md). |
| **Fix it** | A prompt for Cursor or Claude Code. See [Fix a finding with your AI tool](https://docs.octopoda.dev/findings/fix-with-ai.md). |
| **What's wrong** | The issue in plain language. |
| **Why it matters** | What an attacker could do with it. |
| **Where** | The file and lines, with the code highlighted and a link to the line on GitHub for repository scans. For an issue in a route, the method and path. |
| **Proof** | How Octopoda proved the issue. See [How a finding is proven](https://docs.octopoda.dev/how-it-works.md#how-a-finding-is-proven). |
| **Suggested change** | When there is one, the code change that fixes it, as a diff. |
| **Technical details** | The CWE weakness type, the CVSS score and vector, the CVE for vulnerable dependencies, and references. |
| **History** | When the finding was first seen, every scan that saw it again, and every status change. |

## Severity

Octopoda scores each finding with CVSS, the industry-standard scoring system, and maps the score to one of four levels:

| Severity | CVSS score |
| - | - |
| **Critical** | 9.0 to 10.0 |
| **High** | 7.0 to 8.9 |
| **Medium** | 4.0 to 6.9 |
| **Low** | 0.1 to 3.9 |

Fix critical and high findings before you ship. By default, they fail [pull request checks](https://docs.octopoda.dev/scanning/pull-request-checks.md).

A CVSS score describes an issue in general. Where the proof shows that the issue does more damage in your app than the score suggests, Octopoda may rate it one level higher and says why next to the severity, marked **Rated above CVSS**.

## Where findings show up

* The **Findings** page lists open findings across your repositories and CLI uploads, grouped by where they are. Filter by **Severity** and **Status**, or search.
* Each scan page lists the findings that scan proved.
* Pull request comments list the findings for that pull request.
* `octopoda findings` lists open findings in your terminal, and `octopoda findings --severity high` narrows them.


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