Як ШІ змінює терміни реагування на вразливості

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

ШІ виявляє недоліки, які традиційні інструменти можуть пропустити

У травні 2026 року Google Threat Intelligence Group повідомила про перший випадок, коли, на її думку, зловмисник використав ШІ для допомоги у створенні експлойту нульового дня. Експлойт був у скрипті Python і обходив двофакторну автентифікацію в широко використовуваному інструменті адміністрування систем з відкритим кодом, якщо дійсні облікові дані вже були доступні.

Дослідники заявили, що мають високий рівень упевненості в тому, що модель ШІ допомогла як із виявленням, так і зі створенням засобу експлуатації. Їхня оцінка ґрунтувалася на незвично докладних інструктивних коментарях у скрипті, вигаданій оцінці вразливості та чітко структурованому стилі кодування, характерному для згенерованих результатів. Google не стверджувала, що ширша операція була автономною, і не приписувала код конкретній моделі.

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

Ширші дані Google свідчать, що це не поодинока проблема. Згідно з аналізом Google Threat Intelligence Group за 2025 рік, дослідники відстежили 90 вразливостей нульового дня, які активно експлуатувалися у 2025 році, порівняно з 78 у 2024 році. На корпоративне програмне забезпечення та пристрої припало 43 випадки, або 48% від загальної кількості. Обидва показники стали рекордними в наборі даних Google.

Складні контейнери ускладнюють відстеження вразливостей

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

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

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

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

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

Згенеровані ШІ виправлення все одно потребують програмного контексту

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

У попередньому матеріалі про ШІ-агента, розробленого для автоматизації виправлення вразливостей детально описано, як CodeMender від Google DeepMind за перші шість місяців роботи допоміг створити 72 виправлення безпеки для відомих проєктів із відкритим кодом. Система поєднує міркування моделі зі статичним аналізом, тестуванням під час виконання та фазингом, щоб створювати й оцінювати запропоновані виправлення.

Ці виправлення не приймалися автоматично. Людські дослідники перевіряли кожну зміну перед її поданням, виявляючи регресії та підтверджуючи, що вона усуває першопричину, а не лише видимий симптом.

Навіть схвалена зміна коду не завершує роботу. Команди мають виявити уражені образи, повторно створити їх із виправленою залежністю та протестувати результат перед розгортанням. У середовищі з неналежною документацією пошук кожного екземпляра може тривати довше, ніж створення самого виправлення.

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

Пошук вразливості більше не обов’язково є найповільнішим етапом

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

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