Reports
A full assessment document you can hand to someone who was not at the terminal. A security reviewer, an auditor, or a customer.
Generating one
Add --report with an .html path to a scan:
secureai scan ./prompts --report assessment.htmlThe file is self-contained: fonts, styles, and the logo are embedded. It renders identically offline, on a machine that has never seen SecureAI, and inside an email client that blocks remote content.
Written even when the gate fails
The report is produced before --fail-on is evaluated, so a build that exits 1 still leaves the artefact explaining why. Collect it as a CI artefact unconditionally.
Producing a PDF
Open the HTML in any browser and print to PDF. The document carries real page rules, so pagination, margins, and page breaks come out right rather than being cut mid-section.
- Open the file in Chrome, Safari, Edge, or Firefox.
- Print → Save as PDF.
- Leave headers and footers off; the document supplies its own.
To automate it in CI, use headless Chrome:
google-chrome --headless --disable-gpu \
--print-to-pdf=assessment.pdf \
--no-pdf-header-footer \
assessment.htmlWhat is in it
- Cover: organisation, target, overall score, and the window the assessment covers.
- Executive summary: the posture in prose, for a reader who will not read the tables.
- Scope and metadata: CLI version, run ID, environment, ruleset version and hash, so a result is reproducible.
- Top risks: the findings that matter most, with severity, phase, location, and OWASP category.
- Severity distribution and OWASP breakdown: where the risk is concentrated.
- Per-phase sections: findings from whichever phases ran, each with exploitation detail and a concrete fix.
- Remediation plan: ordered by priority, with the effort each item takes.
Sections adapt to what ran
A report from a BUILD-only run contains no TEST or RUNTIME sections. It does not print empty placeholders for phases you did not run. The executive summary and scope are always present.
Reading the scores
Scores are colour-banded, and the direction differs by metric: BUILD score and SDS are higher-is-safer, while ASR is higher-is-worse. A gold 62 and a gold 12% mean the same level of concern in opposite directions. See Scores & exit codes.
Evidence and sensitive content
Reports covering a TEST run may include the payload that succeeded and, if --allow-store-responseswas set, the model's response. Those responses can contain whatever the attack extracted, including your system prompt. Treat a report with evidence as sensitive and share it accordingly.
Reports in the dashboard
You do not have to use the CLI to get one. The dashboard generates the same document from uploaded results, with the scope and audience picked per role. See Dashboard reports.