report-templates

name	report-templates
description	CVSS 3.1 vector examples, executive summary template, full technical finding template, and remediation language bank for pentest reports
allowed-tools	Read

CVSS 3.1 Vector Reference

Format

CVSS:3.1/AV:[N|A|L|P]/AC:[L|H]/PR:[N|L|H]/UI:[N|R]/S:[U|C]/C:[N|L|H]/I:[N|L|H]/A:[N|L|H]

Score by Severity Tier

Severity	Score Range	Typical Vector Example	Score
CRITICAL	9.0–10.0	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	9.8
CRITICAL	9.0–10.0	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H	10.0
HIGH	7.0–8.9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	8.8
HIGH	7.0–8.9	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N	7.5
HIGH	7.0–8.9	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	7.8
MEDIUM	4.0–6.9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N	6.5
MEDIUM	4.0–6.9	CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N	5.4
MEDIUM	4.0–6.9	CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N	5.9
LOW	0.1–3.9	CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N	4.3
LOW	0.1–3.9	CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N	2.5
INFO	0.0	N/A — informational only	0.0

Pre-built Vectors by Vulnerability Type

Pre-auth RCE (internet-facing):  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  = 9.8
Post-auth RCE (authenticated):   AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  = 8.8
SQLi (data exfil possible):      AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N  = 8.1
SQLi (read-only):                AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N  = 6.5
Stored XSS (unauthenticated):    AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  = 6.1
Stored XSS (post-auth):         AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N  = 5.4
Reflected XSS:                   AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  = 6.1
SSRF (internal access):         AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N  = 7.2
SSRF (cloud metadata):          AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N  = 9.6
Path traversal (file read):      AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  = 7.5
LPE (local exploit):            AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  = 7.8
Insecure deserialization:        AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H  = 8.1
IDOR (sensitive data):          AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N  = 6.5
IDOR (data modification):       AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N  = 8.1
Auth bypass (admin access):      AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N  = 9.1
Weak JWT (crackable secret):    AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N  = 7.4
Hardcoded credentials:           AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N  = 9.1
Open redirect:                   AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  = 6.1
Directory listing:               AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  = 5.3
Information disclosure:          AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  = 5.3
Missing HTTPS:                   AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N  = 4.8
CSRF (state-changing):          AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N  = 6.5

---

Executive Summary Template (1 Page)

## Executive Summary

[CLIENT NAME] engaged [FIRM NAME] to conduct a [TYPE: internal/external/web application/full-scope]
penetration test of [SCOPE DESCRIPTION] between [START DATE] and [END DATE].

### Risk Posture

During the assessment, [FIRM NAME] identified **[N] findings** across [M] systems,
including **[X] Critical**, **[Y] High**, **[Z] Medium**, **[W] Low**, and **[V] Informational** vulnerabilities.

The overall risk posture is assessed as: **[CRITICAL | HIGH | MEDIUM | LOW]**

### Key Findings

