How to Turn WormGPT AI Findings Into Client Reports

Reports Are Written During the Engagement

The worst reporting workflow is the one where the report is written in the last three days from memory, screenshots and a terminal history. Evidence is missing, severity is guessed, and reproduction steps are reconstructed rather than captured.

In an AI-assisted workflow the report is a by-product of the work: findings were structured when they were created, evidence was attached when it was validated, and export is a formatting step.

Step 1: Structure Every Finding at Creation

A finding is only reportable if it carries:

• Title in the form "class in component" — "Blind SQL injection in report export".
• Location — file, function, endpoint, parameter.
• Classification — CWE, OWASP Top 10, CVSS 4.0 vector.
• Trace — source to sink, with the sanitisation (or absence of it) named.
• Evidence — request and response, or the sandboxed PoC and its output.
• Prerequisites — authentication level, configuration, network position.

If a field is empty at finding-creation time, it will be empty in the report. Fill it then.

Step 2: Write Impact in Business Language

Two versions of the same finding:

Technical: "Union-based SQL injection in the sort parameter of the /api/reports/export endpoint."

Business: "Any authenticated analyst can read every row in the customer database through the report export, including records for tenants they are not assigned to."

Both are needed. The technical statement lets engineers fix it; the business statement lets the reader decide how fast. Report the business version first.

Step 3: Select Evidence Deliberately

Attach what proves the claim, not everything the sandbox captured. One request/response pair per finding, plus the PoC script. Redact tokens, cookies, real customer data and internal hostnames before export — and note the redaction so a reader does not think evidence is missing.

Step 4: Order by Risk, Group by Theme

Order the findings by chain-adjusted severity, then group by theme for the remediation section: authentication, input handling, authorisation, secrets, configuration. Engineers fix themes; executives read order.

Step 5: Make Recommendations Fixable

Every finding gets one specific recommendation, not a lecture. "Parameterise the query in reports/export.js line 84 and validate the sort value against an allow-list" is fixable on Monday. "Improve input validation across the application" is not.

Step 6: Export and Version

Export Markdown for the report body, JSON for the tracker import. Include the export date and the workspace name in the filename — clients file these documents for years, and "report-final-v3.docx" ages badly.

Key Takeaways

• Structure findings at creation; the report writes itself from structured data.
• Lead with business impact, then give the technical detail.
• Attach minimal, redacted evidence that reproduces the claim.
• Order by chain-adjusted risk and group remediation by theme.
• Give one specific, fixable recommendation per finding.

FAQ

How long should writing the report take? If findings were structured during the engagement, export and narrative take an afternoon. The multi-day report is a symptom of undocumented analysis.

Should the client see exploit paths? Generally yes — they are the strongest argument for prioritising fixes. Redact payload specifics if the agreement requires it.

Can the AI write the executive summary? It can draft from the structured findings, but the risk framing and the recommendation about what to fix first are judgement calls that belong to the engagement lead.

What format do clients prefer? Most want a PDF narrative plus a CSV or JSON export for their tracker. Produce both from the same workspace so numbers match.