Skip to content
RiverCore
Годинник Zero-Day: Вікно для Експлойту Скоротилося до 24 Годин
zero-day exploitpatch windowvulnerability disclosurezero-day exploitation window shrinks 24 hoursmean time to exploitation 2026

Годинник Zero-Day: Вікно для Експлойту Скоротилося до 24 Годин

28 тра 20266 хв. читанняAlex Drover

Кожен, хто хоч раз брав участь у понеділковому тріаж-дзвінку, знає негласне правило: у вас є приблизно квартал, щоб залатати незручні вразливості, перш ніж хтось перетворить їх на зброю. Це правило щойно поховали. Новий метричний проєкт під назвою Zero-Day Clock стверджує, що середній час від публічного розкриття до активної експлуатації скоротився з майже року у 2021-му до трохи більше ніж двадцяти чотирьох годин у 2026-му. Вікна для патчів, розроблені з урахуванням можливостей людини-зловмисника, руйнуються інструментами атак, які не сплять.

Що Сталося

Zero-Day Clock — це вимірювальний проєкт, запущений Сергієм Еппом із Sysdig, якого підтримала більшість провідних технологічних і кіберзахисних вендорів. Його єдине завдання — покласти цифри на те, на що галузь лише вказувала пальцем упродовж двох років: AI-асистована генерація експлойтів стискає вікно реагування захисника до величини, близької до нуля.

Як Tom's Hardware повідомив, середній інтервал між виявленням вразливості та її експлуатацією скоротився з приблизно року у 2021-му до трохи більше ніж доби цього року. Прогноз ZDC ще похмуріший: одна година до 2027 року, а згодом — одна хвилина.

Склад загроз теж змінився. П'ять років тому 31% експлойтів були zero-day, тобто зловмисники вже використовували їх до розкриття. Сьогодні ця цифра становить 73,2%. Зворотний бік — те, що дані називають невикористаними вразливостями: баги, які було повідомлено, але вони тихо зникали, не ставши зброєю. Ця категорія у 2021-му становила близько 60–70% і зараз скоротилася до 25% на момент розкриття. Якщо відсунути часову шкалу на шість тижнів — жодна вразливість не залишається невикористаною, тоді як для минулорічної когорти цей показник становив близько 24%.

Дослідники чітко позначають межі видимості. «Ми відстежуємо лише публічно видимі експлойти. Приватні або державні експлойти можуть існувати раніше», — зазначають вони. Тому сприймайте ці цифри як нижню межу, а не верхню. Реальна крива є крутішою.

Технічна Анатомія

Чому годинник іде так швидко? Сходяться дві структурні причини.

По-перше, сирий субстрат сучасного програмного забезпечення досі небезпечний. ZDC відносить 70% вразливостей до помилок безпеки пам'яті. Це та сама родина проблем — переповнення буфера, use-after-free — яку ми не можемо подолати ще з 1990-х. AI-інструменти не винайшли ці класи помилок. Вони просто індустріалізували процес їх пошуку. Модель, здатна прочитати diff, визначити небезпечну арифметику покажчиків і згенерувати робочий proof-of-concept, перетворює те, що раніше займало тиждень роботи досвідченого реверс-інженера, на виконання скрипту.

По-друге, сам пайплайн розкриття витікає сигналом. Стандартне для галузі 90-денне вікно розкриття було розроблено для світу, де розробка експлойту займала тижні кваліфікованої праці. Коли час генерації падає нижче часу розгортання патча, розкриття стає стартовим пострілом для зловмисника, а не для захисника. Каталог CISA KEV демонструє цю закономірність уже місяцями: вразливості потрапляють до списку активно експлуатованих протягом днів після присвоєння CVE, а не кварталів.

Рекомендовані ZDC технічні контрзаходи безпосередньо відповідають цим двом тискам. На боці субстрату: відмовитися від C і C++ на користь Rust або іншої мовно-безпечної мови, постачати продукти з увімкненими за замовчуванням функціями безпеки, впровадити zero-trust архітектуру та проєктувати системи як одноразові, щоб скомпрометований хост можна було знищити і відбудувати за хвилини. На боці інструментарію: відкривати AI-захисні інструменти з відкритим кодом, щоб захисники мали паритет зі зловмисниками, які вже мають доступ до тих самих моделей.

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

Хто Постраждає

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

iGaming-платформи особливо вразливі. Інфраструктура live-беттингу працює на межі, платіжні інтеграції розлогі, а регуляторні обмеження часто сповільнюють екстрене латання, оскільки кожна зміна потребує підтвердження комплаєнсу в кількох юрисдикціях. Вікно експлойту у 24 години проти стека, якому потрібно 72 години для впровадження регульованої зміни конфігурації — це структурна невідповідність. Виробничі інциденти, які я бачив у цій сфері, зазвичай простежуються до стороннього SDK або інтеграції фіду коефіцієнтів, якою ніхто з основної команди не володіє. Тепер ці вендори мають бути на тому самому годиннику.

