Vulnerability Management

Everything the engines produce lands in one place, already deduplicated and already carrying the evidence a developer needs to fix it. The Vulnerabilities page is where findings are triaged, owned and closed.

The lifecycle of a finding

1. 01
   Ingest

   Findings from AI Native SAST, dependency reachability, secrets, AI DAST, AI Pentest and the classic scanners are normalised into one vulnerability record, with the product, target, scanner and scan run attached.

2. 02
   Correlate

   Identity keys collapse the same issue across engines and across runs. A recurrence reopens the original record instead of creating a second one.

3. 03
   Validate

   Each finding carries its validation record: the exploitable verdict, risk score, confidence, rationale and reported exploitation references — plus the code-flow diagram where one applies.

4. 04
   Prove

   Generate a proof of concept, edit it, and run it in a sandbox. See the next page.

5. 05
   Manage

   Status, owner, due date, tags, references, evidence, solution and lifecycle notes.

6. 06
   Report

   Search, filter, and export to XLSX.

Finding identity

What counts as "the same finding" depends on the scan type. This is the key that drives both in-scan deduplication and recurrence detection across runs:

The dashboard

The page opens on a summary: scanned products, scanned repositories, total open vulnerabilities and scans executed, with a severity breakdown across critical, high, medium and low/info. Below that sit Top 10 Most Vulnerable Targets and Top 10 Vulnerabilities, both filterable by severity.

Working a finding

Each record carries the fields you would expect to triage with:

Status can be changed inline from the list, and findings can be added by hand for issues found outside a scan — a pentest report, a bug bounty submission, a code review.

Search, filter and export

• Full-text search across CVEs, titles and targets.
• Filters by product, severity and status.
• One-click Export to XLSX.