Overview
A vulnerability nobody fixes isn't security. This phase converts raw findings into a report that engineers can act on and leaders can prioritize: consistent severity, crisp reproduction, honest impact, concrete fixes, and tracked closure.
Core principle: Write for two readers at once — an executive who needs risk and priority, and an engineer who needs exact steps to reproduce and fix.
Structure of a good report
- Executive summary — plain-language risk posture, top 3–5 risks, overall verdict. No jargon.
- Scope & methodology — what was tested, environment, dates, what was out of scope.
- Findings — one entry each (see template), ordered by severity.
- Remediation roadmap — prioritized fix list with effort estimates.
- Retest results — status per finding after fixes (Open / Fixed / Risk-accepted).
- Appendix — tools, raw evidence, references.
Finding template (use for every issue)
Title: <Concise, e.g. "IDOR in /api/invoices exposes other users' billing">
Severity: Critical | High | Medium | Low | Info (CVSS x.x — vector)
Affected: <endpoint / file:line / component>
Summary: <1–2 sentences: what's wrong and why it matters>
Reproduction: <numbered, copy-pasteable steps / exact request>
Evidence: <response excerpt / screenshot, real data redacted>
Impact: <business consequence: data exposed, money, accounts, scope>
Remediation: <specific fix, link to security-hardening pattern>
Status: Open | Fixed (retested <date>) | Risk-accepted
Severity & CVSS
Score consistently so priorities are defensible. See references/cvss-and-template.md for the
CVSS v3.1 metrics, a base-score cheat sheet, and a full report skeleton.
| Severity | Rough CVSS | Means |
|---|---|---|
| Critical | 9.0–10.0 | Fix now — full compromise / mass data / unauth RCE |
| High | 7.0–8.9 | Fix this cycle — ATO, sensitive data, privesc |
| Medium | 4.0–6.9 | Plan — needs conditions or limited impact |
| Low | 0.1–3.9 | Backlog — minor/defense-in-depth |
| Info | 0.0 | Note — best-practice, no direct risk |
Adjust for business context: a "Medium" on the payment path may be a "High" for you.
Writing rules
- Reproducible or it didn't happen — steps a developer can paste and rerun.
- Impact in business terms — "any user can read all invoices," not "missing authz check."
- One fix per finding — point to the exact
security-hardeningpattern. - No fear, no fluff — accurate severity; over-hyping burns trust, under-hyping gets ignored.
- Redact real data in evidence.
Retest & closure
For each fixed finding: rerun the original PoC, record pass/fail and date, set status. The report isn't done until every High+ is Fixed or explicitly Risk-accepted by an owner.
Hand-off
Findings come from all FIND/EXPLOIT skills; fixes from security-hardening; this skill
packages and tracks them to closure (retest each High+ before marking it fixed).
Common mistakes
- Dumping scanner output as "the report" — triage, dedupe, and verify first.
- Severity by gut feel — use CVSS + business context so priorities hold up.
- Reproduction steps that only you can follow — write for a stranger.
- No retest — "fixed" without rerunning the exploit is a guess.