Англійська мова для звітів про вразливість безпеки: CVE і мова розголошення

Звіт про вразливість є одним з найважливіших документів у програмному забезпеченні. Вона повинна передати що пошкоджено, *як погано це *, і як це виправити — точно, спокійно, і без перебільшення або сенсаційності. Мова спеціалізована, і якщо її неправильно використати, це пошкодить репутацію. Цей посібник містить англійську мову про CVE, тяжкість, вплив і відповідальне розголошення.

---

Анатомія звітності про вразливість

Відповідь на сильний звіт, в порядку:

1. ** Що ** це за вразливість (класи і компоненти).
2. ** Серйозність ** (наскільки серйозно, ідеально з показником CVSS).
3. ** Вплив ** (що може зробити атакуючий).
4. ** Репродукція ** (доказ того, що це справжнє).
5. Впливові версії (обсяг).
6. ** Ремедиація ** (як виправити або зменшити).

Кожен розділ має свою власну традиційну фразу.

---

Назва уразливості

Використовуйте стандартний словник класів уразливостей — він свідчить про компетентність і дає змогу читачам дізнатися, чого їх очікувати:

• ** injection ** — введення SQL, введення команди. * « Це введення SQL у кінцеву точку пошуку. » *
• ** XSS (крос-сайт скриптування) ** — * “Збережений XSS у полі коментаря.” *
• ** CSRF (фальсифікація запитів між сайтами) **
• ** SSRF (фальсифікація запиту на стороні сервера) **
• RCE (віддалене виконання коду) — найсерйозніший клас. “Це дозволяє неавтентифіковане RCE.”
• ** підвищення привілеїв ** — отримання більшого доступу. * “Порушення підвищення привілеїв дозволяє користувачеві стати адміністратором.” *
• ** path traversal ** — * « Вада перетину шляху виявляє довільні файли. » *
• ** IDOR (небезпечне посилання на прямий об’ єкт) ** — доступ до даних інших користувачів за допомогою зміни ідентифікатора.
• ** розкриття інформації / витік ** — виведення даних. * « Розкриття інформації у відповіді на помилку. » *

«Неавтентифікований атакуючий може досягти віддаленого виконання коду через помилку десеріалізації в кінцевій точці імпорту»

---

Серйозна мова

Для оцінки тяжкості використовується ** CVSS ** (Система оцінки загальної вразливості), оцінка від 0 до 10 з діапазонами:

• Критична (9. 0- 10. 0)
• Висока (7,0-8,9)
• ** Середня** (4, 0- 6, 9)
• ** Низька** (0, 1- 3, 9)

Фраза:

• • « Цей рівень оцінено як ** Критичний ** (CVSS 9. 8) ». *
• “Ми оцінили це як Висока тяжкість.”
• • “Базова оцінка 8,1 через вектор мережевої атаки і високу ступінь впливу.” *

Будьте конкретними щодо умов, які впливають на тяжкість:

• ** вектор атаки ** — мережа, сусідня, локальна, фізична. * « Можна використовувати мережу, без взаємодії з користувачем. » *
• ** вимога щодо привілеїв ** — * « Розпізнавання не потрібне. » *
• user interaction — “Вимагає, щоб жертва клацнула на посилання.”

Фраза “pre-auth” (до автентифікації) проти “post-auth” (після) є критичною: помилки перед автентифікацією набагато небезпечніші.

---

Точний опис удару

Вплив є місцем, де звіти часто провалюються — або нечіткі («це погано»), або гіперболічні. Вкажіть, що саме може зробити нападник.

• • “Злочинець може прочитати будь-які файли на вузлі.” *
• “Це дозволяє повне перехоплення облікового запису.”
• “Злочинець може виконувати довільні команди від імені користувача служби.”
• “Порушення дає доступ до персональних даних інших користувачів.”

Використовувати ** триадний ** форматування ЦРУ, коли це корисно — конфіденційність, цілісність, доступність:

