Безпека очима QA: модель загроз і OWASP Top 10

Зміст

Питання «а що ти перевіриш із погляду безпеки?» провалюють однаково: у відповідь сиплються назви . Назви — кінець розмови, а не початок. Початок — два питання: що саме ми захищаємо і від кого. Без них перелік перевірок не має пріоритету, а знахідка — ваги: «я вставив лапку в поле» ще не баг-репорт, доки не сказано, що ламається і чому це дорого.

Ця глава — словник і карта розділу; на ній стоять наступні глави: автентифікація, авторизація, сесії й токени.

Три цілі: конфіденційність, цілісність, доступність

FIPS PUB 199 не лишає «безпеку» абстракцією — він фіксує, що цілей рівно три: «The FISMA defines three security objectives for information and information systems». Саму стандарт означує через них: захист «in order to provide confidentiality, integrity, and availability».

Ціль	Означення FIPS 199
Конфіденційність (confidentiality)	збереження авторизованих обмежень на доступ до інформації та її розкриття
Цілісність (integrity)	захист від неналежної зміни або знищення, включно з незаперечністю й автентичністю
Доступність (availability)	забезпечення вчасного й надійного доступу до інформації та її використання

Дзеркально стандарт описує втрату кожної цілі й саме через ці втрати означує «порушення безпеки». Тож питання «чи це взагалі про безпеку?» має механічну відповідь: покажи, яка ціль просіла. Три літери C-I-A — індустріальний ужиток, а не термін стандарту.

Розбіжність, яку варто знати наперед. У FIPS доступ належить конфіденційності, а цілісність відповідає за зміну й знищення. проводить межу інакше: integrity там — «the degree to which only authorized access and modification is allowed». Обидва означення канонічні у своїх рамках: FIPS формулює цілі, ISTQB — вимірювані характеристики. Різниця не косметична — звіт «стільки-то дефектів цілісності» без назви словника не означає нічого.

Ті самі три елементи стоять усередині сусідніх означень: NIST означує через утрату цих цілей, — через тих самих трьох. Звідси й практика: знахідка кладеться в одну вісь, і саме вісь пояснює бізнесу ціну; доступність — теж безпека, а і автентичність канон кладе всередину цілісності.

Чотири слова, які плутають щодня

Вразливість (vulnerability) — це стан: слабкість, «що можна задіяти й дістати шкоду» (ISTQB). RFC 4949 додає, де вона живе: у дизайні, реалізації або в експлуатації й супроводі — тож дизайнову вразливість ловлять рев'ю вимог, у коді її може не бути взагалі. І спрацювати слабкість може без : або подія може її «intentionally exploit or accidentally trigger» (NIST).

(threat) — це можливість: «a potential for violation of security». Виконавця RFC 4949 називає окремо — threat agent, і ним може бути й подія. Загроза буває навмисною або випадковою: помилка людини чи збій обладнання підпадають під означення нарівні зі зловмисником, тож перелік лише зі зловмисниками неповний за побудовою. Окремий випадок — , часто від авторизованого користувача.

Атака — це вже дія: «an intentional act by which an entity attempts to evade security services and violate the security policy» (RFC 4949). Тут пастка: у глосарії ISTQB attack означає тестовий підхід — наш метод пошуку дефектів, — а дію зловмисника він носить окремим записом security attack. Обидва канони чинні, тож у безпековому сенсі пишемо саме security attack. І ще розріз, важливий для перевірок: активна атака змінює ресурси системи, пасивна «does not affect system resources» — тож «дані не змінилися» її не виявляє.

(attack vector) — шлях або засіб доступу до системи зі зловмисною метою: один вектор веде до різних вразливостей, одна вразливість досягається різними векторами. І атакувальником канон уважає «a person or process», що дістає доступ без авторизації, — тож інтеграції, заплановані задачі (cron) і сервісні токени входять у той самий перелік входів, що й форма логіну.

Ланка, яку варто знати напамʼять: «not every threat results in an attack, and not every attack succeeds» — успіх залежить від глибини вразливості, сили атаки й дієвості контрзаходів, тож «пейлоад не спрацював» не дорівнює «вразливості немає».

Ризик: те, що перетворює перелік на пріоритет

Окремої аксіоматики під безпеку ISTQB не заводить: security risk — «a quality risk related to security», а вразливості безпеки Foundation-силабус наводить серед прикладів продуктових . Тобто працює та сама рамка, що й у ризик-орієнтованому тестуванні. Ризик — функція впливу та ймовірності; без обох множників це список страхів.

Звідси канонічний ланцюг: «security test objectives are based on security risks», а ризики знаходить оцінка — що під ризиком і наскільки. За цією рамкою перевірка, яку не звести до названого ризику, у план не потрапляє. Сама оцінка — «a snapshot at a given point in time», тож її повторюють регулярно, а результат повертають у план тестів.

Тестування — не єдина відповідь: RFC 4949 перелічує чотири способи поводження з ризиком — уникнення, передача, обмеження контролями і прийняття. «Приймаємо» — легітимний результат, якщо ухвалений явно; ціль керування — прийнятний рівень, а не нуль. І ризик контекстний: NIST говорить про «relative impact … to a user's environment».

Розбіжність, яку глава не згладжує. На сторінці NIST CSRC серед синонімів threat стоїть negative risk — там загроза й негативний ризик підмінюють одне одного. RFC 4949 так не робить: ризик означено через загрозу («an expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability»), тож знака рівності між ними в цій рамці немає. ISTQB тримає третю рамку — ризик якості. Цитуючи, називайте публікацію поіменно.

Мислення атакувальника: use case проти abuse case

— це use case зі злим наміром: сценарій, у якому «some actors with malicious intent are causing harm» (ISTQB), або, з боку функції, «a way to use a feature that was not expected by the implementer».

Про статус техніки одразу: шпаргалка OWASP, яка її описує, має позначку «(Historical)» і сама каже причину — «abuse cases are rarely used in practice». Тобто це описана техніка, а не чинна рекомендація; цінна вона як спосіб думати. А думає вона в правильний бік: «зробіть безпечно» — не вимога, треба «identify the attacks which the application must defend against, according to its business and technical context».

Далі найважливіше для QA. Відібраний сценарій «must become security requirements … or User Story acceptance criteria» — інакше його не оцінять і не реалізують, і кожен мусить мати унікальний ідентифікатор для . Саме з них ростуть перевірки: моделі служать «fuel for identification of concrete security tests». Автотест виконує тут ще одну роль — на контрзаходи: він показує, що захист усе ще на місці й його не прибрали випадково.

// ABUSE-014: клієнт не мусить відкрити чужий рахунок за прямим посиланням
test('ABUSE-014: чужий рахунок недоступний', async ({ request }) => {
  const res = await request.get('/api/invoices/1042'); // ресурс іншого власника
  expect(res.ok()).toBeFalsy();
});

Тест мінімальний навмисно: він фіксує інваріант і його ідентифікатор, а не техніку перевірки доступу — вона в главі про авторизацію.

Чому це робота QA, джерело каже прямо: функціональний тестувальник «має добре відчуття того, як функціональність має працювати, як не має і що змушує її падати». Найдорожчий клас, який техніка ловить, — зловживання функціональністю (у джерелі — «business logic attack»): помилки в коді немає, є непередбачений спосіб скористатися функцією — наприклад, перебрати акаунти через потік (вектор — у главі про автентифікацію). А фільтр, що робить вимогу вимогою, дає стандарт OWASP : вимога мусить бути перевірною, а перевірка — закінчуватися вердиктом pass або fail.

OWASP Top 10 як карта ризиків

