ИИ сокращает путь от опубликованной CVE до рабочего эксплойта, и управление уязвимостями через таблицы начинает выглядеть как попытка тушить дата-центр из чайной ложки. Для русскоязычных команд это не абстрактная тревога, а практический вопрос: кто успеет первым — защитники с патчем или атакующие с автоматизированным PoC.
Об этом пишет The New Stack в материале о том, как искусственный интеллект меняет ритм кибербезопасности. Главная мысль простая и неприятная: процессы, которые держатся на Excel, ручной сортировке CVE и периодических созвонах, больше не соответствуют скорости атаки.
Раньше у команд безопасности был пусть небольшой, но понятный люфт. Появлялась уязвимость, вендор выпускал описание, исследователи разбирали детали, затем появлялись публичные proof-of-concept или первые массовые попытки эксплуатации. Теперь ИИ помогает быстрее читать бюллетени, искать похожие баги, собирать цепочки эксплуатации и адаптировать код под конкретную среду. Это не значит, что каждая новая CVE мгновенно превращается в катастрофу. Но среднее время на подготовку атаки сжимается, а ручная бюрократия остается прежней.
Проблема не только в скорости. Таблица с уязвимостями обычно плохо отвечает на главный вопрос бизнеса: что чинить первым. В одном списке оказываются критичные CVE на публичном сервисе, баги в изолированной тестовой среде, устаревшие библиотеки без реального пути эксплуатации и системы, за которые вообще непонятно кто отвечает. Формально все выглядит управляемо: есть строки, статусы, владельцы, дедлайны. На практике это часто инвентаризация тревоги, а не управление риском.
ИИ усугубляет этот разрыв, потому что атакующие автоматизируют не только написание кода. Они ускоряют разведку, сопоставление версий, подбор целей, поиск обходных путей и генерацию вариантов эксплойта. Защитной стороне приходится делать то же самое, но с поправкой на реальность корпоративной инфраструктуры: легаси, исключения, бизнес-критичные системы, окно обновлений раз в месяц и сервисы, о которых помнит только один инженер в отпуске.
Отсюда меняется смысл фразы «управление уязвимостями». Это уже не список CVE с цветовой разметкой по CVSS. Нужен контекст: доступен ли сервис из интернета, есть ли активная эксплуатация, какие данные затронуты, можно ли быстро поставить патч, существует ли временное компенсирующее средство, кто владелец системы и что сломается при обновлении. Без этого команды либо бросаются чинить все подряд, либо тонут в очереди задач, где настоящие риски смешаны с шумом.
Для разработчиков это означает более жесткую интеграцию безопасности в обычный цикл поставки. SBOM, проверка зависимостей, приоритизация по достижимости кода, автоматические pull request с обновлениями, контроль контейнерных образов и политика исключений становятся не украшением зрелого DevSecOps, а базовой гигиеной. Если уязвимая библиотека лежит в репозитории, но не попадает в рантайм, это один разговор. Если она торчит в публичном API с чувствительными данными за спиной, разговор совсем другой.
Для бизнеса вывод еще менее романтичный. Покупка очередного сканера сама по себе не решает проблему, если результаты оседают в таблице и ждут ручного разбора. Нужны процессы, которые связывают данные сканирования с CMDB, облачными ресурсами, CI/CD, тикет-системой и владельцами сервисов. Иначе организация получает красивую витрину риска, но не механизм его снижения.
Управление уязвимостями будет все меньше похоже на квартальную уборку и все больше — на непрерывную диспетчеризацию риска. Вопрос для команд безопасности теперь звучит жестче: способны ли они автоматизировать контекст и приоритеты быстрее, чем атакующие автоматизируют эксплуатацию.