Англійська для інженерів безпеки: CVE Advisories and Vulnerability Reports

Інженери безпеки пишуть документи, які читаються під тиском: попередження про вразливість, які CISO пересилають до рад, звіти про тестування проникнення, на які розробники повинні діяти, і повідомлення про інцидент, які надходять до клієнтів під час активних порушень. Ставки на неясність написання великі.

Цей посібник містить певний словник, шаблони зв’ язку і шаблони документів, які потрібні інженерам з безпеки для написання ефективних попереджень, відповідального розкриття вразливостей і чіткого повідомлення про результати досліджень безпеки.

---

Частина 1: Основні поняття з безпеки комунікації

Термінологія вразливостей і експлойтів

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 (англійською)

Оцінку CVSS завжди слід вказувати у контексті:

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

---

Частина 2: Писання попереджень про вразливість

Повідомлення про вразливість — це офіційний документ, який сповіщає користувачів про проблему безпеки і вказує їм, що робити. Вона повинна бути ясною, точною і дієвою.

Консультативний шаблон

# 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 |

---

Частина 3: Підписання звітності про тестування проникнення

Звіт про пентест читається як технічними командами (які повинні відтворити і виправити результати), так і керівництвом (яке повинно зрозуміти бізнес-ризик). Вона повинна служити обом аудиторіям.

Структура звіту

# 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

---

Частина 4: Відповідальність за розголошення інформації

Початкове розкриття інформації постачальнику

Коли ви виявляєте вразливість у програмі іншої людини:

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]

Відповідь на підтвердження постачальника

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]

---

Частина 5: Інциденти комунікації з клієнтами

Коли інцидент безпеки впливає на клієнтів, комунікація повинна бути прозорою, точною про те, що відоме і невідоме, і дієздатною.

Шаблон сповіщення про порушення

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]

---

Словник скорочених назв

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

---

Зв’язані ресурси

• Англійська для DevOps: Runbooks, Post-Mortems, і Incident Calls
• Кибербезпека: словосполучення
• Як писати пост-морт англійською