— документ-орієнтир (standard awareness document), який «представляє широкий консенсус щодо найкритичніших ризиків безпеки вебзастосунків»: перелік того, що частіше за все ламається, а не готовий чекліст перевірок. Чинна редакція — 2025, восьма за ліком: A01 Broken Access Control · A02 Security Misconfiguration · A03 Software Supply Chain Failures · A04 Cryptographic Failures · A05 Injection · A06 Insecure Design · A07 Authentication Failures · A08 Software or Data Integrity Failures · A09 Security Logging and Alerting Failures · A10 Mishandling of Exceptional Conditions.

Зсуви, які змінюють читання старих звітів: A01 лишається ризиком №1, і влито саме в цю категорію; A02 піднялася з пʼятого місця у 2021 на друге; A03 — розширення A06:2021 (вразливі й застарілі компоненти) на весь ланцюг. Порівнювати номери між редакціями наосліп не можна.

Як список збирають — теж частина сильної відповіді. Він data-informed, але не сліпо data-driven: більшість категорій ранжують за даними (понад 2,8 млн застосунків), ще дві підіймає опитування спільноти, бо дані неповні. Головне обмеження записане в самому документі: результати здебільшого обмежені тим, що індустрія вміє перевіряти автоматизовано — ризики, які автоматом не тестуються, недопредставлені за побудовою. Звідси й висновок: «ми пройшли Top 10» не дорівнює «ми перевірили безпеку». Друге: категорія — не дефект, а кошик класів слабкостей: аналізованих у цій редакції 589, а десять категорій разом покривають 248 CWE, згрупованих за першопричиною, а не за симптомом. Тому «перевірити A05» неможливо: треба спуститися до конкретного CWE.

Розділ веде далі по цій карті: автентифікація розбирає A07, авторизація — A01, сесії й токени — те, на чому обидві тримаються; механіка вебпонять — у HTTPS, TLS і безпека, автентифікація та авторизація і cookie, сесії та сховище браузера. Споріднений клас — (prompt injection) для застосунків на LLM: власної позиції в десятці веб-ризиків 2025 року вона не має, і сама редакція відсилає по нього до окремого списку OWASP для LLM, який розбирає розділ про AI.

І межа джерел: глосарій ISTQB не згадує OWASP жодного разу — він називає поіменно , CWE, CWSS і CAPEC. Термінологію беремо з ISTQB, карту ризиків — з OWASP.

CVE, CWE і CVSS: три різні речі

CWE — каталог класів слабкостей. Шапка MITRE формулює його з ключовим словом: слабкості, «які можуть стати вразливостями». В означенні ISTQB — «a community-developed list of common software and hardware weaknesses» — ця модальність губиться, а межа тримається саме на ній: вразливість це слабкість, яку вже можна задіяти. Це й пояснює, чому дає сотні збігів, а вразливостей серед них одиниці. CVE — навпаки, «каталог публічно розкритих вразливостей у випущених пакетах ПЗ»: конкретний запис про конкретний продукт. Канон розводить пару разом зі шкалами — оцінює вразливості, CWSS оцінює слабкості; поруч стоїть третій каталог, CAPEC (патерни кібератак). Є ще — щорічний зріз найнебезпечніших класів, зібраний зі статистики (випуск 2024 року — з датасету на 31 770 записів CVE); рік у посиланні обовʼязковий, і чеклистом цей список не є.

Пастка, на якій легко спіткнутися: кількість CVE не є метрикою безпеки. З CWE категорії A03 повʼязано лише 11 CVE, але вона дала найвищу середню частоту, 5,19 %, коли її таки тестували; A09 названо «неймовірно важкою для тестування» — лише 723 CVE. Мала кількість записів означає сліпу пляму інструментів, а не безпеку продукту. У щоденній роботі CVE живе в моніторингу компонентів: OWASP вимагає стежити за CVE, NVD і OSV (класика жанру — CVE-2021-44228, «Log4Shell»).

CVSS — «відкритий фреймворк для передавання характеристик і серйозності вразливостей ПЗ» (FIRST), тобто мова опису, а не база. Глосарій ISTQB дає коротшу форму — оцінювання «на основі легкості й впливу атаки», — і буквальне читання підводить: у специфікації всі метрики виставляються з припущення, що атакувальник має досконале знання про вразливість, тож «її важко знайти» на бал не впливає взагалі. Головне речення для співбесіди дає NVD: «CVSS не є мірою ризику» — це фактор пріоритизації, не готовий пріоритет.

У версії 4.0 груп метрик чотири: Base, Threat, Environmental і Supplemental (у 2.0 і 3.x їх було три, і «Temporal» у чужому звіті це ознака версії). Base — серйозність за характеристиками, постійними в часі, від 0.0 до 10.0, з якісною шкалою None 0.0 · Low 0.1–3.9 · Medium 4.0–6.9 · High 7.0–8.9 · Critical 9.0–10.0; бал під ваше середовище перераховує Environmental, а Supplemental на нього не впливає.

Найважливіше: публічні бази публікують лише Base (CVSS-B). NVD збагачує оцінками всі записи CVE, але не оцінює Temporal/Threat, Environmental і Supplemental — натомість дає калькулятор. Отже «9.8 у бюлетені» — Base-бал чужого середовища з дефолтами найгіршого сценарію. І окрема пастка: 10.0 інколи означає «даних немає» — коли вендор оголосив вразливість без деталей, NVD виставляє найгірший сценарій.

Роль QA: безпека живе в циклі, а не в кінці

Глосарій ISTQB означує (security testing) коротко — тип тестування, що встановлює безпеку компонента чи системи. Але у Foundation-каноні воно заходить з іншого боку: силабус розглядає чотири типи тестування, і безпеки серед них немає — вона стоїть серед нефункціональних ISO/IEC 25010, а поглиблення винесене в окрему гілку сертифікації. Тобто безпекова перевірка — це нефункціональне тестування характеристики Security, і аргумент «ми не робимо security testing, бо це не наш тип» не працює.

Друга теза — про час, і Advanced-силабус із безпеки формулює її без напівтонів: «security is not tested or patched into an already-built application. Rather, it is achieved through security-oriented design and verification throughout the process of construction». Активності безпеки не утворюють власного циклу — вони йдуть поруч з іншими роботами проєкту, у будь-якій моделі розробки, а сам цикл дає їм чотири перевірні речі: прописаний момент, чекпойнти рев'ю, чекпойнти тестування й та виходу.

Звʼязок зі будується через характеристику якості: Foundation-силабус каже, що нефункціональне тестування іноді доречно починати рано, бо пізнє виявлення таких дефектів серйозно загрожує проєкту, і прямо називає практику — виконувати його починаючи з рівня компонентних тестів, «this is a form of shift left». Найраніша точка входу — статика: статичний аналіз оцінює й безпеку, а серед дефектів, дешевших статично, названо вразливості на кшталт переповнення буфера.

І дві особливості звітності: результати самі є чутливими («only to those who need to know»), а безпекові дефекти в більшості проєктів мають вищу severity. Завершеність міряють не «прогнали всі кейси», а результатами проти й приймання.

Пентест і мандат: роль визначає не інструмент

Канон означує (penetration testing, у розмові — «пентест») не як окремий вид, а як підтип динамічного тестування безпеки застосунку: оцінювання слабкостей і вразливостей «without causing harm by mimicking an attacker». Найкорисніше — розвести його із сусідами, з якими плутають:

Термін	Означення каноном	Де межа
`red teaming`	підхід, що атакує систему, щоб навмисно змусити її дати шкідливий результат	навмисна шкода, чого пентест за означенням не робить
`security audit`	аудит, що оцінює процеси й інфраструктуру безпеки організації	предмет — організація, а не пошук вразливостей у компоненті
`destructive testing`	піддає систему зловмисним вводам, щоб викликати стійку аномальну поведінку	шкода є результатом за задумом
`vulnerability scanning`	тип статичного аналізу, що виявляє вразливості	статика проти динамічної симуляції атак

