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

# Findings overview

> View, triage, and manage security findings discovered by your scans

Findings are security vulnerabilities and issues discovered during scans. The findings list is where you review and triage all discovered issues across your assets.

## Viewing findings

Each finding in the list displays:

| Column         | Description                                                                       |
| -------------- | --------------------------------------------------------------------------------- |
| **Finding**    | Name of the vulnerability with a verified indicator                               |
| **Target**     | The target where the finding was discovered                                       |
| **Status**     | Current triage status                                                             |
| **Risk level** | Severity rating (Critical, High, Medium, Low, Info)                               |
| **Source**     | Scanner or source that detected the issue (e.g., Website Scanner, manually added) |
| **Scan date**  | When the finding was discovered                                                   |

### Filtering and sorting

Use filters to focus on what matters:

* **By finding name**: Search by vulnerability name, with partial matching supported
* **By risk level**: View only Critical and High findings, exclude informational items
* **By status**: Track remediation progress (Open, Fixed, Accepted, etc.)
* **By target**: Scope to specific targets
* **By source**: Filter by scanner type or manually added findings
* **By verified status**: Show only verified or unverified findings
* **By scan date**: Filter by when findings were discovered
* **By workspace**: Scope findings to a specific workspace. Hidden by default; enable the column using the **Show all owned workspaces** toggle.

<Tip>
  Start your triage by filtering for Critical and High severity findings.
</Tip>

## Finding details

Select any finding to view full details:

* **Risk level**: Current severity rating (Critical, High, Medium, Low, Info)
* **Status**: Current triage status (Open, Fixed, Accepted, Ignored, False Positive)
* **Verified**: Whether the finding has been manually confirmed

All three can be changed directly from the detail view. Each change optionally includes a reason, which is recorded and applied to duplicate findings in the same group.

* **Description**: What the vulnerability is and why it's a security concern
* **Evidence**: Proof of the vulnerability (request/response data, screenshots, payloads)
* **How to reproduce**: Steps to reproduce the vulnerability
* **Risk description**: Explanation of the potential impact
* **Recommendation**: Guidance on how to fix the issue
* **References**: Links to CVE entries, CWE classifications, OWASP documentation

Additional metadata fields include Port, Protocol, Service, CVSS scores, CVE, CWE, EPSS score, CISA KEV status, and OWASP classifications.

## Actions

### Change status

Update the finding's lifecycle status:

| Status             | Description                        | When to use                           |
| ------------------ | ---------------------------------- | ------------------------------------- |
| **Open**           | Active finding requiring attention | Default status for new findings       |
| **Fixed**          | Remediated and verified            | Issue has been resolved               |
| **Accepted**       | Risk acknowledged                  | No action planned, document rationale |
| **Ignored**        | Intentionally excluded             | Not relevant to current scope         |
| **False Positive** | Not a real vulnerability           | Incorrect detection                   |

<Warning>
  Document all risk acceptance decisions with clear rationale.
</Warning>

### Change risk level

Adjust the severity rating if the automated assessment doesn't match the actual risk in your environment. Consider factors like:

* Business context and asset criticality
* Compensating controls in place
* Actual exploitability in your environment

### How risk level is determined

Risk levels are pre-defined per vulnerability type. SQL injection is always Critical; a missing security header is typically Low or Info. The level is set once when the finding is created, not derived from CVSS.

Two detection engines calculate risk from external scores instead:

| Engine                         | How risk level is assigned                                                                                                                                                                                                                     |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version-based** (Light scan) | Derived from the highest CVSS score in the vulnerability database for detected software versions: CVSS ≥7 → High, 4–6.9 → Medium, \<4 → Low. Version-based findings are capped at High; Critical is not assigned from version detection alone. |
| **OpenVAS**                    | Mapped from the CVSS score in the OpenVAS database: ≥9 → Critical, ≥7.5 → High, ≥4 → Medium, 0 → Info, otherwise → Low.                                                                                                                        |
| **Nuclei**                     | Uses the severity field defined in each Nuclei template (critical, high, medium, low, or info).                                                                                                                                                |

CVSS scores (v2 and v3) are stored on the finding as reference data when available. They are shown in the finding detail on the Findings page and returned by the API. They are not recalculated after a finding is created.

The platform tracks two risk level values: the original scanner-assigned level and the current level (which you may have changed). To revert an override, select **Reset** from the risk level dropdown.

### Add notes and comments

Document your findings with:

* Validation details and reproduction steps
* Remediation notes and progress updates
* Team communication and handoff information

### Rescan to verify fixes

<Steps>
  <Step title="Apply the fix">
    Implement the recommended remediation.
  </Step>

  <Step title="Rescan the target">
    Run a targeted scan to verify the fix worked.
  </Step>

  <Step title="Update status">
    Mark as Fixed if remediation is successful.
  </Step>
</Steps>

### Bulk operations

Select multiple findings to apply changes in bulk. Available operations appear in the toolbar.

| Operation                                                 | What it does                                                     |
| --------------------------------------------------------- | ---------------------------------------------------------------- |
| **Change status**                                         | Set the same status on all selected findings                     |
| **Change risk level**                                     | Override severity for all selected findings                      |
| **Change verified**                                       | Mark selected findings as verified or unverified                 |
| **Send to [Jira](/docs/capabilities/integrations/jira)**       | Creates one Jira ticket per selected finding                     |
| **Send to [Nucleus](/docs/capabilities/integrations/nucleus)** | Sends selected findings to a Nucleus project                     |
| **Clone**                                                 | Duplicates each selected finding                                 |
| **Delete**                                                | Removes selected findings (manually added and Burp imports only) |
| **Generate report**                                       | Creates a report from the selected findings                      |

<Note>
  Status, risk level, and verified changes automatically propagate to duplicate findings in the same group.
</Note>

<Warning>
  Findings created by scans cannot be deleted from the findings list. To remove them, delete the scan that produced them.
</Warning>

## Add manual findings

<Info>
  Manual findings are available on the **Pentest Suite** plan. [View plans](/docs/account-billing/plans-and-limits/plan-overview)
</Info>

Create findings manually for vulnerabilities discovered through manual testing that automated scanners can't detect. Use [finding templates](/docs/core/findings/templates) to standardize documentation and save time.

## Deduplication

When running multiple scans, the same vulnerability may be detected more than once. Findings are automatically grouped as duplicates when they match on:

* Vulnerability type
* Location (same asset and URL/endpoint)
* Affected parameter

<Note>
  Deduplication groups findings but doesn't delete them. You can always see the full history.
</Note>

## Reporting

Generate reports directly from selected findings in multiple formats (PDF, DOCX, HTML, XLSX, CSV, JSON).

<Card title="Reporting" icon="file-lines" href="/docs/capabilities/reports/reporting-overview">
  Learn how to generate reports, create templates, and export findings.
</Card>

## Related topics

* [Finding templates](/docs/core/findings/templates): standardize finding documentation
* [Reporting overview](/docs/capabilities/reports/reporting-overview): generate reports from findings
* [Jira integration](/docs/capabilities/integrations/jira): create Jira tickets from findings
* [Nucleus integration](/docs/capabilities/integrations/nucleus): send findings to Nucleus
* [Burp Suite integration](/docs/capabilities/integrations/burp): import Burp findings into the platform