Pentest Report

A standards-compliance layer for penetration-test reports. The skill takes findings (raw notes, structured YAML, or tool exports) and produces an audit-ready report in German or English, validated against a chosen reporting standard.

The competitive position: most existing tools (SysReptor, Ghostwriter, PwnDoc) render reports beautifully but do not check whether the content satisfies a regulatory standard. Most Claude-side pentest skills focus on testing, not on the report. This skill fills the gap between testing tools and rendering tools — it is the polish layer that produces what a BSI auditor, a DiGA reviewer, or an OSCP examiner expects to see — and tells you exactly what is still missing. It assists compliance; it does not certify it.

When to use this skill

Trigger on any of:

• "Schreib mir einen Pentest-Report / Sicherheitsbericht / Schwachstellenbericht"
• "Write up these findings"
• "Convert this nmap/Burp/Nuclei/Nessus output to a report"
• "Make this BSI-konform / OWASP-WSTG-aligned / PCI-DSS-compliant"
• "OSCP exam write-up for these proofs"
• "Re-test report" / "Delta report against last engagement"
• User pastes raw tool output and asks for analysis or write-up

Do NOT trigger if the user wants to actively test or scan something — that is a different skill.

The pipeline

The skill follows a fixed four-stage pipeline. Always announce the current stage to the user so they can intervene early.

1. Ingest — read raw input (notes, screenshots, tool exports) and produce findings.yaml against the internal schema.
2. Enrich — add CVSS (3.1 or 4.0), CWE, MITRE ATT&CK, OWASP-Top-10/WSTG references, dedupe across hosts, link related findings.
3. Compliance-check + quality review — run compliance_check.py for the deterministic structural checklist (PASS / FAIL / MISSING / WARN, incl. BSI classification) and quality_report.py for the Report Quality Score + Missing-Information Detector. Then add the semantic layer that only a model can do (see "Semantic quality review" below). Never call a report ready while a required section/criterion is missing — the score is gated to INCOMPLETE in that case.
4. Render — produce the requested output format(s). Default is Markdown + PDF; user can also request SysReptor JSON. (DOCX export and Ghostwriter push are planned — see ROADMAP.md.)

Semantic quality review (Claude's job, not the script's)

quality_report.py is the deterministic floor: it catches missing and placeholder/too-thin content (empty impact, "TODO", < 40 chars, no evidence, no CVSS). It cannot judge whether prose that looks complete is actually good. That judgement is the main reason this is a Claude skill and not just a linter — so always perform it explicitly before declaring a report done:

• Impact — does it state a concrete business/technical consequence (data exposed, lateral movement, downtime, regulatory breach), or is it a generic filler sentence? Reject vague impact even if it passes the length check.
• Recommendation — is it specific and actionable for this finding (config, version, control), or boilerplate ("apply best practices")? A fix a reader cannot execute is not a fix.
• Description — does it explain the root cause and how it was confirmed, not just restate the title?
• Severity / CVSS plausibility — does the narrative justify the rating? Flag a "critical" with a low-impact story, or vice-versa.
• Executive summary — for management-facing profiles (BSI, DiGA): is it in business language, Sie-Form, free of jargon, with a clear risk verdict?

Surface these as concrete, per-finding suggestions. Do not silently rewrite the user's findings — propose, let the user confirm.

If the user only provides raw input and no profile, ask which standard applies before stage 3. Reasonable default: owasp-wstg-en for web apps, bsi-praxisleitfaden-de for German infrastructure tests.

Internal finding schema

All findings, regardless of origin, normalize into this schema. Persist as findings.yaml.

engagement:
  id: ENG-2026-042
  client: ACME GmbH
  scope:
    - 192.168.10.0/24
    - app.acme.example
  type: infrastructure       # infrastructure | webapp | api | mobile | ad | cloud | redteam
  authz_reference: ./authz.pdf
  start: 2026-06-10
  end: 2026-06-14
  testers:
    - name: K. Beispiel
      role: Lead

