Reports¶
Audience: All client users (with access to the assessment) · Where: the Reports tab inside an assessment.
Overview¶
The Report is the formal, client-ready deliverable for an engagement — the document you'd share with leadership, auditors, or a compliance team. Canima generates it automatically from the engagement's findings and evidence, structured into standard pentest-report sections. You read it in the browser, and when a PDF has been rendered you can download it for an offline, shareable copy.
Reading a report¶
Open an assessment and click the Reports tab (Canima takes you straight to the latest report for the engagement). The report opens with:
- The title (e.g. Internal Pentest Report - 192.168.9.1/24) and its status badge, plus the published date once it's published.
- A PDF control (top right) — see Downloading the PDF below.
- A section list down the left — a sticky navigation card. Click any entry to jump to it; the right pane shows the selected section. Your position is stored in the page URL, so a link to a specific section is shareable.
Report sections¶
The report is organized like a professional pentest report: a leadership-friendly Executive Summary up top, a technical body documenting what was tested and what was found, and appendices with supporting evidence. Navigate between sections using the list on the left.
The exact sections vary by assessment type
Internal, external, and web-app reports use different templates, and the template set evolves over time — so treat the section list in your own report as the source of truth rather than expecting a fixed lineup. Sections that would be empty are dropped rather than shown blank. (The Table of Contents shows a placeholder on screen — real page numbers are generated inside the PDF.)
Common anchors you'll usually find:
| Section | What it holds |
|---|---|
| Cover & Confidentiality notice | Front matter for the deliverable. |
| Executive Summary | Leadership-friendly overview, with the most urgent findings called out by ID and CVSS. |
| Methodology / scope | What was tested and how. |
| Attack Narrative | The story of the engagement. |
| Vulnerability Summary | Severity scoreboard and Findings Index (see below). |
| Technical Findings | Each finding in full (see below). |
| Appendices | One or more, with supporting evidence. |
Two of the sections are worth calling out:
Vulnerability Summary & Technical Findings
- Vulnerability Summary — a severity scoreboard (Critical / High / Medium / Low / Info counts, plus a total) followed by a numbered Findings Index that lists every included finding with its severity and CVSS score.
- Technical Findings — each finding as its own document: title, severity and CVSS, a metadata strip (status, category, affected host/parameter, CWE, CVE), then Description, Evidence, Remediation, and — where the tester captured them — a Proof of Concept and vulnerable code snippets with a proposed fix.
Downloading the PDF¶
The button in the top-right corner reflects where the report is in its lifecycle:
| Button | Appears when | Notes |
|---|---|---|
| Download PDF | A PDF has been rendered. | Attach the report to a ticket, email it to stakeholders, or archive it for compliance. |
| Generate PDF | The report is Approved or Published but has no PDF yet. | Runs in the background, usually under a minute; shows Generating… while it works, then a toast confirms the PDF is ready. Kicking off a render is a manager-or-above action. |
| Retry PDF | A previous render didn't finish. | Re-runs the generation. |
Treat the PDF as confidential
It details exploitable weaknesses.
Report status (the pipeline)¶
A report moves through a review pipeline before it's final — the same stages you see on the Dashboard → Report Pipeline card:
| Stage | Meaning |
|---|---|
| Draft | Generated, not yet reviewed. |
| In Review | Being quality-checked. |
| Approved | Signed off internally. |
| Published | Final and available to you. |
An Approved/Published report is the authoritative version to share.
Re-scan Required
A report can also show a Re-scan Required status. Canima's reporting quality gate sets this when a scan came back too thin to stand behind (for example, a phase that stalled before doing meaningful work). Read it as "don't treat this as a clean bill of health" — some areas need a re-scan for full assurance. An existing PDF is still downloadable, but the report won't be re-rendered in this state.
Web-app reports: GitHub write-back¶
When a web-application engagement is wired to a GitHub repository, its report can include a GitHub write-back panel showing whether findings were filed as issues — the status, the repo, how many issues were created, and when it last ran. It's a status readout only; nothing to action from the Reports tab.
Tips¶
Tip
- Start non-technical readers on the Executive Summary; send engineers to the Technical Findings and the report's remediation guidance.
- If the report shows Re-scan Required, treat the coverage as incomplete and plan a re-scan before signing off.
- Attack Surface (ASM) monitoring does not produce a formal PDF report; its results live in the Attack Surface dashboards instead.
Related: Findings · Assessment Overview · Home Dashboard