«Аналіз вразливостей» і «пентест» вживають як синоніми — і дарма. Це різні за глибиною, метою й ціною послуги. Плутанина коштує грошей: за скан платять як за глибоку перевірку або, навпаки, чекають від скана того, чого він дати не може. Розберемося по суті — від того, як влаштований сканер, до того, як звести все знайдене в керований процес.
Що таке аналіз (оцінка) вразливостей
Аналіз вразливостей (vulnerability assessment) — виявлення й ранжування відомих слабких місць у системах, переважно автоматичними засобами. Сканер вразливостей звіряє ваші системи з базою відомих проблем і видає перелік: що знайдено, наскільки серйозно, як виправити.
Це швидко, відносно недорого й чудово підходить для регулярного контролю: запускати часто, тримати руку на пульсі.
Як влаштований сканер — і звідки беруться його вади
Механіка проста: інструмент визначає, які служби працюють, які версії компонентів установлені, які відповіді повертає сервер, — і зіставляє це з базою відомих дефектів. Звідси обидві його слабкості.
Хибні спрацювання. Сканер бачить стару версію пакета й позначає її дірявою. А супровідник дистрибутива вже переніс виправлення у стару гілку, не змінюючи номера версії. Дефекту немає, тривога є — і хтось витрачає день, аби це довести.
Хибні пропуски. Чого немає в базі, того для інструмента не існує: свіжий дефект, саморобний модуль, помилка у вашій власній бізнес-логіці. Тому чистий звіт означає лише «нічого відомого», а не «нічого немає».
Сканування з обліковим записом і без нього
Різниця, про яку зазвичай мовчать. Без облікового запису інструмент бачить систему ззовні — приблизно як перехожий бачить будинок: вікна, двері, вивіску. З обліковим записом (аутентифіковане сканування) він читає реальний перелік установлених пакетів і їхні версії.
Покриття відрізняється в рази. Якщо у звіті немає жодної згадки про облікові дані, вам показали фасад.
Аналіз вразливостей проти пентесту
| Критерій | Сканування | Пентест |
|---|---|---|
| Метод | переважно автоматичний | ручний плюс автоматичний |
| Що знаходить | відомі типові дефекти | зокрема логічні хиби й ланцюжки атак |
| Перевіряє експлуатованість | ні, лише виявляє | так, підтверджує реальність |
| Глибина | широко, але поверхово | вужче, зате до дна |
| Ціна | нижча | вища |
| Частота | регулярно | періодично |
Простими словами: інструмент каже «тут може бути проблема», а фахівець перевіряє, чи можна нею скористатися й куди це веде. Тому дешева послуга, яка виявляється звичайним скануванням, — тривожний сигнал (див. з чого складається ціна перевірки). Як влаштована глибока перевірка — в оглядовій статті Пентест: що це і як проходить.
CVE, CVSS, EPSS і KEV: мова пріоритетів
Щоб ранжувати знайдене, галузь користується кількома різними шкалами. Плутати їх — дорога помилка.
| Позначення | Що означає | Питання, на яке відповідає |
|---|---|---|
| CVE | унікальний ідентифікатор конкретного дефекту | «про що саме йдеться?» |
| CVSS | технічна тяжкість за шкалою від 0 до 10 | «наскільки болісно буде, якщо цим скористаються?» |
| EPSS | імовірність експлуатації протягом найближчих 30 днів (модель FIRST, оновлюється щодня) | «наскільки ймовірно, що цим скористаються?» |
| KEV | перелік CISA із підтвердженими випадками експлуатації | «цим уже користуються просто зараз?» |
Ключова думка: CVSS — не ризик. Дефект із балом 9,8, який ніхто ніколи не експлуатував, менш терміновий за «середній» бал 6,5, що вже працює в кампаніях вимагачів. Сортування черги виправлень за самим лише CVSS — найпоширеніша причина того, чому команди роками латають гучне й пропускають небезпечне.
Європейський орієнтир теж є: з травня 2025 року ENISA веде EUVD — базу вразливостей ЄС зі статусом експлуатації.
Чому «критичних» завжди сотні
Бо сканер оцінює дефект сам собою, поза вашим контекстом. Одна й та сама діра в сервері, відкритому з інтернету, і в стенді, вимкненому по п'ятницях, отримає той самий бал.
Контекст, який перетворює перелік на план:
- доступність — до системи дотягується будь-хто чи лише свої?
- експлуатованість — є публічний код атаки, чи проблема лишається теоретичною?
- цінність активу — там платежі й персональні дані чи внутрішня вікі?
- компенсаційні заходи — можливо, шлях уже перекрито іншим засобом захисту.
Чотири питання зазвичай скорочують «сотні критичних» до кількох десятків, із якими справді треба щось робити.
Управління вразливостями: процес, а не подія
Знайти — половина справи. Найпоширеніша помилка — вважати, ніби управління вразливостями виконує сканер. Інструмент лише постачає вхідні дані; сам процес живе в тікетах, строках і людях.
Управління вразливостями (vulnerability management) — безперервний цикл:
- Виявлення — регулярне сканування з покриттям усіх систем, а не лише зручних.
- Ранжування — за контекстом і трьома сигналами вище, а не за одним балом.
- Призначення власника — у кожної знахідки має бути прізвище, інакше її не виправить ніхто.
- Усунення — оновлення, зміна конфігурації, компенсаційний захід.
- Контроль — перевірити, що діру справді закрито, а не просто закрито тікет.
- Повторення — процес живе доти, доки живе інфраструктура.
Дві метрики, які варто рахувати з першого дня: середній час від виявлення до усунення й частка систем, охоплених скануванням. Перша показує швидкість, друга — чесність.
Саме такий підхід закладено в стандарти: керування технічними вразливостями — контроль ISO 27001, а керовану систему навколо описує СУІБ.
Коли достатньо сканування, а коли потрібен фахівець
- Достатньо сканування: регулярний контроль стану, швидка звірка після оновлень, пошук відомих дефектів.
- Потрібен пентест: перевірка бізнес-логіки, підтвердження реального ризику, вимоги партнерів чи стандартів, тест перед запуском важливого сервісу (див. коли він потрібен, а коли зарано).
Найкраще вони працюють разом: часте сканування тримає базову гігієну, періодична глибока перевірка мережі чи застосунків показує те, чого жоден інструмент не побачить.
Хочете вибудувати процес, а не разові запуски сканера? Фахівці допоможуть налаштувати покриття, ранжування й контроль усунення — отримати консультацію.