findings:
  - id: F-001
    title_de: Schwache TLS-Konfiguration auf app.acme.example
    title_en: Weak TLS configuration on app.acme.example
    severity: high           # info | low | medium | high | critical
    cvss:
      version: "4.0"
      vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
      score: 6.9
    cwe: [CWE-326]
    owasp_top10: [A02:2021]
    wstg_id: WSTG-CRYP-01
    mitre_attack: [T1040]
    affected:
      - host: app.acme.example
        port: 443
        evidence: testssl.sh-out.txt
    description_de: |
      Der Server akzeptiert TLS 1.0 und TLS 1.1 ...
    description_en: |
      The server accepts TLS 1.0 and TLS 1.1 ...
    impact_de: |
      Ein Angreifer in einer Man-in-the-Middle-Position kann ...
    impact_en: |
      An attacker in a man-in-the-middle position can ...
    recommendation_de: |
      Konfigurieren Sie den Webserver, ausschließlich TLS 1.2 ...
    recommendation_en: |
      Configure the web server to accept only TLS 1.2 ...
    references:
      - https://datatracker.ietf.org/doc/rfc8996/
    status: open             # open | mitigated | accepted | resolved
    retest: null

The dual-language fields are not auto-translations. Both languages are first-class. If only one is provided, the skill produces only that locale and warns rather than auto-translating.

Profile system

A profile defines what a report must contain to satisfy a standard. Profiles live in profiles/<id>.yaml. Load only the profile the user selects; do not load all of them.

Available profiles:

• bsi-praxisleitfaden-de — BSI Praxis-Leitfaden für IS-Penetrationstests
• bsi-durchfuehrungskonzept-de — BSI 5-Phasen-Modell, I-/E-Module
• owasp-wstg-en — OWASP Web Security Testing Guide
• owasp-asvs-l2-en — OWASP ASVS Level 2
• ptes-en — Penetration Testing Execution Standard
• nist-800-115-en — NIST SP 800-115
• pci-dss-v4-en — PCI-DSS v4 Pentest requirements
• diga-bfarm-de — DiGA / BfArM requirements per DVPMG
• oscp-en — Offensive Security OSCP 24h exam format

A profile YAML declares: required report sections in order, mandatory finding fields, language locale, allowed severity vocabularies, required appendix items, and the template file to use during rendering.

Voice and tone

Reports have three voice registers; the skill picks based on the section:

• Executive voice (Management Summary, Risikoeinschätzung): plain prose, no jargon, business-impact framing. German uses Sie-Form.
• Customer-technical voice (per-finding narrative): technical but explanatory, no swagger. Pre-supposes IT literacy but not pentest expertise.
• Tester-technical voice (Reproduction Steps, Anhang): terse, command-line accurate, no hedging.

See references/voice-style-de.md and references/voice-style-en.md for vocabulary lists and worked examples. Read the relevant file before drafting any prose-heavy section.

German vocabulary note: Schwachstelle, Sicherheitslücke, and Verwundbarkeit are not interchangeable. Default to Schwachstelle for findings, Sicherheitslücke for severe and exploitable cases, and avoid Verwundbarkeit (Anglicism, sounds like a bad translation).

Rendering pipeline

Default render targets:

• Markdown — out/report.md, working copy.
• PDF — via WeasyPrint, styled by templates/styles/<style>.css. Default style is corporate (neutral, B2B-appropriate).
• SysReptor JSON — out/sysreptor-import.json, drop into a SysReptor project.

DOCX export and a Ghostwriter API push are planned but not yet implemented — see ROADMAP.md. Do not advertise them as available.

The render scripts live in scripts/:

• compile_report.py — main entry; takes findings.yaml + --profile <id> + --locale de|en + --out <dir>.
• compliance_check.py — runs profile validation alone (required sections/fields, severity vocab, CVSS↔severity agreement, and — for BSI profiles — the six classification criteria with plausibility WARNings). Useful before rendering.
• quality_report.py — heuristic Report Quality Score (0–100) plus a Missing-Information Detector that lists what is missing/weak per standard and why it matters. Advisory by default; --min-score turns it into a gate.
• render_pdf.py — WeasyPrint wrapper with per-profile CSS.
• export_sysreptor.py — emits SysReptor-compatible JSON.

When the user runs the full pipeline, call compile_report.py. When the user only wants to validate, call compliance_check.py.

Tool-output ingest

Parsers live in parsers/. Each parser reads a tool-specific format and emits partial findings.yaml entries.

Supported parsers:

