Vexta's Report Engine: HTML, PDF, Word and Google Docs, One Click Each

A penetration test report generator turns raw scan and verification data into a document a client or program can actually read, without a hunter manually assembling tables and screenshots. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its report engine produces that document in HTML, PDF, Word, Google Docs, Markdown and more from the same underlying scan, each carrying an executive summary and the evidence behind every finding.

What formats does Vexta's report engine produce?

Vexta's report engine covers nine output formats from a single scan: a standalone HTML report with charts, the full scan data as machine-parseable JSON, a print-ready PDF, SARIF 2.1.0 for GitHub and GitLab code scanning, JUnit XML for pipeline test reporters, a native Word document, a native Google Doc, Markdown packages formatted for HackerOne and Bugcrowd submissions, and a diff format for comparing one scan against another to show new, fixed and recurring findings.

That range matters because the audience for a scan's results is rarely one person. A client's executive wants a short summary with a severity breakdown. Their engineering team wants a document they can hand a developer with the exact request and remediation. A bounty program wants a Markdown package shaped for their submission form. One scan, produced once, ends up serving all three without the hunter rebuilding the same content by hand for each audience.

The Word document, built without a third-party library

The DOCX output is hand-rolled: Vexta builds the OOXML package directly rather than depending on a third-party library or an external binary, which means no dependency to keep patched and no licensing question to track. It assembles the content types, package relationships, heading and list styles, and numbering definitions the format needs, then writes the actual document content: a cover page, an executive summary, a severity table, and a per-finding section that includes the proof-of-exploitation evidence, the payload used, remediation guidance, and CWE and CVSS references.

It is tested against Microsoft Word, LibreOffice, and the Google Docs viewer, so it opens cleanly regardless of which of those a client happens to use. The trade-off of building it by hand is that advanced styling like theme colors or custom footers is out of scope, but the deliverable itself, cover through per-finding remediation, is complete.

That matters more than it sounds on a client engagement where you cannot control which software the recipient has installed. Testing against three different readers up front means the document you hand over looks the same everywhere, rather than a layout that only renders correctly on the machine that generated it.

A native Google Doc, not a converted file

Rather than exporting a Word file and hoping Google Docs renders it correctly, Vexta can create the report as a native Google Doc through the Drive and Docs APIs. The OAuth connection for this lives under the configuration and integrations settings, and it requests only the documents and drive.file scopes, meaning Vexta only ever sees the files it creates itself, not the rest of a connected Drive account.

From a finished scan, an export button generates the document and hands back a shareable URL, with native paragraphs, heading styles and tables rather than an embedded image or a converted attachment. For a client who lives in Google Workspace, that means the report opens exactly like any other document their team already collaborates in.

Why the executive summary matters as much as the findings

Underneath the cover page and executive summary, each finding in the DOCX and PDF output gets its own section: the proof-of-exploitation evidence that confirmed it, the payload that triggered it, plain remediation guidance for the team that has to fix it, and the CWE and CVSS references a compliance reviewer will look for. That is the layer a developer works from, distinct from the severity table an executive skims.

Keeping both layers in the same document, rather than a slide deck for one audience and a spreadsheet for another, is what makes the report usable past the first read. Six months later, when someone asks how a specific finding was reached, the answer is in the same file the client already has, not in a hunter's private notes.

Every format in the report engine carries the same executive summary and severity breakdown, not just a table of raw findings. That is what makes the HTML and PDF outputs usable for a non-technical stakeholder who needs to understand exposure at a glance, while the same underlying data still supports the detailed, evidence-backed sections a technical reviewer or developer needs to act on a specific finding.

For a pentester delivering a client engagement, that consistency also matters for credibility: the summary a CISO reads and the per-finding technical detail an engineer reads are drawn from the same scan and the same proof, so nothing in the executive framing can drift from what the technical evidence actually shows.

Choosing the right format for the audience

In practice, the format decision follows the reader. HTML and PDF suit a client deliverable meant to be read start to finish. SARIF and JUnit XML exist to be consumed by tooling rather than a person, feeding straight into a CI/CD pipeline's own reporting. The Markdown package is shaped for bounty platform submission forms rather than a general audience. And the diff format is not really about any single audience; it exists to answer a narrower question across two scans of the same target: what changed.

None of this requires running the scan differently depending on which report you will eventually need. The formats all come from the same scan.json, so picking a different output later does not mean re-testing anything, which is worth knowing before assuming a particular deliverable requires planning ahead. Exactly which formats are available on which plan is worth confirming on the pricing page rather than assumed.

Key takeaways