У Foundation-силабусі penetration testing — нуль входжень, тож вимагати пентесту «за ISTQB Foundation» не випадає. А ethical hacker канон означує так: «a security tester who follows the code of ethics of their organization» — жодного слова про техніку, межа проходить по мандату. Тестувальник, який обходить авторизацію на стенді за погодженням команди, працює в законній рамці; той самий крок без погодження робить його attacker за означенням, а знайдене не розсилається ширше кола тих, кому воно потрібне для роботи.

Операційне застереження, яке йде поруч із означенням. Означення дає канон: пентест — оцінювання «without causing harm». Дока описує не метод, а окрему процедуру — активне сканування цим інструментом: воно «is a real attack on those targets», і «actual damage can be done to a site's functionality, data, etc.»; той самий документ вимагає дозволу власника цілі. Означення це не скасовує: «без шкоди» — про метод і мандат, попередження — про ризик конкретного прогону конкретного інструмента. Практичний висновок один: активний скан — лише на своєму стенді й лише з дозволу власника системи.

Що вже видно у браузері

Перший інструмент нікуди йти не змушує. Панель Privacy and security у Chrome DevTools служить, щоб інспектувати сторонні cookie та перевіряти захист HTTPS; відкривається з Command menu — почніть друкувати privacy і виберіть Show privacy and security.

Коли основне не захищене, Security → Overview прямо каже «This page is not secure» і називає причину: URL було запитано по HTTP. Якщо проблема з HTTPS — так само каже, що саме пішло не так.
(mixed content) — коли основне походження захищене, а сторінка тягне ресурси з незахищених; такі сторінки захищені лише частково, бо HTTP-вміст доступний сніферам і вразливий до атак «людина посередині».
Від вердикту до конкретних запитів — один клік: у секції Non-secure origins натиснути View requests in Network panel; View certificate показує сертифікат походження.

Наступний крок — перехоплювальний й власний навмисно вразливий стенд, на якому активні перевірки законні: і те, і те — у главі про інструменти й процес security-тестування.

Типові помилки

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

Виглядає як «CVSS 9.8 — беремо першим», а насправді це Base-бал чужого середовища з дефолтами найгіршого сценарію; іноді 10.0 означає, що вендор не дав деталей.

Виглядає як «ми пройшли OWASP Top 10», а насправді пройдено десять кошиків, усередині яких 248 класів слабкостей.

Виглядає як «атака — це наш тестовий підхід», а насправді так означує attack глосарій ISTQB, а дію зловмисника він носить окремим записом security attack.

Виглядає як «payload не спрацював — вразливості немає», а насправді успіх атаки залежить від глибини вразливості, сили атаки й дієвості контрзаходів.

Підсумок

Безпека має рівно три осі. Знахідка кладеться в конфіденційність, цілісність або доступність — і саме вісь пояснює бізнесу ціну; словник, у рамці якого класифікуєте, треба називати.
Вразливість, загроза, атака й вектор — різні поняття: стан, можливість, дія і шлях. Не кожна загроза стає атакою і не кожна атака вдається.
Ризик — це вплив і ймовірність, і він контекстний. Оцінка старіє й повторюється, а відповідей на ризик чотири: уникнення, передача, обмеження, прийняття.
OWASP Top 10 — карта, а не чекліст. Категорія це кошик CWE за першопричиною; щоб дістати перевірку, треба спуститися до конкретного класу слабкості.
Каталоги не міряють безпеку, а роль визначає мандат. CVSS — фактор пріоритизації, не міра ризику; той самий крок із погодженням це робота тестувальника, без погодження — дія атакувальника.

Можливі питання

«Назвіть три цілі безпеки». Перевіряють, чи згадаєте доступність — її забувають найчастіше; сильна відповідь додає, що це осі класифікації знахідки.
«Чим вразливість відрізняється від загрози й від атаки?» Дивляться, чи розрізняєте стан, можливість і дію; плюс — згадка, що загроза буває випадковою.
«Що таке OWASP Top 10 і як ним користуватися?» Слабка відповідь — перелік напамʼять; сильна — документ-орієнтир, категорія як група CWE і визнане обмеження даними.
«У бюлетені CVSS 9.8. Ваші дії?» Чекають згадку про Base-бал чужого середовища, потребу перерахувати Environmental і про те, що CVSS не є мірою ризику.
«Ви QA чи пентестер? Де ваша межа?» Дивляться не на техніку, а на розуміння мандату: активні перевірки роблять лише з дозволу на конкретній цілі.
«Коли підключати безпеку в проєкті?» Очікують «не в кінці»: безпеку не латають у вже збудований застосунок, а частину вразливостей дешевше ловити статично.
«Як придумаєте безпекові перевірки для нової фічі?» Сильна відповідь іде від ризику до сценарію: які активи, які загрози, який сценарій зловживання — і як він стає .

Джерела

Три цілі: конфіденційність, цілісність, доступність

FIPS PUB 199 — Standards for Security Categorization of Federal Information and Information Systems — три , їхні дослівні означення, дзеркальний опис утрат і категоризація системи за впливом.
ISTQB Glossary — ті самі три поняття як вимірювані характеристики («the degree to which») і означення інформаційної безпеки.
ISTQB Certified Tester Advanced Level Syllabus — Security Tester v1.0 (2016) — ризик безпеки як утрата конфіденційності, цілісності або доступності (з посилкою на NIST 800-30).
NIST CSRC Glossary — vulnerability — вразливість, означена через відмову конфіденційності, цілісності або доступності.
NIST CSRC Glossary — risk — ризик, означений через ті самі три втрати.

Чотири слова, які плутають щодня

RFC 4949 — Internet Security Glossary, Version 2 — означення вразливості, загрози, дії-реалізації, й атаки; три типи вразливостей; активна проти пасивної; застереження про хибний ужиток терміна.
NIST CSRC Glossary — vulnerability — навмисне використання проти випадкового спрацювання слабкості.
NIST CSRC Glossary — threat — загроза через уражені активи й через експлуатацію вразливості.
ISTQB Glossary — вразливість, security attack, attack як тестовий підхід, вектор атаки, атакувальник, внутрішня загроза.

Ризик: те, що перетворює перелік на пріоритет

ISTQB Glossary — security risk як ризик якості, повʼязаний із безпекою.
ISTQB Certified Tester Advanced Level Syllabus — Security Tester v1.0 (2016) — вплив і ймовірність, цілі тестування з ризиків, оцінка як знімок і вимога повторювати її регулярно.
NIST CSRC Glossary — risk — керування ризиком до прийнятного рівня й відносність впливу до конкретного середовища.
NIST CSRC Glossary — threat — negative risk як синонім загрози в рамці NIST.
RFC 4949 — Internet Security Glossary, Version 2 — ризик як очікування втрати й чотири способи поводження з ним.
ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — §5.2.2: вразливості безпеки серед прикладів продуктових ризиків.

Мислення атакувальника: use case проти abuse case

ISTQB Glossary — означення abuse case як випадку використання з акторами зі злим наміром.
OWASP Cheat Sheet — Abuse Case — архівний статус техніки, дві її ролі, вимога перетворити сценарій на критерій приймання, унікальний ID, перехід до конкретних тестів, роль QA і зловживання функціональністю.
OWASP ASVS 5.0.0 — What is the ASVS? — вимога безпеки мусить бути перевірною з вердиктом pass/fail і мати демонстрований вплив на безпеку.

OWASP Top 10 як карта ризиків

OWASP Top 10:2025 — головна — що це за документ, чинна редакція та перелік десяти категорій.
OWASP Top 10:2025 — Introduction — восьма редакція, зсуви категорій, як збирають список, обмеження даних, категорія як група CWE і групування за першопричиною.
OWASP Top 10:2025 — Injection — місток: споріднений клас в LLM обговорюють окремо, у списку OWASP для LLM.
ISTQB Glossary — межа словника: OWASP у ньому не згадано, названі каталоги — CVE, CWE, CWSS, CAPEC.

