Как AI променя сроковете за реакция при уязвимости

Изкуственият интелект предоставя на изследователите по сигурността нови начини за анализ на код, проследяване на необичайно поведение и идентифициране на пропуски, които конвенционалните инструменти могат да не забележат. Натискът е особено видим при уязвимостите от нулевия ден, а скорошен анализ на 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 корекции по сигурността към утвърдени проекти с отворен код през първите си шест месеца. Системата съчетава разсъждения на модела със статичен анализ, тестване по време на изпълнение и фъзинг, за да създава и оценява предложени корекции.

Тези корекции не са били приемани автоматично. Човешки изследователи са преглеждали всяка промяна, преди тя да бъде изпратена, като са проверявали за регресии и са потвърждавали, че тя отстранява първопричината, а не само видимия симптом.

Дори одобрената промяна в кода не приключва работата. Екипите трябва да идентифицират засегнатите образи, да ги изградят повторно с коригираната зависимост и да тестват резултата преди внедряване. В среда с лоша документация намирането на всеки екземпляр може да отнеме повече време от самото създаване на корекцията.

Точните инвентаризации дават на автоматизираните инструменти нещо конкретно, с което да работят. Те свързват новоразкрития пропуск с версията на пакета, образа и работното натоварване, които действително изискват внимание.

Откриването на пропуска може вече да не е най-бавната стъпка

ИИ ускорява анализа на кода както за нападателите, така и за защитниците, но много забавяния все още възникват след идентифицирането на уязвимостта. Един екип може да прекара часове в отваряне на образи и ръчна проверка на списъци с пакети. Друг може да потърси в актуална инвентаризация и почти веднага да види кои работни натоварвания съдържат засегнатата версия.

Тази разлика има малко общо със сложността на инструмента за откриване. Тя произтича от по-ранни решения относно софтуерните инвентаризации, състава на образите и начина, по който контейнерите се изграждат и заменят. С ускоряването на изследванията на уязвимости практическото предимство принадлежи на организациите, които могат да установят излагането на риск и да внедрят тествана поправка, без първо да се опитват да възстановят какво съдържат техните системи.