• • “Це впливає на конфіденційність (розкриття даних), але не на цілісність.” *
• “Успішний експлойт знижує доступність — це призведе до аварії служби.”

Уникайте неприйнятних слів: “може, можливо, дозволити” — скажіть “дозволяє”, якщо це так, “може дозволити за X умови”, якщо це умовне.

---

Запис кроків відтворення

Доклад без відтворення - це твердження, а не висновок. Бути точним і мінімальним — довести концепцію, а не навчальний посібник.

Steps to reproduce:
1. Send a POST to /api/import with the payload below.
2. Observe the server executes the embedded command.

Proof of concept:
  POST /api/import
  Content-Type: application/json
  { "data": "<crafted payload>" }

Result: the command `id` runs and returns the service user.

Фрази:

• “Наступний запит демонструє проблему:”
• “Це доведення концепції виконує id як користувач сервісу.”
• “Уразливість може бути викликана одним неавтентифікованим запитом.”

Редагувати все небезпечне при публічному поділі: “Payload redacted pending the fix.”

---

Вплив версій і виправлення

Обсяг стану і виправлення однозначно:

• “Вплив версій: 2.0.0 до 2.4.1.”
• “Віправлено в 2. 4. 2.”
• “Версії, що випущені до 2.4.2, є вразливими.”

Фраза для виправлення:

• “Підвищити до 2.4.2 або пізніше.”
• • “Як запобіжний захід, вимикайте функцію імпорту, поки не зможете встановити латку.” *
• • « Не існує жодного способу вирішити проблему; потрібна латка. » *

Розрізняти ** виправлення ** (вилучення вразливості) від ** зменшення ** (зменшення ризику без повного виправлення).

---

Відповідальна мова розкриття

Коли ви звітуєте перед продавцем, тон повинен бути професійним і співпрацюючим, а не погрожуючим.

• • “Ми повідомляємо про це приватно під відповідальним розголошенням.” *
• • “Ми пропонуємо 90-денний термін розкриття інформації, відповідно до норм промисловості.” *
• “Будь ласка, підтвердіть отримання і очікувану дату відновлення.”
• “Ми будемо координувати публічне розкриття, як тільки стане доступною латка.”
• “Выпуск находится под эмбарго до согласованной даты раскрытия.”

Ключеві терміни:

• відповідальна/координована розкриття — спочатку приватне повідомлення.
• ** розкриття у часі ** — узгоджене вікно перед публікацією.
• embargo — затримка публічних даних.
• ** PoC (доказ концепції) ** — демонстраційний код.
• ** patch / advisory ** — виправлення і його оголошення.

“Ми повідомили про це приватно і погодилися на 90-денне ембарго. Ми опублікуємо попередження і CVE, як тільки патч буде випущений»

---

До і після

** До: ** « У процесі імпорту є дуже погана дірка безпеки, хакери можуть повністю знищити все, вам слід виправити це якомога швидше!!! »

Это тревожно, неконкретно и непрофессионально.

** Після: ** “Розгортання: Неавтентифікований RCE в кінцевій точці /api/import через небезпечну десеріалізацію. Ступінь важкості: Критичний (CVSS 9. 8), вектор мережевого нападу, не потрібна автентифікація. Вплив: Довільне виконання команди від імені користувача служби, що призвело до повного порушення безпеки вузла. Вплив: 2. 0. 0–2. 4. 1. Розв’ язання: Оновлення до 2. 4. 2; як запобіжний захід, вимикання можливості імпорту. ПоК приєднано, вантаж редаговано»

Другу приймають серйозно саме тому, що вона спокійна і конкретна.

---

Поширені помилки

