> For the complete documentation index, see [llms.txt](https://copilot-docs.bugbase.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://copilot-docs.bugbase.ai/enterprise/analysing-scan-results.md).

# 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.

{% content-ref url="/pages/QJ9ahgjtOWQNnN87Ivzs" %}
[Activity](/enterprise/activity.md)
{% endcontent-ref %}

## 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.

{% content-ref url="/pages/TJuUXyT5cbg1xFPAH61r" %}
[Statistics](/enterprise/modules/statistics.md)
{% endcontent-ref %}

## 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.

{% content-ref url="/pages/Qq4eYhCnXnWRSOdpI5cq" %}
[Attack Paths](/enterprise/modules/attack-paths.md)
{% endcontent-ref %}

## 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?

{% content-ref url="/pages/SVOgW3WWDsCNP6N3NZ7R" %}
[Exploit Graph](/enterprise/exploit-graph.md)
{% endcontent-ref %}

## 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.

{% content-ref url="/pages/5R9A4WOfbwrPI78VKDKg" %}
[Reports](/enterprise/reports.md)
{% endcontent-ref %}

## 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.