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.”

Navigating the Nuances: Professional English for Security Reporting

Writing clear and concise security reports is crucial, regardless of your native language. However, for non-native speakers, mastering the specific vocabulary and phrasing used in professional security reporting can be a significant hurdle. It’s not just about conveying technical information; it’s about demonstrating credibility, understanding industry standards, and facilitating effective collaboration within a development team. Let’s consider some common pitfalls and how to approach them with a focus on precision and clarity.

One frequent issue is the tendency to translate directly from one’s native language, resulting in awkward phrasing or omitting critical qualifiers. For example, saying “This vulnerability is dangerous” sounds overly assertive compared to “This vulnerability presents a potential risk” which allows for more nuanced discussion about impact and mitigation. Similarly, using terms like ‘bug’ can be seen as too informal within a security context; replacing it with ‘vulnerability’ or ‘security flaw’ immediately elevates the tone. Pay particular attention to modal verbs – “should,” “must,” “may” – they carry different levels of obligation and recommendation that require careful consideration when crafting remediation steps.

Another area needing focus is structuring your reports for an international audience. A standard CVE advisory often includes a detailed technical description, but it’s equally important to provide a high-level summary accessible to stakeholders who may not have the same level of technical expertise. Think about phrasing like “Impact: This vulnerability could allow unauthorized access to sensitive data if exploited.” versus simply stating “Exploitable vulnerability.” The latter lacks context and doesn’t immediately convey the potential consequences. Remember, clarity is paramount; avoid jargon unless absolutely necessary and always define it clearly when used.

Finally, consider the tone of your communication. Security reports are often reviewed by individuals from diverse backgrounds and technical levels. Maintaining a professional, objective, and collaborative tone—avoiding accusatory language or overly technical detail without context—is vital for fostering trust and facilitating effective problem-solving. When drafting a pull request description referencing a finding, instead of saying “Fix this critical bug!”, consider “Investigate and remediate the identified vulnerability as per severity rating.” This demonstrates an understanding of the reporting process and promotes a constructive dialogue.