Findings

Creating a finding

From an engagement → Findings → New (/engagements/<id>/findings/new/). You can also import from the catalogue while creating one, pulling in an approved vulnerability catalogue entry’s content as a starting point instead of writing from scratch. Nothing stops you editing it further afterward.

Fields

Title, severity (Critical / High / Medium / Low / Informational), and status (Open / Closed, whether the vulnerability itself is currently present, independent of the workflow status below).
CVSS score/vector, entered directly or via the built-in CVSS v3.1 and v4.0 calculators.
CVE ID, if applicable.
Classifications, tagging the finding against one or more taxonomies (for example OWASP Top 10 2021 → A01:2021-Broken Access Control). Taxonomy/value pairs are free-typed the first time and offered as autocomplete suggestions afterward, org-wide.
Affects, the affected assets, as free text.
Content sections, a set of rich-text fields (vulnerability description, technical details, business impact, and so on) that are admin-configured per deployment, not fixed. See Finding structure for what controls which sections exist and their order.

The review workflow

Every finding carries a workflow_status, separate from its status (open/closed):

Draft ──submit for review──▶ Reviewed ──submit for QA──▶ QA Approved
  ▲                              │                            │
  └────── changes requested ─────┘◀──── changes requested ────┘

Draft, the starting state for every new finding.
Reviewed, meaning a reviewer has approved it. Changes Requested (Review) sends it back to Draft with review feedback instead.
QA Approved, meaning a second, independent reviewer has QA-approved it. Changes Requested (QA) sends it back to Draft too. Only a QA Approved finding on a released engagement is ever visible in the Client Portal.

Assigning and acting

Assign reviewer / Assign QA needs findings.review / findings.qa to be eligible for assignment. Assigning itself needs engagement access.
Submit review / Submit QA (approve or request changes) needs findings.review (or findings.review_own for your own authored findings) / findings.qa (or findings.qa_own).
Reopen to draft manually pulls a finding back to Draft regardless of its current stage.
findings.act_any_assignment lets someone submit any finding’s review/QA decision, regardless of who it’s actually assigned to. This is useful for a Team Lead covering for an absent reviewer.

Bulk versions of assign-reviewer, submit-review, assign-QA, and submit-QA exist from the findings list, for acting on several findings in one pass.

Archiving

Archive / Unarchive on a finding works the same way as on an engagement: a soft-delete that drops it from default lists without destroying data.

Retesting

Once an engagement moves into remediation testing, log a retest record per finding: Not Retested → Fixed / Not Fixed / Partially Fixed / Risk Accepted. Retest history renders into the report automatically ({{p finding.retest_history }} / {{p finding['retest_history'] }}) on a remediation report, and it’s empty otherwise.

Comments

Every rich-text field on a finding supports threaded, position-anchored comments. Select the relevant text, start a thread, reply, and mark it resolved when addressed. This is how review/QA feedback usually gets attached to the specific sentence it’s about, rather than living in a separate unstructured field.

Scanner import

Findings can also be bulk-created from a scanner’s raw output (Nmap, Burp Suite, Nuclei) instead of one at a time. See Scanner import.