Phase 07 📄

Reporting & Disclosure

From finding to fix

Writing findings in CVSS format, responsible disclosure workflows, and producing professional pentest reports.

Introduction

A vulnerability that can’t be communicated clearly might as well not exist. The report is the final deliverable of every pentest — it translates technical findings into business risk, and business risk into actionable remediation.

Reporting is not optional. Every finding must be documented before the engagement ends. Undocumented findings that were discussed verbally are not accepted by clients, and may leave the organization exposed.

The tester’s perspective at this stage: you are now a translator. Your audience is both the security engineer who needs to reproduce and fix the bug, and the executive who needs to understand why the budget should be approved.

CVSS Scoring

Purpose of the Test

The Common Vulnerability Scoring System (CVSS) provides a standardized numeric score (0–10) for vulnerability severity, enabling consistent prioritization across different types of findings. Accurate CVSS scoring is a core professional skill.

CVSS 3.1 Base Score Components

Attack Vector (AV): How the vulnerability is exploited

  • Network (N): Remotely exploitable across the internet
  • Adjacent (A): Requires access to the same local network
  • Local (L): Requires local system access
  • Physical (P): Requires physical access

Attack Complexity (AC): Conditions beyond attacker control

  • Low (L): No special conditions required
  • High (H): Requires specific conditions (race condition, specific configuration)

Privileges Required (PR): Privileges needed before attack

  • None (N): No authentication required
  • Low (L): Basic user privileges
  • High (H): Administrative privileges

User Interaction (UI): User involvement required

  • None (N): No user action needed
  • Required (R): A user must take an action

Scope (S): Does the vulnerability affect components beyond its security scope?

  • Unchanged (U): Impact confined to the vulnerable component
  • Changed (C): Impact extends to other components

Impact metrics — Confidentiality (C), Integrity (I), Availability (A):

  • None (N) / Low (L) / High (H)

Severity Ranges

ScoreSeverity
0.0None
0.1 – 3.9Low
4.0 – 6.9Medium
7.0 – 8.9High
9.0 – 10.0Critical

Expected Outcomes

Good CVSS scoring: vector string that accurately reflects the exploitation requirements and impact. Defensible score that a peer reviewer would assign similarly.

Common mistakes: overscoring everything as Critical (destroys credibility), underscoring to avoid difficult conversations (leaves the organization exposed).

AI-Assisted Scoring

Prompt Template — CVSS Score Generation

[ROLE] Senior security analyst
[FINDING] Time-based blind SQL injection at POST /api/users/login
[EVIDENCE]
  - No authentication required
  - Exploitable from the internet
  - Response time confirms injection without additional setup
  - Database: PostgreSQL, confirmed via pg_sleep timing
  - No data extraction performed; timing-based only
  - Could theoretically allow: authentication bypass, data extraction, privilege escalation
[TASK] Calculate the CVSS 3.1 base score for this finding.
  - Justify each metric selection
  - Provide the CVSS vector string
  - Note any metrics that could be higher if further exploitation were confirmed
[OUTPUT FORMAT]
  - Metric-by-metric justification table
  - Final vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
  - Numeric score and severity label

AI Hard Stops for This Topic

  • [NO] Do not score findings without actual evidence — assumed impact is not evidence
  • [YES] Always justify each metric with specific evidence from the test
  • [YES] Conservative scoring with clear evidence beats aggressive scoring with assumptions

Resources

Finding Template

Purpose

A consistent finding template ensures every vulnerability is documented with enough detail to be reproduced, understood, and fixed — by someone who wasn’t in the room.

Standard Finding Structure

Title: Short, descriptive, specific. “SQL Injection in Login Endpoint” not “SQL Injection.”

Severity: Critical / High / Medium / Low / Informational — with CVSS score.

CVSS Vector: Full 3.1 vector string.

Affected Asset: Exact URL, IP, service, component.

Description: What the vulnerability is, in plain English. One paragraph. No assumptions of reader knowledge.

Evidence: Steps to reproduce — numbered, exact, reproducible. Include request/response snippets (sanitized). Include screenshots.

Business Impact: One paragraph. What does this mean for the business? Data breach? Regulatory fine? Service outage? Frame in terms the CEO would understand.

Remediation: Specific, actionable fix. Not “sanitize inputs” — “use parameterized queries as shown in the code example below.”

