Use this skill when an authorized penetration tester, red team operator, or security consultant needs to document and draft findings from a completed authori...
--- name: pentest-findings-report description: > Use this skill when an authorized penetration tester, red team operator, or security consultant needs to document and draft findings from a completed authorized engagement into a structured penetration test report. Covers executive summary, technical findings with CVSS scoring, proof-of-concept summaries, impact analysis, remediation roadmap, and appendices. Produces a DRAFT report for lead tester review before client delivery. --- # Pentest Findings Report Convert raw authorized engagement findings into a structured, client-ready penetration test report aligned to PTES and OWASP Testing Guide documentation standards. ## Flow ### Phase 1 — Engagement Metadata Ask for and record: - Engagement name and reference number - Client organization and primary contact - Scope: in-scope assets (IP ranges, domains, applications, physical locations) - Explicitly out-of-scope assets - Rules of engagement summary - Testing window (start and end dates) - Testing team (lead tester, testers, reviewer) - Report classification level (Confidential / Restricted) ### Phase 2 — Executive Summary Inputs Ask for: - Overall risk rating (Critical / High / Medium / Low) - Finding counts by severity tier - One-paragraph business context for why this assessment was conducted - Top 3 Critical/High findings to highlight for leadership - One-to-two sentence overall security posture statement for the CISO audience Draft the Executive Summary now. Ask the tester to confirm before continuing to Phase 3. ### Phase 3 — Findings Intake For each finding, collect in order: 1. Finding title (clear and descriptive) 2. Severity (Critical / High / Medium / Low / Informational) 3. CVSS 3.1 Base Score and vector string — if not provided, prompt for the required base metrics; label estimated scores as "Estimated" 4. Affected asset(s) 5. Vulnerability description: what the vulnerability is and its root cause 6. Proof-of-concept evidence summary: screenshot filenames, command output references, HTTP request/response references — no working exploit payloads or shellcode 7. Business impact in plain language: what an attacker can achieve with this vulnerability 8. Remediation recommendation: specific and actionable 9. References: CVE, CWE, OWASP category, vendor advisory Ask "Are there more findings to enter?" after each one. When all findings are entered, display the full list and ask the tester to confirm before drafting. ### Phase 4 — Risk Summary Table Build a findings table sorted by severity (Critical → High → Medium → Low → Informational): | # | Title | Severity | CVSS Score | Affected Asset | Status | Ask tester whether any findings are already mitigated or remediated; update Status column accordingly (Open / Mitigated / Remediated). ### Phase 5 — Remediation Roadmap Group remediations by effort tier: - **Immediate (≤30 days):** Critical and High findings - **Short-term (31–90 days):** Medium findings - **Long-term (>90 days):** Low and Informational findings For each tier, list: finding title, recommended action, and responsible team placeholder. ### Phase 6 — Technical Appendices Produce appendix stubs for the lead tester to populate: - Appendix A: Detailed scope and methodology - Appendix B: Testing tool list - Appendix C: Raw finding evidence log (placeholder — tester to attach) - Appendix D: CVSS scoring rationale for Critical/High findings ### Phase 7 — DRAFT Report Assembly Assemble the DRAFT report in this order: 1. Cover page (engagement name, client, dates, classification, version) 2. Table of contents 3. Executive Summary 4. Engagement Overview (scope, methodology, testing window, rules of engagement) 5. Risk Summary Table 6. Technical Findings (one numbered section per finding) 7. Remediation Roadmap 8. Appendices (stubs with placeholders) 9. Lead Tester Review Block Add this block at the end of the document: ``` DRAFT — FOR AUTHORIZED INTERNAL REVIEW ONLY Lead Tester Review: _________________________ Date: ________ Reviewer Sign-off: _________________________ Date: ________ This report documents findings from an authorized security engagement. Do not distribute without lead tester signature. Drafted with AI assistance; human review required before client delivery. ``` ## Key Rules - **Authorization required**: Only document findings from explicitly authorized, scoped testing. If the tester mentions findings on out-of-scope assets, place them in a separate "Out-of-Scope Observations" section and remind the tester to confirm authorization before including. - **No exploit payloads**: Proof-of-concept sections must reference screenshots, log excerpts, or command descriptions — never include working exploit code, shellcode, or attack scripts. - **CVSS accuracy**: Never assign a CVSS score without tester input. Prompt for the required base metrics; label estimated scores clearly. - **Confidentiality**: Mark the report as Confidential. Remind the tester that retention and destruction are governed by the engagement contract. - **AI-generated content notice**: The lead tester review block must be present on every draft before client delivery. - **One finding at a time**: During Phase 3, intake one finding completely before moving to the next. ## Output Format DRAFT penetration test report containing: - Executive Summary (1–2 pages, CISO-readable) - Engagement Overview (scope, methodology) - Risk Summary Table (all findings, sorted by severity) - Technical Findings sections (one per finding: description, evidence summary, impact, remediation, references) - Remediation Roadmap (three tiers by effort) - Appendix stubs (A–D) - Lead tester and reviewer sign-off block All severity ratings, CVSS scores, and impact statements reflect tester-provided inputs. The AI does not independently assess vulnerability severity or compensability. ## Feedback If you encounter an engagement type, compliance framework mapping, or output format requirement this skill doesn't handle, share it at https://github.com/archlab-space/Open-Skill-Hub/issues so the community can improve the skill.
don't have the plugin yet? install it then click "run inline in claude" again.