Analysing Scan Results

Use results pages in this order: Activity, Statistics, Attack Paths, Exploit Graph, then Reports.

1. Confirm the Scan Finished

Open Activity -> Activity.

Check:

• module status;

• failed or cancelled submodules;

• max runtime cancellations;

• agent disconnects;

• browser session failures;

• target blocking or rate-limit events.

Do this before judging coverage. A partial run can still produce findings, but it should not be treated as complete coverage.

Activity

2. Review Statistics

Open:

• Modules -> External Assessment -> Statistics, or

• Modules -> Internal Assessment -> Statistics, or

• Modules -> Code Assessment -> Statistics.

Use Statistics to understand aggregate results:

• total findings;

• severity distribution;

• vulnerability categories;

• affected targets;

• for internal assessments: hosts, services, secrets, and compromise indicators.

• for code assessments: repositories, vulnerable code paths, dependency risk, leaked secrets, and inventory coverage.

Statistics

3. Triage Attack Paths

Open:

• Modules -> External Assessment -> Attack Paths, or

• Modules -> Internal Assessment -> Attack Paths, or

• Modules -> Code Assessment -> Attack Paths.

Start with Critical and High findings. For each finding:

1. Open the finding detail page.

2. Read the summary, evidence, AI reasoning, remediation, and references.

3. Open the attack path drawer.

4. Confirm the graph chain makes sense.

5. Mark the finding Valid, False Positive, or Duplicate.

6. Retest when your team needs fresh verification.

For code assessments, also review the repository, branch or commit, affected files, and whether a fix can be suggested or opened as a pull request.

Attack Paths

4. Inspect the Exploit Graph

Open Dashboard -> Exploit Graph.

Use the graph to answer:

• What did discovery find under this root entity?

• Which assets led to the finding?

• Which browser session, trajectory, test case, or internal host was involved?

• For code assessments, which repository, branch or commit, dependency, file, or inventory component was involved?

• Are there related findings on the same path?

• Does the path cross a boundary your team considers out of scope?

Exploit Graph

5. Generate Reports

Open Reports after triage is complete.

Before generating:

• resolve obvious false positives;

• mark duplicates;

• confirm report root entity;

• decide whether full output is needed;

• choose severity filters for comprehensive reports.

Reports

What Not to Miss

• Authenticated findings should identify the browser session or role used.

• Code assessment findings should identify the repository, branch or commit, and affected file or dependency.

• Code assessment inventory should be reviewed from Modules -> Code Assessment -> SBOM before sharing SPDX, CycloneDX, or AI-BOM exports.

• Internal findings may require cleanup or credential rotation even if they are later marked duplicate.

• A clean scan is not proof of no risk if discovery, browser sessions, agents, or submodules failed.

• Scheduled scans should be reviewed against approved scope and browser-session validity.