CVE, CWE і CVSS: три різні речі

ISTQB Glossary — означення CVE, CWE, CWSS, CAPEC і CVSS та розведення пари «каталог вразливостей проти списку слабкостей».
MITRE — 2024 CWE Top 25 Most Dangerous Software Weaknesses — формулювання «можуть стати вразливостями», датасет із 31 770 записів CVE, банер про попередню версію, межі списку.
OWASP Top 10:2025 — Introduction — CWE типу «першопричина» проти CWE типу «симптом».
OWASP Top 10:2025 — A03 Software Supply Chain Failures — моніторинг CVE/NVD/OSV, приклад Log4Shell, 11 CVE проти найвищої середньої частоти.
OWASP Top 10:2025 — A09 Security Logging and Alerting Failures — 723 CVE як ознака сліпої плями інструментів, а не безпеки.
FIRST — CVSS v4.0 Specification Document — чотири групи метрик, діапазон 0.0–10.0, якісна шкала, припущення про досконале знання атакувальника й теза про лише Base у публічних базах.
NVD — Vulnerability Metrics (CVSS) — «CVSS не є мірою ризику», три групи в старих версіях, що саме NVD оцінює й чого не оцінює, оцінка 10.0 за найгіршим сценарієм.

Роль QA: безпека живе в циклі, а не в кінці

ISTQB Glossary — означення тестування безпеки й означення shift-left як підходу.
ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — §2.2.2: чотири типи тестування, безпека серед характеристик якості ISO 25010, ранній старт нефункціонального; §2.1.5: нефункціональне з рівня компонента як форма shift left; §3.1 і §3.1.3: статичний аналіз оцінює безпеку, вразливості серед дефектів, дешевших статично; §0.3: поглиблення винесене в Specialist stream.
ISTQB Certified Tester Advanced Level Syllabus — Security Tester v1.0 (2016) — безпеку не латають у готовий застосунок, чотири речі, які цикл дає тестуванню безпеки, звітність за принципом need-to-know, вища severity й критерій завершеності.

Пентест і мандат: роль визначає не інструмент

ISTQB Glossary — означення пентесту, динамічного тестування безпеки, red teaming, аудиту безпеки, деструктивного тестування, сканування вразливостей, й атакувальника.
ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — нуль входжень penetration testing у Foundation-каноні.
ISTQB Certified Tester Advanced Level Syllabus — Security Tester v1.0 (2016) — поводження з результатами за принципом need-to-know як частина мандату.
ZAP – Getting Started — попередження, що активне сканування є справжньою атакою й може завдати реальної шкоди, і вимога мати дозвіл на тестування цілі.

Що вже видно у браузері

Chrome DevTools — Privacy and security panel — призначення панелі, дві секції, спосіб відкриття, вердикт про незахищену сторінку, змішаний контент, перехід до незахищених запитів і перегляд сертифіката.

Назвіть три цілі безпеки. Навіщо вони тестувальнику?

Канон FIPS PUB 199 фіксує рівно три: конфіденційність (confidentiality), цілісність (integrity) і доступність (availability). Конфіденційність — про те, кому дозволено дістатися до даних і кому їх можна розкривати. Цілісність — про захист від сторонньої зміни й знищення; сюди ж канон кладе автентичність і . Доступність — про те, щоб дані й функції були під рукою вчасно і без збоїв. Стандарт описує ще й зворотний бік — утрату кожної цілі, — і саме через утрати означує порушення безпеки. Практичний наслідок: питання «чи це взагалі безпековий баг?» має механічну відповідь — назви вісь, яка просіла. Це ж дає мову для розмови з бізнесом: «у пік продажів кошик недоступний» звучить інакше, ніж «сторінка не вантажиться». Скорочення C-I-A — індустріальний ужиток, самої абревіатури стандарт не вводить. І типова прогалина: доступність згадують найрідше, хоча в обслуговуванні й зависла черга — теж безпека.

Чим відрізняються вразливість, загроза, атака й вектор атаки?

Це чотири різні сутності: стан, можливість, дія і шлях. (vulnerability) — слабке місце, яким можна скористатися й дістати шкоду; RFC 4949 нагадує, що вона зʼявляється не лише в коді, а й у дизайні та в тому, як систему експлуатують і супроводжують; дизайнову слабкість тому й шукають на рев'ю вимог — усередині реалізації її може взагалі не бути. (threat) — це ще не подія, а сама можливість порушення безпеки; канон називає окремим терміном, threat agent. Security attack — уже конкретна навмисна дія, спроба обійти захист і порушити політику безпеки. (attack vector) — це шлях чи спосіб, яким до системи дістаються зі зловмисним наміром: одним шляхом виходять на різні слабкості, а до однієї слабкості ведуть різні шляхи. Ланцюг складається так: носій → загроза → вектор → вразливість → → втрата однієї з трьох цілей. На співбесіді перевіряють саме вміння не змішувати ці слова: фраза «у нас загроза SQL-інʼєкції» неохайна, бо тут або клас слабкості, або дія — залежно від того, що мали на увазі.

Чи буває загроза без зловмисника?

Так, і це один із найчастіших пропусків у відповідях. Означення покриває і навмисне, і випадкове: помилка оператора, збій диска, крива міграція даних підпадають під нього нарівні з атакою. NIST формулює це через дві різні дії над слабкістю — її можна свідомо задіяти або випадково зачепити. Тому перелік загроз, у якому самі лише зловмисники, неповний за побудовою: випадкова подія підпадає під те саме означення, що й напад. Окремим рядком стоїть — часто це цілком авторизований користувач, який робить те, на що формально має право. Для QA висновок прямий: сценарії «адмін масово видалив не те», «інтеграція залила дублікати», «нода лягла під навантаженням» теж безпекові, і в їх ніхто, крім тестувальника, не принесе.

«Пейлоад не спрацював — значить, вразливості немає». Погоджуєтесь?

Ні. Канон розводить три речі: загроза не зобовʼязана вилитися в атаку, а атака — досягти мети. Успіх залежить від того, наскільки глибока сама слабкість, наскільки сильна спроба і наскільки дієві контрзаходи. Тобто конкретний рядок міг не пройти через фільтр на периметрі, екранування виводу чи обмеження довжини поля — а слабкість під ними лишилася нерушеною. Зворотний бік теж вірний: «лапка не зламала форму» — це результат одного експерименту, а не вердикт про клас слабкості. Коректне формулювання у звіті — «цим вектором відтворити не вдалося», а не «вразливості немає». І практична добавка: контрзахід можна випадково прибрати наступним релізом, тому підтверджений захист варто закріпити регресійним тестом.

Що таке ризик безпеки і чому без нього перелік перевірок нічого не вартий?

Власної аксіоматики під безпеку в ISTQB немає: там — це різновид якості, а самі вразливості безпеки Foundation-силабус наводить як приклад продуктових ризиків. Отже, діє звична рамка ризик-орієнтованого тестування: ризик — це вплив і ймовірність разом. Без другого множника виходить перелік побоювань, у якому «теоретично можна брутфорсити» стоїть поруч із «будь-хто читає чужі рахунки». Канон вʼяже це в ланцюг: цілі безпекового тестування виводять із ризиків, а самі ризики дає оцінка, яка відповідає на два питання — які активи під загрозою і якої величини кожен ризик. Звідси робочий фільтр: якщо перевірку не вдається привʼязати до конкретного названого ризику, у плані їй не місце; це рятує від сценарію «прогнали сканер і здали звіт». Ризик ще й контекстний — той самий дефект у внутрішній адмінці й у публічному кабінеті коштує різного. І оцінка старіє: вона фіксує стан на момент часу, тож її повторюють, а результат вертають у тест-план.

