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.
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
- 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
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 |
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). |
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
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 | Creates one Jira ticket per selected finding |
| Send to 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 |
Status, risk level, and verified changes automatically propagate to duplicate findings in the same group.
Add manual findings
Manual findings are available on the Pentest Suite plan. View plans
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
Deduplication groups findings but doesn’t delete them. You can always see the full history.
Reporting
Generate reports directly from selected findings in multiple formats (PDF, DOCX, HTML, XLSX, CSV, JSON).Reporting
Learn how to generate reports, create templates, and export findings.
Related topics
- Finding templates: standardize finding documentation
- Reporting overview: generate reports from findings
- Jira integration: create Jira tickets from findings
- Nucleus integration: send findings to Nucleus
- Burp Suite integration: import Burp findings into the platform