• nmap_xml.py — nmap -oX output. Maps services → asset list; flags risky ports (Telnet/21, FTP/21, SMB/445 with NULL session, Redis/6379 open, MongoDB/27017 unauth).
• burp_xml.py — Burp Suite issue export.
• nuclei_json.py — Nuclei JSONL.
• nessus.py — Tenable .nessus XML.
• trivy_sarif.py — Trivy SARIF (containers/IaC).
• bloodhound_json.py — BloodHound query exports for AD paths.

A parser produces draft findings, not final findings. The user must review before commitment. Each parser writes to findings.draft.yaml; promotion to findings.yaml is explicit. This avoids silently shipping every scanner false positive.

Deduplication runs after ingest: same CWE + same affected host = one finding with multiple affected entries, not two findings.

Re-test / delta reports

If the user provides a prior findings.yaml and a new one, the skill produces a delta report:

• Resolved findings → moved to "Behobene Befunde / Resolved findings"
• Still-open findings → carried forward with retest: failed
• New findings → flagged as introduced since last test

Pass --mode retest --baseline <path-to-previous-findings.yaml> to compile_report.py.

Folder layout of this skill

pentest-report/
├── SKILL.md                          (this file)
├── references/
│   ├── finding-schema.md             (full schema with field semantics)
│   ├── cvss-guide.md                 (3.1 vs 4.0, vector construction)
│   ├── voice-style-de.md             (German voice + vocabulary)
│   ├── voice-style-en.md             (English voice + vocabulary)
│   └── standards-mapping.md          (CWE ↔ OWASP ↔ MITRE crosswalk)
├── profiles/
│   ├── bsi-praxisleitfaden-de.yaml
│   ├── bsi-durchfuehrungskonzept-de.yaml
│   ├── owasp-wstg-en.yaml
│   ├── owasp-asvs-l2-en.yaml
│   ├── ptes-en.yaml
│   ├── nist-800-115-en.yaml
│   ├── pci-dss-v4-en.yaml
│   ├── diga-bfarm-de.yaml
│   └── oscp-en.yaml
├── templates/
│   ├── report-de.md.j2               (Jinja2)
│   ├── report-en.md.j2
│   └── styles/
│       ├── corporate.css
│       ├── academic.css              (for OSCP / lab reports)
│       └── minimal.css
├── parsers/
│   ├── nmap_xml.py
│   ├── burp_xml.py
│   ├── nuclei_json.py
│   ├── nessus.py
│   ├── trivy_sarif.py
│   └── bloodhound_json.py
├── scripts/
│   ├── compile_report.py             (main entry point)
│   ├── compliance_check.py
│   ├── render_pdf.py
│   └── export_sysreptor.py
└── examples/
    ├── example-findings.yaml
    ├── example-report-de.pdf
    └── example-report-en.pdf

Worked example

User input: "Hier mein nmap-Output und drei Burp-Findings, mach mir nen Report auf BSI-Praxisleitfaden, deutsch."

Skill response:

1. Parse nmap.xml via parsers/nmap_xml.py → 12 draft asset entries, 2 risky ports flagged.
2. Parse burp-issues.xml via parsers/burp_xml.py → 3 draft findings.
3. Ask user to confirm draft findings or edit.
4. Run compliance_check.py --profile bsi-praxisleitfaden-de --findings findings.yaml. Report which BSI-required sections are missing (e.g., "Klassifikation nach BSI-Kriterien" — needs user input for aggressiveness/scope/method).
5. Once compliance passes: compile_report.py --profile bsi-praxisleitfaden-de --locale de --out out/.
6. Present out/report.pdf and out/sysreptor-import.json to the user.

What this skill explicitly will not do

• Run scans, exploits, or any active probing. The user supplies findings; the skill writes them up.
• Certify compliance or guarantee that an auditor will accept the report. It validates structure, consistency and coverage and flags gaps; the final professional sign-off is a human's.
• Invent findings the user did not provide. If a profile demands a section and no data exists, the skill emits a placeholder with a TODO comment, not fabricated content.
• Auto-translate between DE and EN. Translation in legal/audit-grade reports requires human review; the skill warns and stops.
• Ship without a profile selection. The user must consciously pick a standard; the skill never silently defaults to "generic".