Ризик знайшли. Які є варіанти дій, крім «полагодити»?

Чотири, і тестування покриває лише частину з них. RFC 4949 перелічує уникнення (прибрати саму функцію або дані), передачу (страхування, винесення обробки до провайдера, який бере відповідальність), обмеження контролями (тут живе більшість наших перевірок) і прийняття (свідомо жити з ризиком). Прийняття — легітимна відповідь, якщо вона ухвалена явно й записана, а не «якось забули». Мета керування ризиком, як її формулює канон, — звести ризик до прийнятного рівня, а не до нуля. Для QA це знімає типовий конфлікт: якщо бізнес ризик прийняв, робота тестувальника не воювати, а зафіксувати рішення і його межі, щоб через рік ніхто не питав «чому це не покрито». Практична добавка: прийнятий ризик усе одно лишається в переліку — інциденти люблять траплятися саме там.

У глосарії ISTQB слово `attack` означає не дію зловмисника. У чому пастка?

ISTQB тримає два різні записи. attack у нього — це тестовий підхід, спосіб шукати дефекти цілеспрямованими спробами зламати поведінку. А дія зловмисника носить окрему назву — security attack. Тому фраза «ми застосували attack-based підхід» у рамці ISTQB означає методику тест-дизайну, а не імітацію нападу. Плутанина коштує реального непорозуміння в документах: одні читають «атаки» як перелік загроз, інші — як опис підходу до тестування. Правило просте: у безпековому сенсі пишіть security attack повністю, а коли говорите про техніку, уточнюйте, що це підхід. На співбесіді така точність зчитується миттєво — кандидат, який знає про роздвоєння терміна, читав канон, а не переказ.

Чим активна атака відрізняється від пасивної і що це змінює для перевірок?

Активна змінює ресурси системи, пасивна — ні: вона лише спостерігає. Класика пасивної — перехоплення трафіку й зчитування даних, що йдуть відкритим каналом. Наслідок для тестування неприємний: критерій «дані на місці, записи не змінилися» пасивну атаку не виявляє в принципі, бо їй нічого міняти й не треба. Тому перевірки під цю пару різні. Під активну шукають слід: змінений запис, зайвий обʼєкт, в аудиті. Під пасивну дивляться на канал і на те, що взагалі виїжджає назовні: незашифроване зʼєднання, , чутливе поле в URL, токен у логах, зайві дані у відповіді API. У тест-плані це два різні класи очікуваного результату, і сплутати їх легко — команда пише «атаку не виявлено», маючи на увазі лише відсутність змін.

Що таке abuse case і як довести його до автотеста?

— це сценарій використання, у якому діє зі злим наміром; з боку функції те саме описують як спосіб скористатися нею так, як розробник не передбачав. Статус техніки варто знати чесно: шпаргалка OWASP, що її описує, позначена як історична і сама зізнається, що в реальній практиці вона трапляється рідко. Цінність не в церемонії, а в напрямі думки: «зробіть безпечно» — це не вимога, треба назвати конкретні атаки, від яких застосунок мусить захищатися в його бізнесовому й технічному контексті. Далі головне для QA: відібраний сценарій має стати безпековою вимогою або , інакше його ніхто не оцінить і не реалізує. Кожному дають унікальний ідентифікатор, щоб трасувати шлях від вимоги до тесту. Фільтр придатності підказує : вимогу мають уміти перевірити, і сама перевірка мусить давати однозначний вердикт — pass або fail. Автотест тут виконує другу роль — на контрзахід: він щодня підтверджує, що захист на місці й ніхто не зніс його рефакторингом.

Що таке OWASP Top 10 і як ним користуватися на проєкті?

Це документ для обізнаності (standard awareness document), який фіксує широкий консенсус індустрії щодо найкритичніших ризиків вебзастосунків, — тобто атлас того, що ламається найчастіше, а не готовий перелік перевірок. Слабка відповідь на співбесіді — переказати десятку напамʼять; сильна — пояснити, що з нею робити. Кожен пункт це не дефект, а кошик класів слабкостей, зібраних навколо спільної першопричини, а не спільного симптому. Саме тому фраза «перевірити A05» позбавлена змісту: щоб отримати конкретний тест, спускаються всередину категорії до конкретного . Робочий спосіб застосування такий: узяти категорію, відібрати з неї класи, які взагалі можливі у вашому стеку, і перетворити кожен на перевірку з очікуваним результатом. І варто знати межу джерел: карту ризиків беруть з OWASP, а термінологію — з ISTQB, бо не згадує OWASP жодного разу: з каталогів там названі , CWE, CWSS і CAPEC.

Що змінилося в чинній редакції OWASP Top 10 порівняно з 2021 роком?

Чинна редакція — 2025 року, восьма за ліком. Перше місце не змінилося: (A01 Broken Access Control) лишається ризиком номер один, і саме в цю категорію влито , яка раніше мала окрему позицію. (A02 Security Misconfiguration) піднялася з пʼятого місця на друге. Третя позиція, A03 Software Supply Chain Failures, — це розширення колишньої категорії про вразливі й застарілі компоненти на весь ланцюг постачання. Далі йдуть , інʼєкції, , , , та . Головний практичний висновок: номери між редакціями наосліп не порівнюються — «у нас багато A06» у звітах 2021 і 2025 років означає різні речі. Це ж стосується старих чеклистів і шаблонів баг-репортів, у яких категорія зашита рядком.

Чому «ми пройшли OWASP Top 10» не дорівнює «безпеку перевірено»?

Через те, як список збирають, і через те, що всередині кожного пункту. Ранжування спирається на дані, але не віддане їм повністю: більшість категорій підняті статистикою по мільйонах застосунків, ще дві — опитуванням спільноти, бо цифр під них бракує. Обмеження записане в самому документі: дані здебільшого відображають те, що індустрія вміє перевіряти автоматизовано, тож ризики, які автоматика не бере, недопредставлені за побудовою — не тому, що їх мало, а тому, що їх нікому порахувати. Друга частина відповіді — масштаб: у цій редакції проаналізовано 589 класів слабкостей, а десять категорій разом покривають 248 із них. Тобто «пройшли десятку» означає «зачепили десять кошиків», а не «закрили 248 класів». І третє: документ призначений підвищувати обізнаність, а не сертифікувати; коли потрібне саме з вердиктом, беруть перевірний стандарт на кшталт ASVS.

Розкладіть по полицях CVE, CWE, CVSS, CWSS і CAPEC.

CWE — каталог класів слабкостей: типових помилок, які можуть стати вразливостями; ця модальність і є межею, бо вразливість — та слабкість, яку вже можна задіяти. CVE — навпаки, конкретика: запис про публічно розкриту вразливість у конкретному випущеному продукті. Шкали йдуть симетрично: оцінює вразливості, CWSS — слабкості. CAPEC стоїть поруч, але це вже каталог патернів атак, тобто способів, а не місць. Приклад для наочності: CWE-89 (інʼєкція в SQL-команду) — це рецепт помилки, а CVE-2021-44228, вона ж Log4Shell, — конкретна діра в конкретній бібліотеці. Різниця між класом і записом пояснює й повсякденну картину: дає сотні збігів на класи, а вразливостей серед них одиниці. Є ще — річний зріз найнебезпечніших класів за статистикою; випуск 2024 року спирається на датасет із 31 770 записів CVE. У посиланні на нього обовʼязково ставлять рік випуску, а користуватися цим переліком як чеклистом не варто.

У бюлетені CVSS 9.8. Ваші дії?