• “Катастрофа, повне знищення” звучить як аматорський вислів. Нехай факти переважають.
• Неясний вплив. “Це небезпечно” - сказати що може зробити нападник.
• ** Плутанина між виправленням і запобіганням. ** Запобігання зменшує ризик; виправлення усуває ваду.
• ** До- автентифікація проти пост- автентифікації залишено невідомим. ** Завжди повідомляти, чи потрібна автентифікація.
• Нет воспроизведения. Без доказательства подлинности это непроверенное утверждение.
• ** Перевикористання “може потенційно можливо”. ** Зазначте, що * є *, а потім обмежтеся тільки справжніми умовними частинами.

---

Ключевые вещи

• Структура: що, тяжкість, вплив, відтворення, зачеплені версії, усунення.
• Назвіть ** клас уразливості ** і вкажіть ** до- автентифікації проти після- автентифікації **.
• Надати ** CVSS бал ** і пояснити, що його породжує.
• Описати вплив як ** те, що нападник може насправді зробити **.
• Зберігайте тон спокійним і точним — факти, а не тривога — і використовуйте відповідальну розголошення мову.

Відмінний звіт про вразливість заслуговує на довіру через ясність. Напиши так, щоб читач знав, наскільки це погано і що робити далі.

Національні мови: мова, що використовується для спілкування ненаціональними групами

Метою створення ефективних звітів про вразливість безпеки є не тільки передання технічних деталей; це про комунікацію достатньо точно для глобальної аудиторії - включаючи розробників, які можуть вивчати професійну англійську як другу мову. Хоча основні концепції CVE (Common Vulnerabilities and Exposures) і мови розкриття є універсальними, тонкі відмінності у формулюванні можуть суттєво вплинути на ясність і розуміння. Для тих, хто розвиває свою вправність в англійській мові, фокусування на точності і уникнення надто складних структур речень є найважливішим. Поширена пастка полягає у тому, що технічні терміни перекладаються ідеально; завжди двічі перевіряйте визначення у контексті звіту про безпеку, щоб переконатися, що всі розуміють термінологію однаково.

Розгляньте цей сценарій: Ви переглядаєте запит на завантаження, надісланий колегою, який є відносно новим для команди. У описі зазначено: « Кінечна точка API є уразливою через недостатню перевірку вхідних даних, що може призвести до можливого віддаленого виконання коду ». Хоча це технічно вірно, у описі відсутній важливий контекст для тих, хто не знайомий з усім жаргоном. Ефективнішою формулюванням може бути: «Кінечна точка API /users/create є вразливою, тому що вона неправильно перевіряє введення користувача. Це дозволяє атакуючому надсилати шкідливі дані, які можуть виконувати довільні команди на сервері, що може призвести до компромісу системи. Зауважте, що ця версія розбиває проблему на менші, більш перетравлювані частини і пояснює * чому * недостатня перевірка є проблематичною — « дозволяє атакуючому … » — замість того, щоб просто стверджувати це як факт.

Інша часта проблема виникає при описі впливу вразливості. Замість того, щоб просто сказати “високий рівень”, спробуйте оцінити потенційний збиток. Замість « Система може бути повністю порушена », розгляньте « Успішний експлойт може дозволити нападнику отримати повний контроль над сервером, що може призвести до крадіжки даних або атак відмови в обслуговуванні ». Використання вимірюваних термінів — таких як « крадіжка даних » або « відмова в обслуговуванні » — допомагає зацікавленим сторонам зрозуміти потенційні наслідки і визначити пріоритети зусиль по усуненню. Пам’ятайте, ясність переважає технічний блиск, коли йдеться про ризики безпеки.

Нарешті, пам’ятайте про пасивний голос. Хоча це іноді може звучати більш формально, надмірне використання може затемнити відповідальність. Замість « Вразливість була виявлена дослідником », скажіть « Дослідник визначив цю вразливість ». Ця активна фраза чітко визначає власника і відповідальність, що є ключовим у середовищі співпраці. Сфокусуйтеся на використанні прямої, короткої мови, яка мінімізує неоднозначність і сприяє ясному спілкуванню між різними командами.