redteam-report-template

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:

## 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 remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices" — say what specifically.>

### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>

**Step 1:** <action>

<full HTTP request or curl one-liner>

**Step 2:** <action>

<response excerpt>

**Screenshot:**
![F##_descriptive_name] (screenshots/F##_descriptive_name.png)

---

Severity & status disciplines

Severity table (client-facing — different from CVSS-only)

| Severity | Business definition | CVSS rough range |

|---|---|---|

| Critical | Direct revenue/data loss without prerequisites | 9.0-10.0 |

| High | Full account/system takeover with limited prerequisites | 7.0-8.9 |

| Medium | Significant data exposure or partial compromise | 4.0-6.9 |

| Low | Information disclosure with limited exploitation path | 0.1-3.9 |

| Informational | Hygiene finding, no immediate exploit | N/A |

Status field (red-team-specific)

This is the field that distinguishes red-team deliverables from bug-bounty reports. Use one of:

- **Confirmed** — reproduced multiple times, with full PoC

- **Confirmed; patched mid-engagement** — was reproducible, client patched during the test window (still ship the finding — see `mid-engagement-ir-detection`)

- **Confirmed; partially reproducible** — works but needs specific conditions

- **Suspected (1 signal)** — single indicator, not confirmed (rare — usually drop)

- **Out-of-band** — finding from passive recon, not actively tested

---

Mistakes to avoid (from authorized-engagement)

1. Don't retract findings that stopped reproducing

If a finding was confirmed and then stopped working, that is almost always a CLIENT PATCH, not a finding-was-false. The correct response is "Confirmed; patched mid-engagement" with timestamps showing when it broke. See `mid-engagement-ir-detection`.

2. Don't hedge in the Impact section

Bad: "An attacker could potentially be able to access user data, which may lead to..."

Good: "An attacker reads any user's profile data. Demonstrated on test user `victim@target.com` at 14:22 IST."

3. Don't generic-CIA the impact

Bad: "Loss of confidentiality and integrity of customer data"

Good: "Read access to 247,000 customer records including PAN cards, addresses, GST numbers. India DPDPA Section 33 mandates 72-hour breach disclosure to DPB."

4. Don't list every recon finding as a finding

Recon notes (subdo