Перше — не хапатися за пожежну сокиру. 9.8 це Base-бал: серйозність за характеристиками, постійними в часі, порахована без нашого середовища й із дефолтами найгіршого сценарію. Публічні бази публікують саме його: NVD збагачує оцінкою всі записи CVE, але Threat, Environmental і Supplemental за вас не рахує — натомість дає калькулятор. Тому наступний крок — перерахувати Environmental під наш контекст: чи компонент узагалі є в збірці, чи досяжний вразливий шлях коду, чи дивиться сервіс в інтернет, які дані за ним стоять. Третє — головна теза: CVSS не є мірою ризику, це лише фактор пріоритизації; ризик додасть ймовірність і вплив саме на наш бізнес. Окрема пастка, яку варто згадати вголос: 10.0 інколи означає не «кінець світу», а «деталей немає» — вендор оголосив вразливість без подробиць, і бал виставлено за найгіршим припущенням. Практичний внесок QA тут не в тому, щоб зупинити реліз через цифру, а в тому, щоб принести відповідь на питання «чи це нас узагалі стосується».

Скільки груп метрик у CVSS 4.0 і що з них реально є в публічних базах?

Чотири: Base, Threat, Environmental і Supplemental. У версіях 2.0 і 3.x груп було три, тож слово Temporal у чужому звіті — ознака старої версії, а не помилка автора. Base описує властивості, незмінні в часі, і дає число в діапазоні 0.0–10.0, якому відповідають словесні рівні: None — рівно 0.0; Low — 0.1–3.9; Medium — 4.0–6.9; High — 7.0–8.9; Critical — від 9.0. Environmental — це перерахунок під конкретне середовище, і зробити його, крім вас, нікому. Supplemental несе додаткові характеристики, але на сам бал не впливає. У публічних базах ви, як правило, бачите лише Base — це і є та цифра з бюлетеня. І нюанс, на якому ловить буквальне читання короткого означення ISTQB: специфікація виставляє метрики з припущення, що знає про вразливість усе, тож аргумент «її ще треба зуміти знайти» на оцінку не впливає ніяк.

У категорії мало повʼязаних CVE. Це означає, що з нею все гаразд?

Ні, часто якраз навпаки. Найпоказовіший приклад чинної редакції: з класами слабкостей категорії про ланцюг постачання повʼязано лише 11 записів CVE, а середня частота спрацювання, коли її таки перевіряли, виявилася найвищою в десятці — 5,19 %. Дзеркальний приклад — категорія про логування й сповіщення: документ прямо називає її вкрай складною для тестування, і записів там теж негусто, 723. Пояснення просте: кількість CVE показує, скільки разів проблему змогли знайти, описати й опублікувати, а не скільки її насправді в продуктах. Мала цифра говорить радше про межі інструментів, ніж про стан застосунку. Практичний висновок для QA подвійний: «сканер нічого не знайшов» доказом не є, а категорії, де автоматика безсила, лишаються за ручним тестуванням, рев'ю й перевіркою дизайну.

Коли підключати безпеку в проєкті й до чого тут shift left?

Не в кінці — Advanced-силабус з безпеки формулює це без напівтонів: у вже збудований продукт безпеку не дотестовують і не допатчують, вона виникає з орієнтованого на безпеку дизайну й перевірок протягом усієї побудови. При цьому безпекові активності не утворюють власного циклу: вони йдуть паралельно зі звичайними роботами проєкту, у будь-якій моделі розробки. Щоб це не лишилося декларацією, цикл має дати їм чотири речі — визначений момент виконання, чекпойнти рев'ю, чекпойнти тестування, а також і виходу. Зі все зшивається через : безпека нефункціональна, а нефункціональне тестування Foundation радить починати рано, бо пізно знайдений такий дефект серйозно загрожує проєкту; виконання його вже з рівня компонентних тестів канон прямо називає формою shift left. Найдальша ліва точка — статика: статичний аналіз дає оцінку й за безпекою, і частину вразливостей там ловлять дешевше, ніж у запущеній системі. Побічний аргумент, що знімає відмовки: у Foundation безпека взагалі не входить у чотири типи тестування — вона стоїть серед характеристик якості ISO/IEC 25010, тож «це не наш тип тестування» не працює.

Ви QA чи пентестер? Де ваша межа?

Розділяє тут не набір інструментів, а наявність погодження. Канон означує як тестувальника безпеки, який дотримується кодексу етики своєї організації, — про техніку там немає жодного слова. Той самий крок, обійти авторизацію на стенді, з погодженням команди є роботою тестувальника, без погодження робить вас attacker за означенням. Друга частина мандату — поводження з результатами: звіти самі є чутливими, тож розходяться лише тим, кому потрібні для роботи. Корисно розвести й сусідні поняття: пентест канон уважає підтипом динамічного , який імітує атакувальника, не завдаючи шкоди; red teaming навмисно домагається шкідливого результату; аудит безпеки дивиться на процеси й інфраструктуру організації, а не шукає діри в компоненті; сканування вразливостей канон відносить до статичного аналізу. Варто згадати й операційне застереження, яке стоїть поруч із означенням, а не замість нього: «без шкоди» описує метод і мандат, а дока і Burp попереджає про ризик конкретної процедури — активного сканування їхнім інструментом, де реальна шкода даним чи функціональності можлива; звідси й вимоги авторизації власника цілі, резервної копії та прийнятого ризику. І окремо: вимагати пентесту «за ISTQB Foundation» не випадає — у тому силабусі термін не трапляється жодного разу.

Як ви придумаєте безпекові перевірки для нової фічі?

Іду не від переліку модних атак, а від активів і ризику. Крок перший — назвати, що ця фіча захищає: які дані, чиї гроші, яка дія незворотна. Крок другий — хто або що може це порушити, і сюди йдуть не лише зловмисники, а й випадкові події та цілком авторизовані користувачі. Крок третій — сценарії зловживання: як скористатися функцією так, як розробник не задумував; найдорожчий клас тут — зловживання бізнес-логікою, де помилки в коді немає взагалі, наприклад перебір акаунтів через різні відповіді потоку . Крок четвертий — перевести відібрані сценарії в критерії приймання з унікальними ідентифікаторами й перевірним вердиктом pass або fail, інакше вони лишаться розмовою на грумінгу. Крок пʼятий — вирішити, що автоматизувати як регресію на контрзахід, а що робити руками або на рев'ю дизайну. І рамки: те, що не привʼязується до конкретного ризику, у план перевірок не потрапляє, а результат оцінки повертається назад у план, бо оцінка старіє.

Що з безпеки видно у браузері, поки ви ще нічого не встановили?

Досить багато — і це чесна відповідь на питання «з чого почнете на новому проєкті». У Chrome DevTools є : вона служить, щоб інспектувати сторонні cookie й перевіряти захист зʼєднання; відкривається з Command menu — почати друкувати privacy і вибрати показ панелі. Якщо основне не захищене, огляд прямо каже, що сторінка небезпечна, і називає причину: її запитано по HTTP. Окремий діагноз — змішаний контент (mixed content): головний документ приїхав по HTTPS, а частина ресурсів тягнеться відкритим каналом; така сторінка захищена лише частково, бо HTTP-частину видно сніферам і вона вразлива до атаки «людина посередині». З вердикту можна одразу провалитися в конкретику: у секції з незахищеними походженнями є перехід до відповідних запитів у панелі Network, а поряд — перегляд сертифіката походження. Це нульовий крок, який не потребує ані дозволу на активні дії, ані окремого стенду, — і саме тому з нього зручно починати.

Три ситуації, у яких словник із цієї глави перетворюється на роботу: випадкової знахідки до баг-репорта, який приймуть; сценарій зловживання, доведений до й регресійного тесту; і бюлетень із високим балом , який прилетів у понеділок уранці. Скрізь — що робити і чому саме так.

Кейс 1. «Я вставив лапку, і сторінка впала». Що з цим робити далі

