Writing Security Reports in English: CVE Advisories, Penetration Test Findings

Security reports communicate risk to two very different audiences: technical engineers who need to understand and fix a vulnerability, and executives or clients who need to understand business risk. Writing security reports that work for both audiences requires a specific vocabulary and structure. This guide covers CVE advisories, penetration test findings, and the language that makes security reports clear and actionable.

Security Report Structure

Most professional security reports follow a consistent structure:

Section	Purpose	Audience
Executive summary	Non-technical overview of findings and overall risk	Management, clients
Scope	What was tested, and what was out of scope	All
Methodology	How the testing was conducted	Technical reviewers
Findings	Detailed list of vulnerabilities discovered	Technical engineers
Risk ratings	Severity classification for each finding	All
Remediation guidance	Specific steps to fix each finding	Engineers
Appendices	Technical evidence, screenshots, payloads	Technical reviewers

Executive Summary Language

The executive summary must be readable by a non-technical audience. Avoid jargon; focus on risk and impact.

Good executive summary pattern:

• Start with the overall risk posture: “The penetration test identified X findings, of which Y are classified as Critical or High severity.”
• Connect to business impact: “The most critical finding allows an unauthenticated attacker to gain administrative access to the customer database.”
• State what was found to be working well: “The application demonstrated strong input validation and appropriate session management controls.”
• Recommend action: “We recommend prioritising the remediation of all Critical findings before the planned production launch.”

Severity Ratings

Security findings are typically rated using one of two systems: CVSS (Common Vulnerability Scoring System) or an organisation’s own classification.

Rating	CVSS Score Range	Typical meaning
Critical	9.0–10.0	Remote code execution, unauthenticated data breach
High	7.0–8.9	Significant data exposure, privilege escalation
Medium	4.0–6.9	Requires authentication or specific conditions
Low	0.1–3.9	Minimal impact; informational concern
Informational	N/A	Best-practice improvement, not a vulnerability

Writing about severity:

• “This finding has been rated Critical (CVSS 9.8) due to the ease of exploitation and the complete compromise of confidentiality and integrity.”
• “This is classified as Informational — it does not represent an exploitable vulnerability but is a deviation from security best practices.”

CVE Advisory Language

A CVE (Common Vulnerabilities and Exposures) advisory is a public disclosure of a security vulnerability. CVE advisories follow a strict format.

Key vocabulary:

Term	Meaning
CVE ID	The unique identifier (e.g. CVE-2024-12345)
Affected versions	The specific software versions that contain the vulnerability
Fixed in	The version where the vulnerability is patched
Attack vector	How the attacker reaches the vulnerable component (Network, Adjacent, Local, Physical)
Attack complexity	How difficult the attack is to execute (Low or High)
Privileges required	Whether the attacker needs to be authenticated (None, Low, High)
User interaction	Whether a victim must take an action (None or Required)

Sample CVE advisory language: “A SQL injection vulnerability exists in the user search endpoint of Example Software versions 2.1.0 through 2.3.4. An unauthenticated remote attacker can exploit this vulnerability to extract the contents of the database, including user credentials and session tokens. This issue is fixed in version 2.3.5. Users are strongly advised to upgrade immediately.”

Penetration Test Finding Language

Each finding in a pentest report should follow a consistent structure:

1. Title — Short, descriptive: “SQL Injection in User Search Endpoint”
2. Severity — Critical / High / Medium / Low / Informational
3. Description — What the vulnerability is and why it exists
4. Evidence — Proof of exploitation (request/response, screenshots)
5. Impact — What an attacker could achieve
6. Remediation — Specific, actionable steps to fix it
7. References — Relevant CVEs, OWASP references, CWE numbers

Finding description language:

• “During testing, it was discovered that the q parameter in the /api/users/search endpoint is not sanitised before being included in a database query.”
• “This vulnerability was successfully exploited to extract the contents of the users table, including hashed passwords and email addresses.”

Remediation language:

• “Implement parameterised queries (also known as prepared statements) for all database interactions.”
• “Conduct a codebase-wide audit to identify other endpoints that may be affected by the same pattern.”
• “Add automated security testing to the CI/CD pipeline to detect injection vulnerabilities before deployment.”

Example Sentences

1. “The executive summary notes that three Critical findings were identified, all of which are remotely exploitable without authentication and should be treated as an immediate priority.”
2. “This finding has been rated High severity — while it requires an authenticated session to exploit, a successful attack would grant the attacker access to all data within the organisation.”
3. “The CVE advisory for this vulnerability specifies that all versions prior to 4.2.1 are affected; organisations running earlier versions should apply the patch within 48 hours.”
4. “Remediation for this finding requires replacing the dynamic query construction in the account controller with parameterised queries using the existing ORM framework.”
5. “The penetration test scope covered the external-facing web application and the internal API, but explicitly excluded the mobile application and third-party integrations, which will be assessed separately.”