pentest-report-writing

name

pentest-report-writing

description

Turn penetration test evidence, weak drafts, screenshots, scanner output, and notes into reviewer-ready findings and report prose for pentest deliverables. Use when drafting, rewriting, splitting, merging, or polishing findings, executive summaries, scope, methodology, rules of engagement, or related report sections. Do not use for exploit development, active scanning, or generic editing unrelated to security reporting.

Pentest report writing

Turn assessment evidence into clear, reviewer-ready pentest report content for findings and supporting report sections.

Quick Start

• Determine whether the task is a finding or a section.
• Build an evidence inventory before writing.
• Ask targeted follow-up questions if the evidence cannot support the claim.
• Draft as review-ready prose that a consultant could paste into SysReptor.
• Review the draft for evidence quality, scope honesty, and remediation clarity.

Read Only What You Need

• Read references/sysreptor-finding-fields.md when drafting or rewriting a finding for common SysReptor finding areas.
• Read references/sysreptor-report-fields.md when drafting report sections commonly used in SysReptor.
• Read references/report-quality.md when deciding what a good pentest report should sound like.
• Read references/report-structure.md when you need a clean split between executive and technical content.
• Read references/cvss-calibration.md when setting or reviewing a CVSS vector.
• Read references/prompt-rules.md when you need a reusable drafting pattern for a specific task.
• Read references/deinternalization.md when the draft contains internal team references, ticket IDs, or shorthand that a client reader would not understand.
• Read references/anti-ai-writing.md when the prose sounds stiff, promotional, or obviously generated.
• Read references/example-patterns.md when a short example would help.

Workflow

1. Determine the target. Classify both the artifact type and the audience. Choose finding for vulnerability content and section for executive_summary, povzetek_za_vodstvo, scope, methodology, or rules_of_engagement.
2. Inventory the evidence. Extract assets, endpoints, parameters, authentication state, prerequisites, proof of impact, limitations, and remediation clues from the raw material.
3. Calibrate the claim. Separate verified facts, bounded inference, and unknowns before writing. Prefer the narrowest true claim that fits the evidence.
4. Decide grouping. Use a hybrid rule: merge only when root cause, exploit path, and fix ownership are genuinely shared. Split when impact, affected surface, or fix path materially differs.
5. Draft the content. Write the strongest useful prose the evidence supports. Treat SysReptor as the destination for the writing, not as the source of truth for the wording.
6. Run the quality review. Check audience fit, evidence quality, root cause clarity, remediation specificity, and whether scope or engagement limits need to be stated.
7. Run the deinternalization pass. Strip internal references, team jargon, cross-client leaks, and shorthand. Replace with client-facing language or remove. Read references/deinternalization.md.
8. Run the prose pass. Remove generated-sounding phrasing, sales language, vague attributions, and filler. Keep the result formal, factual, and impersonal.
9. Keep the output paste-ready. Favor concise Markdown that can be dropped into the relevant SysReptor finding or report section with minimal cleanup.

Quality Rubric

• Write for two audiences at once. Give leadership business-relevant exposure and priorities. Give engineers enough technical detail to validate and fix the issue.
• Explain the verified weakness, not the scanner. Lead with the issue and the affected surface rather than the tool that found it.
• Tie impact to what was demonstrated. Present the strongest claim the evidence supports, not the largest theoretical consequence.
• Include root cause and corrective action. Make it clear what should change and why, not just what was observed.
• State scope, methodology, and limitations honestly. Do not invent access models, dates, exclusions, or coverage that were not provided.
• Keep evidence concise and reproducible. Include enough proof for validation and remediation, but avoid noisy raw output and transcript dumps.
• Make follow-up obvious. Recommendations and mitigation text should help a reviewer understand how to verify the fix or reduce exposure immediately.

Finding Areas

Most SysReptor designs use some variant of these content areas for a finding:

• title State the root cause and affected surface clearly.
• cvss Use a CVSS v3.1 vector that matches the demonstrated attacker model.
• affected_components List concrete hosts, URLs, endpoints, parameters, roles, or services.
• summary Write one short paragraph explaining what is wrong and where.
• description Explain the technical issue with evidence-backed detail.
• impact Describe realistic business or technical consequence. Do not claim maximum theoretical impact unless the evidence supports it.
• recommendation Give specific remediation guidance, not generic hardening advice.
• references Include relevant CWE, OWASP, vendor, or protocol references. Use an empty list if no useful reference exists.
• replication Give concise reproduction steps with sanitized payloads or commands.
• mitigation Explain how to verify the fix or reduce exposure if full remediation is not immediate.

Treat these as writing targets, not as a hard schema contract. Exact field names and layouts vary by report design.

Section Areas

These are the most common report sections this skill should help draft:

• executive_summary Write for non-technical stakeholders. Summarize the main risks, affected business areas, and overall exposure pattern. Do not include payloads or raw scanner output.
• povzetek_za_vodstvo Produce a faithful Slovene adaptation of executive_summary. Preserve meaning and confidence level; do not add new claims.
• scope Describe the assessed systems, environments, or applications only from known engagement facts.
• methodology Describe the test approach, coverage, and major activity types. Keep the wording honest about what was and was not tested.
• rules_of_engagement Describe constraints, access model, test window, exclusions, and agreed limitations only when the facts are known.

These section names are common SysReptor conventions, not guarantees. Adapt the writing to the target template instead of assuming exact field names.

Prompt Rules

• Always distinguish verified fact, bounded inference, and unknown detail.
• Always explain why the issue matters in the language of the target audience.
• Always make remediation implementation-specific and ownership-friendly.
• Always state limits when access, impact, or exploitability was only partially demonstrated.
• Never anchor the narrative on tool names or scanner signatures.
• Never present hypothetical maximum impact as if it were demonstrated.
• Never invent scope, methodology, access model, or rules of engagement facts.
• Never include secrets, live credentials, or unsafe raw evidence in final prose.

Writing Rules

• Lead with the verified weakness, not with tool names.
• Prefer root cause and consequence over scanner phrasing.
• Use sentence case for finding titles, section headings, and bullet labels in generated report content. Do not Title Case them.
• Prefer direct verbs over padded phrasing like "serves as", "showcases", "underscores", or "highlights".
• Keep reproduction detail sufficient for an engineer to validate and fix the issue, but avoid dumping transcripts or noisy raw output.
• State uncertainty explicitly when impact or exploitability is only partially demonstrated.
• Keep remediation specific to the observed implementation or protocol.
• Use consistent terminology across related findings and report sections.
• Preserve bilingual consistency by treating the Slovene management summary as a controlled adaptation of the English source.
• Keep the tone formal and impersonal. Do not add first-person voice, humor, or personality flourishes.

When Evidence Is Thin

• Ask for the smallest missing artifact that would support the claim.
• Narrow the claim instead of inflating it.
• Prefer a lower-confidence impact statement over a dramatic unsupported one.
• Keep the finding draft usable even if some evidence is missing by flagging the gap directly.

Final Anti-AI Pass

• Ask what makes the draft sound generated instead of written by a consultant.
• Remove inflated significance, vague authority phrases, and ad-style wording.
• Remove chatbot artifacts, generic optimistic closers, and filler transitions.
• Replace Title Case headings or inline bullet headers with sentence case and plain phrasing.
• Keep the revision technically exact. Do not soften a claim that is supported, and do not add personality where the report should stay neutral.