References: OWASP, CVE, CWE, NVD links.

AI-Assisted Reporting

Prompt Template — Finding Write-Up

[ROLE] Senior penetration tester writing a professional finding
[VULNERABILITY] Time-based blind SQL injection
[AFFECTED] POST /api/users/login — email parameter
[EVIDENCE]
  - Request: POST /api/users/login with email=' OR pg_sleep(3)--
  - Baseline response time: 120ms (3-request average)
  - Payload response time: 3,140ms (3-request average)
  - Confirmed on 3 separate test runs
[CONTEXT] Unauthenticated endpoint, internet-facing, PostgreSQL backend
[TASK] Write a complete professional finding entry.
  - Title, severity, CVSS vector and score
  - Description suitable for a developer audience
  - Business impact for an executive audience
  - Step-by-step reproduction (sanitized curl commands)
  - Specific remediation with code example (parameterized queries in Node.js/Python)
  - OWASP and CWE references
[CONSTRAINTS] Professional, factual, no hyperbole. Remediation must be specific and implementable.

AI Hard Stops for This Topic

  • [NO] Never include real credentials, PII, or sensitive data in finding documentation
  • [NO] Do not exaggerate impact beyond what was demonstrated
  • [YES] Every finding must have reproduction steps — untested “theoretical” findings are noted as such
  • [YES] Sanitize all request/response snippets before including in reports

Executive Summary

Purpose

The executive summary is the first and often only section read by the CISO, CTO, or board. It must convey risk level and business impact in non-technical language, with a clear call to action.

Executive Summary Structure

  1. Engagement Scope and Objective: What was tested and why
  2. Overall Risk Rating: A single aggregate rating with brief justification
  3. Critical Findings Summary: 2–3 sentences per critical/high finding — no technical jargon
  4. Key Risk Themes: Patterns across findings (e.g., “authentication controls were a consistent weakness”)
  5. Immediate Actions Required: Prioritized list of the 3–5 most urgent fixes
  6. Positive Observations: What the organization is doing well — builds credibility and trust

Writing Principles

  • Write for a reader with no technical background
  • Translate every technical finding into a business consequence: “SQL injection” → “could expose your entire customer database”
  • Avoid severity inflation — if everything is Critical, nothing is
  • Be honest about what was not tested and why

AI-Assisted Reporting

Prompt Template — Executive Summary Draft

[ROLE] Senior penetration tester writing an executive summary
[FINDINGS SUMMARY]
  Critical: SQL injection in login endpoint (unauthenticated, internet-facing)
  High: Missing rate limiting on authentication (credential stuffing risk)
  High: TLS 1.1 enabled on public API
  Medium: Missing CSRF protection on account settings
  Low: Server version disclosed in HTTP headers
[ENGAGEMENT] External penetration test, 5-day engagement, scope: main web application + API
[AUDIENCE] CISO and CTO — technical but not pentest practitioners
[TASK] Draft a 1-page executive summary.
  - Overall risk rating with justification
  - Non-technical description of each critical/high finding
  - Top 3 immediate actions
  - 2 positive observations to balance the report
[CONSTRAINTS] Plain English. No CVE IDs or CVSS vectors in this section. Business impact framing only.

AI Hard Stops for This Topic

  • [NO] Do not include technical payload examples in the executive summary
  • [NO] Do not include unexplained technical terms (SSRF, IDOR, etc.) without a plain-language definition
  • [YES] Every finding should be translated into a business risk statement
  • [YES] Include positive observations — a purely negative report damages the relationship

Responsible Disclosure

Purpose

Responsible disclosure (also called coordinated vulnerability disclosure) is the process of reporting a security vulnerability to the affected organization in a way that gives them time to fix it before public exposure. Bug bounty programs formalize this process.

Disclosure Process

  1. Discover the vulnerability — document thoroughly before contacting anyone
  2. Identify the contact — security@ email, HackerOne/Bugcrowd program, or vendor security page
  3. Send initial report — include: description, impact, reproduction steps, suggested fix. Do NOT include exploit code.
  4. Set a reasonable timeline — industry standard is 90 days before public disclosure (Google Project Zero standard)
  5. Coordinate a fix — respond to questions, verify the patch if asked
  6. Agree on disclosure — coordinate the public disclosure date; request CVE if appropriate
  7. Publish (optional) — write-up that credits both parties; include timeline of coordination