Ситуація типова: на стенді в параметрі сортування підставили апостроф і отримали 500 зі стектрейсом просто в тілі відповіді.

GET /api/orders?sort=name' HTTP/1.1

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error":"SQLSTATE[42000]: Syntax error near \"'\" in /srv/app/Repo/OrderRepo.php:118"}

Спокуса — написати «знайшов SQL-інʼєкцію, критично». Це слабкий баг-репорт: у ньому немає ані осі, ані , ані класу слабкості, тож пріоритет йому проставлять навмання. Перед тим як заводити дефект, проженіть знахідку через шість питань.

Питання тріажу	Навіщо воно	Приклад відповіді
Чи був мандат на такі проби саме тут?	Той самий крок із погодженням — робота, без нього — дія атакувальника	Стенд, активні перевірки узгоджені з командою
Яка з трьох цілей просіла?	Вісь пояснює бізнесу ціну знахідки	Конфіденційність: назовні поїхали шлях до файлу, рядок і рушій БД
Це симптом чи першопричина?	Категорія OWASP — кошик, тест росте з конкретного класу	Симптом — розкриття даних у помилці; першопричину ще треба довести
Чи вдалося дійти до даних?	«Не спрацювало» не дорівнює «немає слабкості»	Ні: другий і третій вектори віддали `400`, вибірку відтворити не вдалося
Хто дістає цей ендпоінт?	Ймовірність — половина ризику	Анонім без токена — отже, ймовірність висока
Як звучить вердикт pass/fail?	Вимога без перевірного критерію не закривається	«Сервер відповідає `400`, тіло не містить стектрейсу, шляху й назви рушія»

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

БУЛО
Заголовок: SQL injection в /api/orders
Опис: підставив лапку, сайт впав. Критично!

СТАЛО
Заголовок: /api/orders віддає 500 зі стектрейсом і деталями БД на некоректний параметр sort

Вісь: конфіденційність (розкриття внутрішньої інформації); потенційно цілісність,
якщо параметр справді доходить до запиту неекранованим.
Ймовірність: ендпоінт доступний без автентифікації.
Кроки: GET /api/orders?sort=name'
Фактично: 500, у тілі — рушій БД, файл і рядок коду.
Очікувано: 400 з нейтральним текстом; стектрейс лише в серверних логах.
Не підтверджено: вибірку даних відтворити не вдалося двома іншими векторами —
це не знімає слабкість, а фіксує межу перевірки.

Що дивитися і чому:

Стектрейс у відповіді — самостійний дефект. Навіть якщо немає, назовні поїхали рушій БД, структура проєкту й номер рядка: дістав карту, не витративши жодної спроби. Фіксуйте це окремо від питання «чи можна дістати дані».
500 на кривому вводі — сигнал пропущеної валідації. Коректна поведінка — свідома 4xx, а не необроблений виняток; це та частина, яку тест закриє одразу й дешево.
«Не відтворив» пишіть як межу, а не як вердикт. Успіх спроби залежить і від контрзаходів на шляху; формулювання «цим вектором не вдалося» лишає місце для перевірки іншим шляхом і не дає команді закрити тікет фразою «у нас же фільтр стоїть».
Категорію ставте після класу, не замість нього. Спершу — що саме зламано (розкриття даних у повідомленні про помилку), і лише потім, за потреби для звітності, — у який кошик Top 10 воно лягає.

Кейс 2. Abuse case для промокодів: від сценарію до регресії

Фіча звичайна: одноразовий промокод на першу покупку. Дефектів у коді може не бути взагалі — і саме тут живе найдорожчий клас знахідок, зловживання бізнес-логікою. Розписуємо сценарії зловживання відразу у форматі, придатному для приймання: унікальний ID, сценарій, перевірний результат.

ID	Сценарій зловживання	Критерій приймання (pass/fail)
ABUSE-PROMO-01	Той самий код застосовують двічі паралельно з двох вкладок	Успішна відповідь рівно одна, у кошику одна знижка
ABUSE-PROMO-02	Код «для нових клієнтів» застосовує акаунт з історією замовлень	Відмова; текст відповіді не підказує, чому саме відмовлено
ABUSE-PROMO-03	Перебір кодів словником з одного акаунта	Спрацьовує рейт-ліміт; відповіді на вигаданий і на чужий код однакові
ABUSE-PROMO-04	Знижку застосовують, потім міняють кошик на дорожчий товар	Знижка перераховується від фінальної суми, а не від початкової

Чотири рядки цієї таблиці — уже не нотатки в блокноті, а вимоги: кожна перевірна й закінчується вердиктом. Два з них варто мати автотестами — не заради пошуку нових дір, а як на контрзахід: щоб чи блокування повторного застосування не зникли тихо під час чергового рефакторингу.

import { test, expect } from '@playwright/test';

// ABUSE-PROMO-01: інваріант — знижка нараховується рівно один раз
test('ABUSE-PROMO-01: одноразовий код не спрацьовує двічі паралельно', async ({ request }) => {
  const apply = () => request.post('/api/cart/promo', { data: { code: 'WELCOME10' } });

  const [first, second] = await Promise.all([apply(), apply()]);
  const ok = [first, second].filter((r) => r.ok());
  expect(ok, 'гонка двох запитів пройшла обидва рази').toHaveLength(1);

  const cart = await (await request.get('/api/cart')).json();
  expect(cart.appliedDiscounts).toHaveLength(1);
});

// ABUSE-PROMO-03: перебір упирається в ліміт, а відповіді не розрізняють коди
test('ABUSE-PROMO-03: словниковий перебір промокодів обмежено', async ({ request }) => {
  const messages = new Set<string>();
  let throttled = false;

  for (let i = 0; i < 25; i += 1) {
    const res = await request.post('/api/cart/promo', { data: { code: `GUESS-${i}` } });
    if (res.status() === 429) {
      throttled = true;
      break;
    }
    messages.add((await res.json()).message);
  }

  expect(throttled, 'рейт-ліміт не спрацював — контрзахід прибрали').toBeTruthy();
  expect(messages.size, 'текст помилки видає, який код існує').toBe(1);
});

Що дивитися і чому:

ID у назві тесту — не прикраса. Він звʼязує критерій приймання, тест і дефект: коли тест червоніє, зрозуміло, яка саме вимога порушена, а не «щось із промокодами».
Тест фіксує інваріант, а не техніку. У першому сценарії перевіряється не «як реалізовано блокування», а факт: успішних застосувань рівно одне. Реалізацію можна переписати, інваріант лишається.
Однаковий текст помилки — теж вимога. Різні відповіді на «коду не існує» і «код не для вас» перетворюють форму на : перебором вивідують валідні коди, не ламаючи нічого.
Автотест не замінює аналіз. Він стереже вже названі сценарії; нові беруться з розмови про активи й ризики, а не з прогону старої .

Кейс 3. Прилетів бюлетень: CVSS 9.8. Що робить QA до того, як зупиняти реліз

Уранці в чат падає повідомлення: у бібліотеці, яка є в наших залежностях, опубліковано з базовим балом 9.8. Найгірша реакція — паніка й зупинка релізу, друга найгірша — «у нас цього немає, забийте» без перевірки. Розберіть бал на те, що він каже, і те, чого не каже.

Бал каже	Бал не каже
Серйозність за характеристиками, постійними в часі (це група Base)	Наскільки це небезпечно у вашому середовищі
Порахований з дефолтами найгіршого сценарію	Чи досяжний вразливий код у вашій конфігурації
Опублікований у базі як CVSS-B: Threat, Environmental і Supplemental там не рахують	Який пріоритет ставити у вашому беклозі
Виставлений з припущення, що атакувальник знає про вразливість усе	Наскільки її складно знайти в реальному застосунку

Порядок дій, який перетворює цифру на рішення:

