English for Security Engineers: CVE Advisories and Vulnerability Reports

Security engineers write documents that get read under pressure: vulnerability advisories that CISOs forward to boards, penetration test reports that developers must act on, and incident communications that go to customers during active breaches. The stakes of unclear writing are high.

This guide covers the specific vocabulary, communication patterns, and document templates that security engineers need to write effective advisories, disclose vulnerabilities responsibly, and communicate security findings clearly.

Part 1: Core Security Communication Vocabulary

Vulnerability and exploit terminology

Term	Definition
vulnerability	A weakness in a system that could be exploited
exploit	Code or technique that takes advantage of a vulnerability
CVE	Common Vulnerabilities and Exposures — the global ID system for known vulnerabilities
CVSS	Common Vulnerability Scoring System — numeric score (0–10) indicating severity
attack vector	How the vulnerability can be exploited (network, adjacent, local, physical)
attack surface	The sum of all points where an attacker can try to enter a system
zero-day	A vulnerability with no available patch
patch	A software update that fixes a vulnerability
disclosure	The process of informing vendors and the public about a vulnerability
responsible disclosure	Notifying the vendor privately before public disclosure, giving time to patch
proof of concept (PoC)	A demonstration that a vulnerability is exploitable in practice
remediation	Fixing or mitigating a vulnerability
mitigation	A workaround that reduces risk without fully fixing the underlying issue
risk acceptance	A formal decision not to remediate a known vulnerability, with documented rationale
threat actor	An individual or group that could exploit a vulnerability
threat model	An analysis of what could go wrong, by whom, and via what method

CVSS Score Language

The CVSS score should always be contextualised in writing:

CVSS Score	Label	How to write about it
9.0–10.0	Critical	”This vulnerability is rated Critical (CVSS 9.8). Immediate action is required.”
7.0–8.9	High	”This is a High-severity finding (CVSS 7.5). Remediation is strongly recommended within 30 days.”
4.0–6.9	Medium	”This finding is rated Medium severity. We recommend addressing it within 90 days.”
0.1–3.9	Low	”This is a Low-severity finding. Remediation can be planned as part of the normal development cycle.”

Part 2: Writing Vulnerability Advisories

A vulnerability advisory is a formal document that notifies users of a security issue and tells them what to do. It must be clear, accurate, and actionable.

Advisory template

# Security Advisory: [Short Title]

**ID:** [Internal ID or CVE ID if assigned]
**Severity:** Critical / High / Medium / Low
**CVSS Score:** [score] (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**Affected Versions:** [product] versions [range]
**Fixed Version:** [version]
**Published:** [date]
**Last Updated:** [date]

---

## Summary

A [brief description of vulnerability type] vulnerability exists in [component].
An unauthenticated remote attacker could exploit this to [impact — e.g., 
"execute arbitrary code", "access sensitive data", "cause a denial of service"].

---

## Affected Components

- [Product name] versions [range]
- [Any dependent libraries, OS versions, configurations affected]

---

## Description

[Detailed technical description. Include:
- What the vulnerable component does
- What the weakness is
- How it can be exploited
- What conditions must be met for exploitation]

An attacker who sends a specially crafted [request type] to [endpoint/component] 
can [exploit mechanism], resulting in [impact].

---

## Impact

If exploited, this vulnerability could allow an attacker to:
- [Impact 1]
- [Impact 2]

---

## Remediation

**Recommended action:** Update to version [X] immediately.

To update:
   npm update [package-name]@[version]   (or equivalent for your package manager)

If immediate update is not possible, the following interim mitigations reduce 
the risk:
- [Mitigation 1]
- [Mitigation 2]

---

## Workaround

If upgrading is not immediately possible, [describe workaround]. Note that 
this is a temporary measure and does not fully remediate the vulnerability.

---

## Credits

This vulnerability was reported by [researcher name / organisation] through 
[responsible disclosure / bug bounty program].

---

## Timeline

| Date | Event |
|------|-------|
| [date] | Vulnerability reported to [vendor] |
| [date] | Vendor acknowledged report |
| [date] | Patch developed and tested |
| [date] | Advisory published |

Part 3: Penetration Test Report Writing

A pentest report is read by both technical teams (who need to reproduce and fix findings) and management (who need to understand business risk). It must serve both audiences.

Report structure

# Penetration Test Report: [Target] [Date Range]

**Prepared for:** [Client organisation]
**Prepared by:** [Security team / firm]
**Classification:** CONFIDENTIAL

---

## Executive Summary

One page of non-technical risk summary intended for CISO and management.

During the assessment of [target] conducted between [date] and [date], 
[company name] identified [N] findings across [N] systems. Of these, 
[N] are rated Critical or High severity and require immediate attention.

The most significant findings include:

- **Authentication Bypass in the Admin Portal** (Critical): An unauthenticated 
  attacker with network access could gain full administrative access to [system], 
  compromising all data within it.

- **Insecure Direct Object Reference in the API** (High): Authenticated users 
  can access records belonging to other users by manipulating request parameters.

Immediate remediation of the Critical and High findings is strongly recommended.

---

## Scope

| In Scope | Out of Scope |
|----------|--------------|
| [List of URLs, IPs, systems] | [Explicitly excluded systems] |

**Testing period:** [dates]
**Testing type:** Black-box / Grey-box / White-box
**Credentials provided:** [description if grey/white-box]

---

## Findings Summary

| ID | Title | Severity | CVSS | Status |
|----|-------|----------|------|--------|
| F-001 | Authentication bypass in admin portal | Critical | 9.8 | Open |
| F-002 | Insecure Direct Object Reference in /api/users | High | 7.5 | Open |
| F-003 | Outdated TLS configuration (TLS 1.0 enabled) | Medium | 5.3 | Open |

---

## Individual Finding: F-001

### Authentication Bypass in Admin Portal

**Severity:** Critical  
**CVSS:** 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)  
**Affected URL:** https://admin.example.com/login  

