Не «чи знайдуть», а «коли ви закриєте»

Навесні 2026 року розмова про кібербезпеку знову стала гучною. 7 квітня Anthropic оголосила Project Glasswing і написала, що її модель Claude Mythos Preview вже знайшла «thousands of high-severity vulnerabilities», зокрема в кожній великій операційній системі та браузері. Загального доступу до моделі компанія не планує. Це заява вендора, а не незалежна оцінка, і читати її варто саме так.

Незалежніша картина від британського AI Security Institute (AISI). У своїй оцінці від 13 квітня інститут пише, що модель першою пройшла 32-кроковий полігон «The Last Ones», який імітує атаку на корпоративну мережу, від початку до кінця, але лише в трьох спробах із десяти. Тут же застереження самого AISI: на полігоні немає активних захисників і захисних засобів, тому про добре захищені системи висновків робити не можна.

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

Без паніки: що кажуть дані

Тон «ШІ зламає все» дані не підтверджують. У звіті M-Trends 2026 від Mandiant (Google) прямо сказано: 2025 рік не став роком, коли витоки були прямим наслідком ШІ, а переважна більшість успішних проникнень досі пов'язана з базовими людськими й системними помилками. Звідси й тверезий висновок: основи важливіші за новинки.

Водночас сам звіт показує, чому основи треба робити швидко:

• експлойти (використання вразливостей) стали початковим вектором у 32% проникнень, перше місце шостий рік поспіль; голосовий фішинг виріс до 11%;

• середній час до експлуатації Mandiant оцінює в мінус сім днів: атаки нерідко починаються ще до виходу патча;

• передача доступу від однієї злочинної групи іншій скоротилась з понад восьми годин у 2022 році до 22 секунд у 2025.

VulnCheck у звіті State of Exploitation 2026 додає: 28,96% вразливостей, які потрапили до каталогу KEV (Known Exploited Vulnerabilities, перелік вразливостей з підтвердженою експлуатацією), у 2025 році атакували в день публікації CVE або раніше. Найчастіше ціллю були периметрові пристрої: firewall, VPN, проксі.

Скільки днів вам потрібно насправді

Тепер про те, як із цим справляються організації. За Verizon DBIR 2026, де проаналізовано дані понад 13 000 організацій, у 2025 році повністю закрито лише 26% вразливостей із каталогу CISA KEV (у попередньому році 38%). Медіана повного виправлення зросла до 43 днів проти 32. Експлуатація вразливостей у цьому звіті стала найчастішим початковим вектором проникнення.

Порівняйте ці числа з попереднім розділом. Частина атак стартує до патча, інша частина в день публікації, а медіана повного виправлення в DBIR становить 43 дні. Розрив у цьому, а не в тому, що хтось знайшов ще одну дірку.

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

П'ять кроків, які скорочують розрив

1. Пріоритет за ознакою реальної експлуатації, а не лише за CVSS. Бал CVSS (Common Vulnerability Scoring System, оцінка серйозності вразливості) показує потенційну небезпеку. Каталог KEV від CISA показує, що вразливість уже використовують. Якщо вразливість із KEV є у вас на периметрі, вона йде перед усім, навіть із середнім балом. Додайте каталог до правила пріоритезації: «є в KEV» піднімає задачу вгору автоматично.

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

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

4. Безперервне сканування периметра. Зовнішній периметр змінюється швидше, ніж ви його інвентаризуєте: нові піддомени, забуті тестові стенди, пристрої з оновленою прошивкою. Разове сканування раз на квартал показує стан на один день. Регулярне сканування вразливостей з автоматичним порівнянням «що з'явилось нового» скорочує час між появою проблеми і вашим знанням про неї. А тест на проникнення показує те, чого сканер не бачить: як окремі дрібні недоліки поєднуються в реальний шлях атаки.

5. Перевірка коду до релізу. Найдешевша вразливість та, що не потрапила в продакшн. Якщо у вас є власний код, аудит безпеки вихідного коду до релізу прибирає цілий клас проблем, які потім довелося б латати в терміновому порядку. Особливо це важливо для сервісів, відкритих в інтернет.