Fintech знаходиться в аналогічній пастці. PCI-скоупінг, театр change advisory board та партнери по core banking, що розгортають оновлення за власним льодовиковим графіком, означають, що найслабша ланка встановлює реальну затримку патчів. Незручний висновок: якщо ваш KYC-вендор патчиться щомісяця, ваше ефективне вікно експозиції — щомісячне, незалежно від того, наскільки швидко працює ваш власний пайплайн.

Команди крипто та DeFi мають протилежну проблему. Вони патчаться швидко, але незмінні контракти взагалі не можна пропатчити. Коли вікно експлойту скорочується до години, весь захисний стан має зміститися до circuit breakers, pausable-контрактів і агресивного моніторингу mempool. Код, який неможливо змінити, потребує навколо себе інфраструктури, яку можна.

Вендори корпоративної інфраструктури стикаються з питанням відповідальності в лоб. Фраза Брюса Шнайєра у звіті ZDC категорична: «Жодна галузь за останні 150 років не покращувала безпеку без примусу з боку уряду». Він також зазначає, що небезпечні продукти, перші на ринку, щоразу перемагають краще збудованих конкурентів. Якщо законодавство про відповідальність ухвалять, економічні стимули нарешті зміняться. Якщо ні — перегони на дно тривають.

Плейбук для Команд Безпеки

Конкретні дії на найближчі два тижні, впорядковані за ефективністю:

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

Проінвентаризуйте свою C та C++ експозицію. 70% вразливостей є помилками безпеки пам'яті — це вхідні дані для планування, а не триvia. Визначте, які сервіси у вашому критичному шляху досі написані небезпечними мовами. Цього кварталу ви їх не перепишете, але маєте знати, які є найпріоритетнішими кандидатами на міграцію до Rust упродовж наступного року.

Зробіть хости одноразовими. Якщо відновлення скомпрометованого production-вузла займає більше п'ятнадцяти хвилин — виправте це, перш ніж купувати ще одну EDR-ліцензію. Одноразовість — найдешевший захід проти експлойту, який ви все одно не встигли б пропатчити вчасно.

Налаштуйте KEV-орієнтовані сповіщення. Підпишіться на фіди MITRE CVE та оновлення CISA KEV напряму у вашу on-call-ротацію, а не просто в Slack-канал, який ніхто не читає о 2 ночі. Коли вікно експлойту — доба, асинхронного сповіщення недостатньо.

Тисніть на вендорів письмово. Додавайте до оновлень контрактів clauses про SLA патчів. Зобов'язання щодо критичних патчів протягом менше ніж 72 годин мають бути мінімальною вимогою. Якщо вендор не може погодитися на це — він є потенційною передачею відповідальності.

Ключові Висновки

  • Середній час від розкриття до експлуатації скоротився з ~1 року (2021) до ~1 дня (2026), прогнозується 1 година у 2027-му. 90-денне вікно розкриття — пережиток минулого.
  • Частка zero-day серед експлойтів зросла з 31% до 73,2% за п'ять років. Захисники прибувають після зловмисника, а не до нього.
  • 70% вразливостей — це помилки безпеки пам'яті. Міграція критичних сервісів на Rust є стратегічним пріоритетом, а не бажаним додатком.
  • ZDC рахує лише публічні експлойти. Приватна та державна активність за визначенням поза графіком, тому реальна крива гірша.
  • Одноразова інфраструктура, SLA патчів вендорів і KEV-орієнтовані сповіщення перевершують будь-який окремий блискучий захисний інструмент у скороченні розриву.

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

Q: Що таке Zero-Day Clock?

Це вимірювальний проєкт, запущений Сергієм Еппом із Sysdig за підтримки більшості провідних технологічних і кіберзахисних вендорів, що відстежує, як швидко публічно розкриті вразливості експлуатуються. Його головна метрика — середній час від розкриття до активної експлуатації, який скоротився з приблизно року у 2021-му до трохи більше ніж доби у 2026-му.

Q: Чи залишається корисним 90-денне вікно розкриття вразливостей?

Не у своїй нинішній формі. 90-денний стандарт було розроблено для світу, де розробка експлойту займала тижні кваліфікованої роботи. З AI-асистованим інструментарієм, що скорочує час до експлуатації до менше ніж 48 годин, розкриття тепер функціонує як стартовий постріл для зловмисників, якщо координоване латання ще не розпочато до публікації.

Q: Яка єдина найефективніша зміна, яку команда безпеки може зробити цього кварталу?

Зробити production-хости справді одноразовими. Якщо скомпрометований вузол можна знищити і відбудувати менше ніж за п'ятнадцять хвилин — ви нейтралізуєте більшість шкоди від експлойтів, які не вдалося б пропатчити вчасно. Поєднайте це з письмовими SLA патчів від вендорів — і ви закриєте найбільший структурний розрив, який виявляють дані ZDC.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
ПОДІЛИТИСЯ
// RELATED ARTICLES
ГоловнаРішенняПроєктиПро насКонтакт
Новини06
Дублін, Ірландія · ЄСGMT+1
LinkedIn
🇺🇦UK