6 min read

Beginner
Template

Finding Template

A standardized template for documenting individual vulnerabilities. Use this format consistently across all findings for professional, actionable reports.

Consistency is Key

Using a consistent format for all findings makes reports easier to read and ensures no critical information is missed.

Standard Finding Format

## [VLN-XXX] [Vulnerability Title]

### Overview
| Attribute | Value |
|-----------|-------|
| **Severity** | [Critical / High / Medium / Low / Info] |
| **CVSS Score** | X.X |
| **CVSS Vector** | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| **CWE** | CWE-XXX: [Name] |
| **OWASP** | A0X:2025 - [Category] |
| **Affected Asset** | [URL / IP / System] |
| **Status** | Open / Remediated / Risk Accepted |

### Description
[2-3 sentences describing the vulnerability in clear terms. What is it? 
Why does it exist? Avoid overly technical jargon.]

### Technical Details
[Detailed technical explanation for security/development teams. 
Include the root cause and attack vector.]

### Evidence

#### Request
```http
[HTTP request that demonstrates the vulnerability]
```

#### Response
```http
[Server response showing successful exploitation]
```

#### Screenshot
[Insert screenshot or reference to appendix]

### Impact
[Describe what an attacker could achieve by exploiting this vulnerability.
Be specific about data at risk, systems affected, and business impact.]

**Potential consequences:**
- [Impact 1]
- [Impact 2]
- [Impact 3]

### Proof of Concept
```
[Minimal PoC code/command to reproduce the issue]
[Keep it simple - just enough to prove the vulnerability]
```

### Remediation

#### Immediate Actions (Quick Wins)
1. [First quick fix]
2. [Second quick fix]

#### Long-term Solution
[Comprehensive fix that addresses the root cause]

#### Secure Code Example
```[language]
// Before (Vulnerable)
[vulnerable code]

// After (Secure)
[fixed code]
```

#### Remediation Effort
| Effort | Estimated Time |
|--------|---------------|
| Development | [X hours/days] |
| Testing | [X hours/days] |
| Deployment | [X hours/days] |

### References
- [Relevant OWASP page]
- [Relevant CWE entry]
- [Vendor documentation]
- [Additional resources]

Example Findings

Critical: SQL Injection

## [VLN-001] SQL Injection in Search Functionality

| Attribute | Value |
|-----------|-------|
| **Severity** | Critical |
| **CVSS Score** | 9.8 |
| **CVSS Vector** | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| **CWE** | CWE-89: SQL Injection |
| **OWASP** | A05:2025 - Injection |
| **Affected Asset** | https://app.example.com/search |

### Description
The search functionality is vulnerable to SQL injection via the 'q' parameter.
User input is concatenated directly into SQL queries without sanitization.

### Evidence
Request: GET /search?q=test' OR '1'='1 HTTP/1.1
Response: Returns all database records instead of filtered results

### Impact
- Complete database compromise
- Authentication bypass
- Potential RCE via database functions

### Remediation
Use parameterized queries:
```python
cursor.execute("SELECT * FROM products WHERE name LIKE %s", ("%" + query + "%",))
```

Medium: Missing Security Headers

## [VLN-007] Missing HTTP Security Headers

| Attribute | Value |
|-----------|-------|
| **Severity** | Medium |
| **CVSS Score** | 5.3 |
| **CWE** | CWE-693: Protection Mechanism Failure |
| **OWASP** | A02:2025 - Security Misconfiguration |
| **Affected Asset** | https://app.example.com/* |

### Description
The application does not implement recommended HTTP security headers,
reducing defense-in-depth against common web attacks.

### Missing Headers
- Content-Security-Policy
- X-Frame-Options
- X-Content-Type-Options
- Strict-Transport-Security

### Remediation
Add to web server configuration:
```nginx
add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
```

Writing Checklist

Before Submitting

  • Vulnerability is reproducible
  • CVSS score is accurate
  • Evidence clearly shows the issue
  • Impact is specific, not generic
  • Remediation is actionable
  • References are included
  • Screenshots are clear and annotated
  • No sensitive data exposed in report

Common Mistakes

  • Generic impact statements
  • Missing reproduction steps
  • Incorrect CVSS scoring
  • No code examples in remediation
  • Unclear screenshots
  • Duplicate findings not merged
  • Technical jargon without explanation
  • Missing affected asset details

Likely False Positives

A finding is the unit the client will argue with. These are the ways a single finding overstates or understates what was actually demonstrated.

  • Example vector left in place: The template ships a high-impact CVSS vector. A finding that keeps it while describing a lower impact will be disputed, and the dispute is legitimate.
  • Observation scored to fit a band: A best-practice observation given a number so it appears in the severity table is presented as a confirmed weakness it never was.
  • Impact borrowed from the category: Copying the impact text of a similar CVE onto a target whose path cannot reach that consequence overstates the finding at the exact point the client will test it.
  • Asset narrower than the evidence: A finding whose affected asset names one endpoint while the evidence shows the parameter is shared across several understates scope and under-delivers the fix.
  • One root cause, two IDs: The same weakness filed twice against different endpoints inflates the finding count and splits the remediation.
  • Client data quoted as proof: A dump excerpt that includes real personal data proves the access but creates a second problem; quote the structure, redact the values.
  • Remediation that restates the finding: Naming the weakness again in imperative form leaves the developer to work out where the change goes, which is the part they needed from you.

Finding Sign-Off Checklist

Header and scoring

  • ☐ ID unique and in sequence with the summary table
  • ☐ Severity band agrees with the CVSS score
  • ☐ CVSS vector recomputed against the impact text rather than inherited from the template
  • ☐ CWE and OWASP mappings checked against the weakness described
  • ☐ Affected asset string matches the scope table exactly

Body

  • ☐ Description states what the weakness is and why it exists
  • ☐ Technical details name the root cause rather than the symptom
  • ☐ Impact names the data or capability at risk, not a category name
  • ☐ Remediation names the file, configuration or component to change
  • ☐ References resolve and point at the specific guidance, not a landing page

Evidence

  • ☐ Request and response both present and paired
  • ☐ Screenshot legible without zooming and annotated at the payload
  • ☐ Test account and timestamp recorded so the client can correlate
  • ☐ Secrets and personal data redacted, raw copy retained

Consistency

  • ☐ Same root cause not filed twice under different IDs
  • ☐ Status field left accurate rather than pre-filled as remediated
  • ☐ Remediation effort agreed with whoever will implement it
  • ☐ Finding exported in the same structure as its siblings

Related Topics

Technical Report

Full technical report template

Executive Summary

Executive summary template

Retest Report

Remediation verification template