Як рахувати метрику «знайшли → закрили»

Метрика проста на вигляд і підступна у виконанні. Щоб їй можна було вірити, фіксуйте дати подій, а не враження. Для кожної вразливості записуйте п'ять дат:

1. Публікація: коли CVE або бюлетень вендора стали публічними.

2. Додавання до KEV: якщо вразливість там є, коли саме її туди внесли.

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

4. Застосування виправлення: патч, зміна конфігурації або вимкнення сервісу.

5. Підтверджене закриття: повторне сканування чи ручна перевірка, що вразливість зникла.

Головна метрика це час від третьої дати до п'ятої. Є й другий корисний показник: від першої дати до третьої. Це ваш «час невідомості», тобто скільки днів вразливість була публічною, поки ви про неї не знали. Його скорочують безперервне сканування і підписка на бюлетені вендорів.

Одна цифра без розкладки вводить в оману, тому тримайте три правила.

Медіана і середнє показують різне. Середнє тягнуть вгору кілька вразливостей, що висять роками, а медіана показує типову швидкість. DBIR теж користується медіаною. Рахуйте обидва і додайте вік найстарішого відкритого пункту. Саме найстаріше зазвичай і є вашим реальним ризиком.

Рахуйте не лише закриті. Якщо в метрику потрапляють тільки виправлені вразливості, найстаріші відкриті пункти зникають зі статистики, і картина виглядає краще, ніж є. Окремо тримайте віковий розподіл відкритих: до тижня, до місяця, довше.

Розділяйте групи. Окремо рахуйте вразливості з KEV, окремо все, що стоїть на периметрі, і окремо решту. Змішане число ховає саме те, що вимагає найшвидшої реакції. VulnCheck зафіксував 884 вразливості з KEV, що вперше експлуатувались у 2025 році: на тлі загального потоку CVE це невелика група, і її цілком реально закривати окремим пріоритетним процесом.

На сторінці каталогу CISA біля кожного запису є дата додавання і строк. Серед двадцяти записів, доданих туди з 16 по 30 жовтня 2026 року, строк становить три або чотирнадцять днів. Це спостереження за сторінкою, а не вимога до вас, але воно показує, що навіть у KEV терміновість неоднакова.

Як вибудувати процес

Затримка рідко виникає через те, що ніхто не вміє встановити патч. Вона виникає між людьми. Тому процес варто описати на одній сторінці, відповівши на кілька питань.

Ролі. Для кожної системи потрібні власник (відповідає за бізнес-наслідки), виконавець (оновлює) і відповідальний за безпеку (оцінює терміновість, перевіряє результат). Коли системою опікується зовнішній підрядник, строки й подвійну перевірку варто вписати в договір чи SLA (угоду про рівень сервісу).

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