What Makes a Good Disclosure Report

  • Clear, reproducible reproduction steps
  • Evidence of the vulnerability (screenshots, request/response)
  • Business impact description — not just technical description
  • Suggested remediation
  • No exploit code in the initial report

Bug Bounty Context

Most bug bounty programs (HackerOne, Bugcrowd, Intigriti) have their own rules that supersede general responsible disclosure guidelines. Always read the program policy before testing:

  • Scope: which domains/assets are in scope
  • Out-of-scope: what you must not test
  • Safe harbor: protection from legal action for in-scope testing
  • Reward structure: severity → reward mapping

AI-Assisted Reporting

Prompt Template — Disclosure Report

[ROLE] Security researcher writing a bug bounty disclosure report
[PROGRAM] HackerOne program for Example Corp
[FINDING] SQL injection in login endpoint
[EVIDENCE] Timing-based confirmation, no data extracted
[TASK] Draft a professional bug bounty report.
  - Title, severity, summary
  - Step-by-step reproduction (sanitized — no real data)
  - Impact statement
  - Suggested fix
  - Compliance with responsible disclosure norms
[OUTPUT FORMAT]
  - Bug bounty report structure
  - Professional, factual tone
[CONSTRAINTS] No exploit code. No real user data. No proof-of-concept that could cause harm.

AI Hard Stops for This Topic

  • [NO] Never include weaponized exploit code in a disclosure report
  • [NO] Do not publicly disclose before the coordinated timeline
  • [NO] Do not contact media before the vendor has had a chance to respond
  • [YES] Follow the program’s safe harbor and disclosure guidelines
  • [YES] 90 days is the standard coordination window before considering public disclosure

Resources

Remediation Roadmap

Purpose

A remediation roadmap translates findings into a prioritized action plan — telling the engineering team not just what is broken but in what order to fix it, and what “fixed” looks like for each finding.

Prioritization Framework

Prioritize by: Severity × Exploitability × Exposure

  • A Critical finding on an internet-facing, unauthenticated endpoint should be fixed within 24–48 hours
  • A High finding requiring authentication should be fixed within 2 weeks
  • Medium findings should be addressed within 30 days
  • Low and Informational findings can be scheduled into the next sprint

Remediation Roadmap Structure

Immediate (0–48 hours)

  • Critical findings requiring emergency patching or temporary mitigation
  • Findings where active exploitation is likely or has been confirmed

Short-Term (2 weeks)

  • High findings
  • Systemic issues (e.g., “all SQL queries in the login service need parameterized query refactoring”)

Medium-Term (30 days)

  • Medium findings
  • Architectural improvements

Long-Term (90 days)

  • Low and Informational findings
  • Security program improvements (training, SDLC integration, tooling)

Verification

  • Every remediated finding should be re-tested before closing
  • A fix that doesn’t fully address the root cause is not a fix

AI-Assisted Reporting

Prompt Template — Remediation Roadmap

[ROLE] Senior security engineer producing a remediation roadmap
[FINDINGS]
  Critical: SQL injection — login endpoint (CVSS 9.8)
  High: Missing rate limiting — login endpoint (CVSS 7.5)
  High: TLS 1.1 enabled (CVSS 7.5)
  Medium: Missing CSRF on account settings (CVSS 5.4)
  Medium: Session not invalidated on logout (CVSS 5.4)
  Low: Server version in headers (CVSS 3.1)
[TEAM CONTEXT] 2 backend engineers, 1 DevOps engineer, 2-week sprint cycles
[TASK] Produce a prioritized remediation roadmap.
  - Timeline tiers: Immediate, 2-week, 30-day, 90-day
  - Specific fix per finding (code approach or config change)
  - Verification criteria: how to confirm each fix is complete
  - Estimate of engineering effort per finding
[CONSTRAINTS] Practical, implementable. Assume no dedicated security team.

AI Hard Stops for This Topic

  • [NO] Do not recommend remediations that require data migration without client sign-off
  • [NO] Do not suggest temporary workarounds as permanent fixes
  • [YES] Every remediation must include a verification method
  • [YES] Prioritize by exploitability, not just CVSS — a High with easy exploitation beats a Critical requiring physical access

Resources