redteam-report-template

Solid

Client-facing red-team deliverable format — codifies the Subject / Observations / Description / Impact / Recommendation / PoC structure used for external red-team engagements (not bug-bounty platform reports). Different audience, different tone, different cadence. Built from an authorized engagement deliverable where 14 findings were packaged into a 52KB MD + 2.2MB DOCX with 16 embedded screenshots. Use when the engagement is "external red team for an enterprise client" (not H1/Bugcrowd/Intigriti), when generating the final report, when the client has specified a custom report format, or when packaging findings into DOCX/PDF.

Data & Documents 1,478 stars 216 forks Updated 5 days ago NOASSERTION

Install

View on GitHub

Quality Score: 86/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

## When to use Use this skill for **client-deliverable** reports: - External red-team engagements with a signed SOW - Pentest reports going to a CISO / IT-Sec team (not a triager) - Findings that will be reviewed by both technical and non-technical stakeholders - Reports that need DOCX/PDF output (not just markdown / platform UI) Do NOT use for: - Bug-bounty platform submissions (use `report-writing` / `bugcrowd-reporting` instead) - Quick proof-of-concept memos - Internal team writeups --- ## The 6-section format per finding This is the canonical structure each finding follows: ```markdown ## Finding F##: <descriptive title> **Severity:** Critical / High / Medium / Low / Informational **Status:** Confirmed / Patched mid-engagement / Suspected (1 signal) **CVSS 3.1:** <score> (<vector>) **Affected Asset:** <URL / IP / app name> ### 1. Subject <One-line statement of the issue. Plain English, no jargon.> ### 2. Observations <Bulleted list of what was observed during testing. Concrete facts only — no interpretation yet.> - <Observation 1> - <Observation 2> - ... ### 3. Description <Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.> ### 4. Impact <What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.> ### 5. Recommendation <Specific, actionable...

Details

Author
elementalsouls
Repository
elementalsouls/Claude-BugHunter
Created
3 weeks ago
Last Updated
5 days ago
Language
Python
License
NOASSERTION

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Listed

report-template

Autonomous report generation from collected findings. Produces bug bounty submissions, client deliverables, and vulnerability reports using the standard finding schema.

0 Updated 2 days ago
Ap6pack
Data & Documents Listed

pentest-reporter

Pentest report builder — executive summary, methodology, finding template with CVSS v3.1/v4.0 scoring, reproduction steps, impact and remediation per finding, remediation roadmap, retest sign-off, and appendices. Works for web-app, network, red-team, and bug-bounty reports.

4 Updated 1 weeks ago
roodlicht
Data & Documents Listed

security-report

Generate security assessment reports in docx format with findings, risk ratings, and remediation recommendations. Use when: User asks for security audit report, vulnerability assessment document, penetration test report, or compliance gap analysis document. Keywords: security report, audit findings, vulnerability report, pentest report

335 Updated today
aiskillstore
Data & Documents Listed

report-writing

Bug bounty report writing for H1/Bugcrowd/Intigriti/Immunefi — report templates, human tone guidelines, impact-first writing, CVSS 3.1 scoring, title formula, impact statement formula, severity decision guide, downgrade counters, pre-submit checklist. Use after validating a finding and before submitting. Never use "could potentially" — prove it or don't report.

1,478 Updated 5 days ago
elementalsouls
Data & Documents Listed

report-writing

Bug bounty report writing for H1/Bugcrowd/Intigriti/Immunefi — report templates, human tone guidelines, impact-first writing, CVSS 3.1 scoring, title formula, impact statement formula, severity decision guide, downgrade counters, pre-submit checklist. Use after validating a finding and before submitting. Never use "could potentially" — prove it or don't report.

0 Updated today
Mikacr1138