Вікна обслуговування. Крім регулярного вікна, потрібне запасне, з коротким попередженням для користувачів, і правило, коли переноситься зірване вікно (збій зв'язку, електропостачання, зайнята команда). Інакше один зірваний вікенд стає тижнем відкритої вразливості.

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

Коли патча немає. Бувають вразливості, на які патч ще не вийшов (згадайте «мінус сім днів» із M-Trends), а іноді він не вийде ніколи, бо продукт знято з підтримки. Тоді потрібні компенсаційні заходи. Типові з них:

• виконати рекомендацію вендора, якщо він описав тимчасове обхідне рішення (вимкнення вразливої функції, зміна налаштування);

• закрити доступ: прибрати інтерфейс керування з інтернету, дозволити його лише з відомих адрес або через захищений вхід з багатофакторною автентифікацією;

• відокремити систему сегментацією, щоб її злам не відкривав шлях до критичних сервісів;

• стежити пильніше за журналами самого пристрою і планувати заміну, якщо продукт знято з підтримки.

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

Умовний приклад

Це вигаданий сценарій, щоб показати арифметику. Числа в ньому ілюстративні, це не статистика і не дані конкретного проєкту.

Уявімо середню компанію із зовнішнім шлюзом віддаленого доступу. У понеділок вендор публікує бюлетень про критичну вразливість шлюзу. У вівторок сканер показує, що вразливість є і у вас: це день 1 від виявлення. Адміністратор бачить задачу, але для зупинки шлюзу потрібна згода власника системи, а той у відрядженні. У п'ятницю згода є, але регулярне вікно обслуговування лише наступного вівторка. Оновлення застосовують на день 8, повторне сканування підтверджує закриття на день 9.

Метрика «знайшли → закрили» дорівнює дев'яти дням, а реальна робота зайняла менше доби. Решта це очікування. Так виглядає розрив із DBIR у малому масштабі.

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

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

• Вважати «патч встановлено» закриттям. Без повторної перевірки ви не знаєте, чи оновлення дійшло до всіх вузлів і чи вимкнено старий шлях.

• Один строк для всього. Спільна черга для внутрішнього принтера й шлюзу в інтернет означає, що шлюз чекає.

• Виняток без дати завершення. Тимчасова вимога стає постійною, і про неї ніхто не пам'ятає.

• Орієнтація лише на CVSS. Високий бал для вразливості, яку ніхто не експлуатує, і середній бал для тієї, що вже в атаках: друга має йти першою.

• Оновити і не перевірити сліди. Якщо експлуатація передувала патчу, оновлення лише закриває двері, через які вже могли зайти.

Що це означає для українських компаній

Для українського бізнесу картина має кілька особливостей. Частина команд невеликі, а ІТ-адміністрування часто віддане підряднику: тоді саме договір має містити строки, порядок термінових змін і вимогу підтвердження закриття. Для компаній, яким перебої зі зв'язком чи електропостачанням зривають планові роботи, запасне вікно обслуговування перестає бути розкішшю.

ІТ-експортери й сервісні компанії, які працюють із замовниками з ЄС, зазвичай отримують від них опитувальники з безпеки, де питають про строки виправлення і докази їх дотримання. Загальновідомо, що NIS2 і DORA вимагають від регульованих організацій управляти ризиками, зокрема вразливостями, і що ці вимоги передаються ланцюгом постачання: замовник просить того самого від вас. Фінансовий сектор і небанківські фінансові установи зазвичай також мають зовнішні вимоги й перевірки. У всіх цих випадках журнал дат із розділу про метрику перетворюється на доказ, а не лише на внутрішню статистику.

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

З чого почати цього місяця

Не з нового інструмента. Візьміть одну метрику: скільки днів проходить від виявлення вразливості до її підтвердженого закриття. Рахуйте медіану окремо для вразливостей із KEV і для решти, і додайте вік найстарішого відкритого пункту. Потім подивіться на найстаріші відкриті пункти на периметрі: зазвичай саме там ховається історія, яку сьогодні розповідають звіти.

Якщо число вас здивує, це нормально. Головне, щоб воно перестало бути невідомим. А далі це інженерна задача: власник у кожної системи, строк, повторна перевірка.

Часті запитання

Який строк виправлення вважається нормальним?

Універсального числа немає, і ми не будемо його вигадувати. 43 дні в DBIR це медіана по великій вибірці, а не ціль. Строк залежить від того, чи доступна система з інтернету, чи є вразливість у KEV і що станеться, якщо систему зламають. Для периметра й записів KEV він має бути суттєво коротшим, ніж для внутрішніх систем, але таким, який ви справді здатні дотримати.

Що робити, коли патча ще немає або він не вийде?

Застосувати компенсаційні заходи: обхідне рішення від вендора, закриття доступу до інтерфейсу керування, сегментацію, правило блокування на межі, посилений нагляд. Оформіть це як виняток із датою завершення й названим власником, а якщо продукт знято з підтримки, заплануйте заміну.

Як часто сканувати периметр?

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

Чи варто готуватись до ШІ-атак окремо?

Mandiant у M-Trends 2026 пише, що 2025 рік не був роком витоків, прямо спричинених ШІ, а переважна більшість проникнень досі пов'язана з базовими помилками. Тому найкраща підготовка це швидко закривати відомі вразливості та знати свій периметр. Окремий «антиШІ» захист без цих основ не допоможе.

Хочете подивитись на свій розрив між «знайшли» і «закрили» разом із нами? Поговоримо.