Перевірити наявність, а не назву. Бібліотека може бути транзитивною залежністю або взагалі не входити у прод-збірку; питання «яка версія реально їде в контейнер» вирішує половину тривоги.
Перевірити досяжність. Уразливим буває конкретний режим чи функція: якщо ми не викликаємо цей код і не вмикаємо цю опцію, вплив інший.
Перерахувати Environmental. Саме цю групу публічні бази за вас не рахують — вони дають лише Base і калькулятор: сервіс усередині периметра з й публічний кабінет із платіжками дадуть різні числа з того самого Base.
Перекласти в ризик. CVSS — фактор пріоритизації, а не міра ризику; рішення народжується, коли до серйозності додали ймовірність і вплив на конкретний бізнес.
Записати рішення. Оновлюємо, обмежуємо контролем чи свідомо приймаємо — будь-який із варіантів має бути явним і датованим, бо оцінка старіє й до неї повернуться.

Що дивитися і чому:

Бал 10.0 подеколи читається як «подробиць не дали». Вендор оголосив , не розкривши деталей, — і оцінку виставили за найгіршим припущенням. Читати таку оцінку як «підтверджено найстрашніше» — помилка.
Слово Temporal у чужому звіті — маркер версії. У CVSS 4.0 груп чотири: Base, Threat, Environmental і Supplemental; побачили Temporal — перед вами оцінка за 2.0 або 3.x, і порівнювати числа наосліп не варто.
Supplemental на бал не впливає. Це додаткова характеристика для контексту, а не спосіб «підняти» чи «збити» оцінку.
Кількість CVE у звіті — не рейтинг безпеки. Категорія з десятком записів може мати найвищу частоту спрацювання, коли її нарешті перевіряють; порожньо там, куди не дістає автоматика.

Три цілі й базовий словник

Знаю три (конфіденційність, цілісність, доступність) і кладу будь-яку знахідку в одну з осей — саме вісь пояснює бізнесу ціну; памʼятаю, що FIPS відносить доступ до конфіденційності, а ISTQB — до цілісності, тому називаю словник, у рамці якого класифікую.
Розрізняю (стан), (можливість), security attack (дію) і (шлях) і памʼятаю, що загроза буває випадковою: збій, помилка людини й авторизований інсайдер підпадають під означення нарівні з нападом.
Знаю пастку : attack там означає тестовий підхід, а дію зловмисника носить окремий запис security attack.
Можу заперечити тезі «пейлоад не спрацював — вразливості немає»: успіх залежить ще від сили спроби й дієвості контрзаходів.

Ризик і пріоритет

Можу пояснити як вплив разом із ймовірністю і чому без другого множника виходить перелік побоювань, який нічим не пріоритезувати; памʼятаю й те, що оцінка фіксує стан на момент часу, тож її повторюють, а результат вертають у тест-план.
Знаю чотири можливі відповіді на ризик — уникнути, передати, обмежити контролями або прийняти — і те, що прийняття легітимне, коли ухвалене явно; мета — прийнятний рівень, а не нуль.

Від ризику до перевірки

Можу пояснити, що таке , і чесно назвати статус техніки: описана, але в реальній практиці вживається рідко.
Знаю правило, без якого сценарій зловживання нічого не змінює: він мусить стати вимогою або з унікальним ідентифікатором і вердиктом pass/fail.
Розумію другу роль автотеста в безпеці — на контрзахід, щоб захист не зник разом із рефакторингом.

OWASP Top 10 як карта

Розумію, що це документ для обізнаності, а категорія — кошик класів слабкостей за першопричиною, тож перевірка починається зі спуску до конкретного .
Знаю чинну редакцію 2025 року й ключові зсуви (контроль доступу лишився першим, влито в нього, конфігурація піднялася на друге) і не порівнюю номери категорій між редакціями наосліп.
Можу пояснити обмеження даних: список зміщений у бік того, що індустрія вміє перевіряти автоматизовано, тож «пройшли десятку» не дорівнює «перевірили безпеку».

Каталоги і шкали

Не плутаю CWE (класи слабкостей, які ще тільки можуть стати вразливостями) з (запис про розкриту вразливість у конкретному продукті) і памʼятаю сусідів — CWSS для слабкостей і CAPEC для патернів атак.
Можу пояснити, чому кількість CVE не є метрикою безпеки й чому мале число записів говорить радше про межі інструментів.
Знаю чотири групи метрик 4.0 (Base, Threat, Environmental, Supplemental), діапазон 0.0–10.0 і що публічні бази дають, як правило, лише Base.
Памʼятаю, що CVSS не є мірою ризику, а лише фактором пріоритизації, і що 10.0 інколи означає відсутність деталей від вендора.

Роль QA, цикл і мандат

Можу заперечити «це не наш тип тестування»: безпека належить до нефункціональних за ISO/IEC 25010 і в чотири типи тестування Foundation не входить.
Знаю тезу про те, що в готовий продукт безпеку не допатчують, і чотири речі, які цикл має дати безпековим активностям: момент виконання, чекпойнти рев'ю, чекпойнти тестування, й виходу.
Розумію, що shift left тут означає конкретне: нефункціональне тестування з рівня компонента, а найраніша точка — .
Памʼятаю, що тестувальника від відрізняє погодження, а не інструмент, і що знахідки розходяться лише тим, кому потрібні для роботи.

Знайшли помилку?

Безпека очима QA: модель загроз і OWASP Top 10

Три цілі: конфіденційність, цілісність, доступність

Чотири слова, які плутають щодня

Ризик: те, що перетворює перелік на пріоритет

Мислення атакувальника: use case проти abuse case

OWASP Top 10 як карта ризиків

CVE, CWE і CVSS: три різні речі

Роль QA: безпека живе в циклі, а не в кінці

Пентест і мандат: роль визначає не інструмент

Що вже видно у браузері

Типові помилки

Підсумок

Можливі питання

Джерела

Назвіть три цілі безпеки. Навіщо вони тестувальнику?

Чим відрізняються вразливість, загроза, атака й вектор атаки?

Чи буває загроза без зловмисника?

«Пейлоад не спрацював — значить, вразливості немає». Погоджуєтесь?

Що таке ризик безпеки і чому без нього перелік перевірок нічого не вартий?

Ризик знайшли. Які є варіанти дій, крім «полагодити»?

У глосарії ISTQB слово attack означає не дію зловмисника. У чому пастка?

Чим активна атака відрізняється від пасивної і що це змінює для перевірок?

Що таке abuse case і як довести його до автотеста?

Що таке OWASP Top 10 і як ним користуватися на проєкті?

Що змінилося в чинній редакції OWASP Top 10 порівняно з 2021 роком?

Чому «ми пройшли OWASP Top 10» не дорівнює «безпеку перевірено»?

Розкладіть по полицях CVE, CWE, CVSS, CWSS і CAPEC.

У бюлетені CVSS 9.8. Ваші дії?

Скільки груп метрик у CVSS 4.0 і що з них реально є в публічних базах?

У категорії мало повʼязаних CVE. Це означає, що з нею все гаразд?

Коли підключати безпеку в проєкті й до чого тут shift left?

Ви QA чи пентестер? Де ваша межа?

Як ви придумаєте безпекові перевірки для нової фічі?

Що з безпеки видно у браузері, поки ви ще нічого не встановили?

Кейс 1. «Я вставив лапку, і сторінка впала». Що з цим робити далі

Кейс 2. Abuse case для промокодів: від сценарію до регресії

Кейс 3. Прилетів бюлетень: CVSS 9.8. Що робить QA до того, як зупиняти реліз

Три цілі й базовий словник

Ризик і пріоритет

Від ризику до перевірки

OWASP Top 10 як карта

Каталоги і шкали

Роль QA, цикл і мандат

У глосарії ISTQB слово `attack` означає не дію зловмисника. У чому пастка?