**Description:**
The admin portal login endpoint does not validate the integrity of the session 
token before granting access. By replaying a captured expired token with a 
modified timestamp, an attacker can bypass authentication entirely.

**Steps to Reproduce:**
1. Capture a valid session token using a proxy tool.
2. Modify the `exp` (expiry) claim in the JWT payload without updating the signature.
3. Submit the modified token in the Authorization header.
4. Access is granted despite the invalid signature.

**Impact:**
An unauthenticated attacker with network access to the admin portal can gain 
full administrative access, enabling data exfiltration, configuration changes, 
and creation of backdoor accounts.

**Recommendation:**
1. Ensure JWT signature validation is enforced on every request.
2. Use a well-maintained JWT library — do not implement your own validation.
3. Deploy a test that verifies token tampering is rejected.

**References:**
- OWASP JWT Security — https://owasp.org/www-project-web-security-testing-guide/

---

## Methodology

Testing was conducted [manually / using automated tools / both]. The following 
methodology was applied:

- Reconnaissance: [passive/active]
- Authentication testing
- Session management testing
- Input validation and injection testing
- Access control and privilege escalation testing
- API security testing

Part 4: Responsible Disclosure Communication

Initial disclosure to a vendor

When you discover a vulnerability in someone else’s software:

Subject: Security Vulnerability Report — [Product Name]

Dear [Company] Security Team,

I am writing to report a security vulnerability I discovered in [product name] 
version [X.Y]. I have followed responsible disclosure practices and am 
contacting you privately before any public disclosure.

**Summary:** A [vulnerability type] vulnerability in [component] allows 
[impact], without requiring authentication.

**Severity:** High (estimated CVSS 8.1)
**CVE:** Not yet requested
**Affected version:** [version]

I have included a proof-of-concept in the attached document. I request a 
30-day remediation window before I publish this finding publicly.

Please acknowledge this report within 5 business days. I can be reached at 
[email] and am happy to assist with verification or remediation guidance.

Best regards,
[Name]

Vendor acknowledgement response

Subject: Re: Security Vulnerability Report — [Product Name]

Dear [Name],

Thank you for reporting this vulnerability through responsible disclosure.

We have received your report and are investigating. Our initial assessment 
confirms the issue you described. We are working on a fix and expect to have 
a patch available within [timeframe].

We will keep you informed as we progress and will credit you in the advisory 
when published, unless you prefer to remain anonymous.

Best regards,
[Vendor Security Team]

Part 5: Incident Communication to Customers

When a security incident affects customers, communication must be transparent, precise about what is known and unknown, and actionable.

Breach notification template

Subject: Important Security Notice Regarding Your Account

Dear [Name / Customer],

We are writing to inform you of a security incident that may have affected 
your account.

**What happened:**
On [date], we detected unauthorised access to [specific system/data type]. 
We immediately took steps to contain the incident and have since confirmed 
the unauthorised access has been terminated.

**What information was affected:**
Based on our investigation, the following types of information may have 
been accessed: [list the specific data types — e.g., email addresses, 
hashed passwords — be specific, never vague].

**What information was NOT affected:**
Payment card information and passwords [are/are not] stored in the affected 
system. [Be specific about what was not compromised.]

**What we are doing:**
- We have patched the vulnerability that enabled the incident.
- We are working with [law enforcement / security experts] to investigate.
- We have implemented [specific measures] to prevent recurrence.

**What you should do:**
1. [Specific action, e.g., reset your password at: link]
2. [If passwords may be affected: update your password on any other service 
   where you used the same password]
3. Be alert to phishing emails claiming to be from us. We will never ask 
   for your password by email.

We apologise for this incident. If you have questions, please contact 
[contact method].

[Company Name]

Vocabulary Quick Reference

Situation	Phrase
Describing a finding	”An attacker could exploit this to…”
Rating severity	”This is rated Critical (CVSS X.Y). Immediate remediation is required.”
Recommending action	”We strongly recommend updating to version [X] as soon as possible.”
Communicating risk	”If exploited, this could allow…”
Disclosing to a vendor	”I am reporting this through responsible disclosure…”
Incident comms	”We are writing to inform you of a security incident…”
Acknowledging uncertainty	”Our investigation is ongoing. We will provide updates as more information becomes available.”