The most significant finding was **[FINDING TITLE]**, which allowed testers to [IMPACT DESCRIPTION —
e.g., "gain unauthenticated remote code execution on the production API server and access
the customer database containing [N] records"].

Additional critical findings included:
- **[Finding 2]**: [One-sentence impact]
- **[Finding 3]**: [One-sentence impact]

### Business Impact

Exploitation of the identified vulnerabilities could result in:
- Unauthorized access to sensitive customer data (regulatory impact: GDPR, PCI-DSS)
- Complete compromise of [SYSTEM] infrastructure
- Reputational damage and loss of customer trust
- [SPECIFIC DOLLAR/OPERATIONAL IMPACT IF QUANTIFIABLE]

### Remediation Priority

| Priority | Timeline | Actions |
|----------|----------|---------|
| Immediate (0-7 days) | Patch [CVE], revoke [credential], disable [service] |
| Short-term (8-30 days) | Implement [control], remediate [N] High findings |
| Medium-term (31-90 days) | Address [N] Medium findings, establish [process] |

[FIRM NAME] is available to provide remediation guidance and conduct a retest upon completion.

---

Technical Finding Template

---

## [ID]: [SEVERITY] — [Vulnerability Title]

| Field | Value |
|-------|-------|
| **Severity** | CRITICAL / HIGH / MEDIUM / LOW / INFO |
| **CVSS 3.1 Score** | [SCORE] ([CVSS:3.1/AV:.../...]) |
| **CWE** | CWE-[NUMBER]: [NAME] |
| **ATT&CK TTP** | [T-NUMBER]: [TECHNIQUE NAME] |
| **Affected Asset** | [IP / URL / Component] |
| **CVE** | CVE-XXXX-XXXXX (if applicable) |
| **Date Identified** | [UTC DATE] |

### Description

[2-4 sentence technical description of the vulnerability. Explain what it is, why it exists,
and what conditions allow it to be exploited. Avoid jargon that a non-technical reader
cannot follow in the executive summary.]

### Business Impact

[1-2 sentences describing the business consequence if this vulnerability is exploited.
Frame in terms of data confidentiality, regulatory requirements, operational availability,
or financial impact.]

### Steps to Reproduce

**Prerequisites:** [Access level required, e.g., "Unauthenticated" / "Valid user account"]

1. Navigate to `[URL]` using a web browser or send the following request:
   ```http
   [REQUEST METHOD] [PATH] HTTP/1.1
   Host: [HOST]
   [HEADERS]

   [BODY IF APPLICABLE]

2. [Step 2 description]

3. The application responds with:

   [RESPONSE SNIPPET or COMMAND OUTPUT]
   

4. [Step describing the impact demonstration]

Evidence

• Screenshot/Output: evidence/[DATE]/[TARGET]/[category]/[filename]
• Request/Response: evidence/[DATE]/[TARGET]/[category]/[filename].http
• Video recording: evidence/[DATE]/[TARGET]/[category]/[filename].mp4 (if captured)

Remediation

Immediate Actions:

1. [Specific immediate mitigation step — e.g., "Disable the affected endpoint at the WAF layer"]
2. [Second immediate step if needed]

Long-term Fix: [Specific code-level or configuration-level remediation. Include version number to upgrade to, configuration value to set, or code pattern to implement.]

Verification: [How to confirm the fix is effective — e.g., "Re-run the proof of concept steps above; the server should return HTTP 403 or equivalent error."]

References

• [CVE link or NVD URL if applicable]
• [Vendor advisory URL]
• [OWASP / CWE / NIST link]
• [ATT&CK technique URL: https://attack.mitre.org/techniques/T-NUMBER/]

---

## 5×5 Risk Matrix

```markdown
## Risk Matrix

|  | **Negligible (1)** | **Minor (2)** | **Moderate (3)** | **Major (4)** | **Catastrophic (5)** |
|---|---|---|---|---|---|
| **Almost Certain (5)** | MEDIUM 5 | HIGH 10 | HIGH 15 | CRITICAL 20 | CRITICAL 25 |
| **Likely (4)** | LOW 4 | MEDIUM 8 | HIGH 12 | HIGH 16 | CRITICAL 20 |
| **Possible (3)** | LOW 3 | MEDIUM 6 | MEDIUM 9 | HIGH 12 | HIGH 15 |
| **Unlikely (2)** | LOW 2 | LOW 4 | MEDIUM 6 | MEDIUM 8 | HIGH 10 |
| **Rare (1)** | INFO 1 | LOW 2 | LOW 3 | LOW 4 | MEDIUM 5 |

*Score = Likelihood × Impact*

---

Remediation Language Bank (Top 20 Vulnerability Types)

SQL Injection

Implement parameterized queries (prepared statements) for all database interactions. Do not construct SQL queries using string concatenation with user-supplied input. Apply input validation with allowlists at the application layer. Deploy a WAF rule to detect and block common SQL injection patterns as a defense-in-depth measure.

Cross-Site Scripting (XSS)

Implement context-sensitive output encoding for all user-controlled data rendered in HTML, JavaScript, CSS, and URL contexts. Use a Content Security Policy (CSP) header that restricts inline scripts and specifies trusted sources. Validate and sanitize all inputs using an allowlist approach. Consider adopting a templating framework that auto-escapes by default.

Insecure Direct Object Reference (IDOR)

Implement server-side authorization checks that verify the authenticated user has permission to access the requested object before returning it. Replace sequential numeric IDs with unpredictable UUIDs where possible. Do not rely solely on obscurity — enforce access controls regardless of whether the ID is guessable.

Server-Side Request Forgery (SSRF)

Validate and allowlist permitted URL schemes, hosts, and ports before making server-side requests. Block requests to RFC 1918 private address ranges, loopback (127.0.0.1), and cloud metadata endpoints (169.254.169.254). Use a dedicated network egress proxy and disable URL redirects when making outbound connections.

Broken Authentication / Auth Bypass

Implement strong multi-factor authentication. Enforce secure session management: use cryptographically random session IDs, set Secure and HttpOnly cookie flags, expire sessions after inactivity, and invalidate server-side on logout. Audit all authentication code paths for logic bypasses including parameter manipulation, host header injection, and JWT algorithm confusion.

Insecure File Upload

Validate file type using magic byte inspection (not just extension). Enforce maximum file size limits. Store uploaded files outside the web root with non-executable permissions. Serve files through a separate subdomain without CGI/PHP processing enabled. Scan uploaded files with an antivirus engine before processing.

Command Injection

Never pass user input to shell interpreters. Redesign functionality to avoid subprocess calls where possible; if unavoidable, use language-native API bindings that do not invoke a shell, and apply strict allowlist validation on all parameters.

Path Traversal

Resolve the canonical path after user input is appended to the base directory and verify the result starts with the expected base path before accessing the file. Never pass user-controlled input directly to file system APIs.

Insecure Deserialization

Avoid deserializing data from untrusted sources. If required, use a data format that does not support arbitrary object deserialization (JSON/XML rather than Java Serialization, PHP unserialize, or Python pickle). Implement integrity checking (HMAC) on serialized data and apply an allowlist of permitted classes during deserialization.

Sensitive Data Exposure

Encrypt sensitive data at rest using AES-256 and in transit using TLS 1.2+ with HSTS. Remove sensitive data from responses, logs, and error messages. Apply field-level encryption for PII. Implement data classification and enforce access controls at the data layer, not just the application layer.

Security Misconfiguration

Apply CIS benchmarks to all systems, containers, and cloud services. Remove default credentials, sample applications, and unnecessary services. Automate configuration baseline enforcement using infrastructure-as-code tools (Terraform, Ansible) and validate continuously with configuration scanning tools.

XML External Entity (XXE)

Disable XML external entity processing in the XML parser configuration. In Java: factory.setFeature("http://xml.org/sax/features/external-general-entities", false). In PHP: libxml_disable_entity_loader(true). Use less complex data formats (JSON) where XML is not required.

Missing Rate Limiting / Brute Force

Implement account lockout after N (5–10) failed authentication attempts with progressive delay. Apply IP-based rate limiting at the application gateway layer. Enable CAPTCHA for high-value authentication flows. Log and alert on abnormal login velocity from a single source.

Hardcoded Credentials

Remove all hardcoded credentials from source code, configuration files, and container images immediately. Rotate any exposed credentials. Store secrets in a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Implement pre-commit hooks and CI pipeline scanning (gitleaks, truffleHog) to prevent future credential exposure.

JWT Vulnerabilities

Validate the alg header against an allowlist of accepted algorithms; reject none. Use asymmetric keys (RS256/ES256) rather than symmetric HMAC. Validate iss, aud, exp, and nbf claims on every request. Use a minimum 256-bit secret for HS256. Rotate signing keys periodically.

CSRF

Implement anti-CSRF tokens (synchronizer token pattern) for all state-changing requests. Use the SameSite=Strict or SameSite=Lax cookie attribute. Validate the Origin and Referer headers server-side. For REST APIs, verify the Content-Type is application/json (non-simple CORS request) to leverage the preflight mechanism.

Open Redirect

Validate redirect URLs against a strict allowlist of permitted destinations. Reject any URL that does not match the expected domain exactly. Do not rely on URL parsing alone — canonicalize and normalize the URL before comparison.

Directory Listing

Disable directory listing in the web server configuration. Apache: Options -Indexes. Nginx: remove autoindex on. Ensure that all directories accessible via the web root contain an index document or are explicitly denied.

Unpatched Software / Known CVEs

Establish a vulnerability management program with defined SLAs by severity (Critical: 24h, High: 7 days, Medium: 30 days, Low: 90 days). Deploy authenticated vulnerability scanning weekly. Enroll in vendor security advisories and subscribe to the CISA Known Exploited Vulnerabilities (KEV) catalog.

Insecure TLS Configuration

Enforce TLS 1.2 as the minimum version; prefer TLS 1.3. Disable weak cipher suites (RC4, DES, 3DES, export ciphers, NULL). Enable HSTS with a minimum max-age of 31536000 and include the preload directive. Configure OCSP stapling. Use a certificate with a minimum 2048-bit RSA or 256-bit ECDSA key signed by a trusted CA.

---

30/60/90 Remediation Roadmap Template

## Remediation Roadmap

### Phase 1: Immediate (Days 1–30)
**Goal:** Eliminate critical/high risk and contain active exposure

| # | Finding | Owner | Action | Due |
|---|---------|-------|--------|-----|
| 1 | [CRITICAL finding] | [Team] | [Specific action] | Day 7 |
| 2 | [HIGH finding] | [Team] | [Specific action] | Day 14 |
| 3 | [HIGH finding] | [Team] | [Specific action] | Day 30 |

### Phase 2: Short-term (Days 31–60)
**Goal:** Address medium-severity findings and implement preventive controls

| # | Finding | Owner | Action | Due |
|---|---------|-------|--------|-----|
| 1 | [MEDIUM finding] | [Team] | [Specific action] | Day 45 |
| 2 | [MEDIUM finding] | [Team] | [Specific action] | Day 60 |

### Phase 3: Medium-term (Days 61–90)
**Goal:** Harden security program and address low-severity findings

| # | Finding | Owner | Action | Due |
|---|---------|-------|--------|-----|
| 1 | [LOW finding] | [Team] | [Specific action] | Day 75 |
| 2 | [Program improvement] | [Security team] | [Specific action] | Day 90 |

**Retest:** A verification assessment is recommended upon completion of Phase 1.