ainews
ИИ против уязвимостей: почему разработчики всё ещё проигрывают время
Google зафиксировал первый случай использования ИИ для разработки zero-day эксплойта. Модели находят логические уязвимости, которые пропускают фаззеры и статические анализаторы. Но главная проблема не в скорости обнаружения — а в том, что компании не знают, где у них работает уязвимый софт. Без точного инвентаря зависимостей даже автоматический патч бесполезен.
Если раньше защита выигрывала время за счёт сложности разработки эксплойтов, теперь ИИ уравнял шансы. Конкурентное преимущество получают те, кто автоматизировал весь цикл от обнаружения до патча — а не просто ставит сканеры.
Что произошло
В мае 2026 года Google Threat Intelligence впервые зафиксировала применение ИИ для создания zero-day эксплойта. Атакующий использовал языковую модель, чтобы найти и эксплуатировать логическую уязвимость в популярном open-source инструменте администрирования — обход двухфакторной аутентификации при наличии валидных креденшелов. Эксперты распознали ИИ-код по детальным комментариям, фальшивому vulnerability score и характерному стилю генерации.
Главное не в самом факте использования модели, а в типе уязвимости: это не краш, не переполнение буфера и не SQL-инъекция. Обычные фаззеры и статические анализаторы такие дыры не видят — они ищут технические ошибки. Языковая модель анализирует логику взаимодействия функций, прав доступа и ожидаемого поведения. Итог: 90 zero-day в 2025 году против 78 в 2024-м, 48% из них — в корпоративных системах.
Однако скорость обнаружения уязвимости перестала быть узким местом. Проблема сместилась: команды безопасности не могут быстро понять, где именно у них работает уязвимый компонент. Контейнерные образы содержат десятки унаследованных зависимостей, часть которых вообще не нужна для работы приложения. Уязвимая библиотека может сидеть в базовом образе на три уровня ниже реального кода.
Log4Shell в 2021-м показал масштаб: патч вышел быстро, но компании месяцами искали все инстансы уязвимой Log4j. ИИ-агенты вроде CodeMender от DeepMind уже автоматизируют написание патчей (72 фикса за полгода), но даже готовый код бесполезен без точного SBOM (software bill of materials) и понимания, в каких образах запущена уязвимость.
Автор: Сергей Ефимов · Источник: artificialintelligence-news.com
Разработчикам. Языковые модели теперь находят логические ошибки в permission-схемах и trust assumptions — то, что фаззеры не ловят. Минимальные контейнерные образы и актуальные SBOM сокращают время от disclosure до патча в разы. Если не знаешь состав зависимостей — автогенерация фикса не поможет.
Бизнесу. 48% zero-day в 2025-м ударили по корпоративному софту. Скорость реакции теперь упирается не в написание патча, а в понимание, где работает уязвимый код. Компании без инвентаря зависимостей тратят недели на поиск уязвимых инстансов — конкуренты с SBOM закрывают дыры за часы.
Инвесторам. Рынок SBOM-инструментов и контейнерной безопасности растёт на фоне ИИ-ускорения уязвимостей. Инвестиции идут в автоматизацию инвентаризации зависимостей, минимизацию образов и DevSecOps-платформы. Те, кто продаёт только обнаружение уязвимостей, проигрывают платформам полного цикла response.
- SBOM-as-a-Service: автоматическая генерация и актуализация software bill of materials для контейнеров и микросервисов, интеграция с CI/CD
- ИИ-агент для поиска уязвимых зависимостей: сканирует образы, сопоставляет с CVE-базами, автоматически перестраивает контейнеры с фиксами
- Платформа минимизации Docker-образов: анализ реально используемых зависимостей, автоудаление лишних пакетов, снижение attack surface
- DevSecOps-платформа с AI-патчингом: от обнаружения до автоматического тестирования и деплоя исправленных образов без ручного вмешательства
- Консалтинг по container security для enterprise: внедрение SBOM, настройка rebuild-процессов, автоматизация vulnerability response timeline
- Переоценка возможностей ИИ-агентов: автогенерация патчей требует ручной проверки на регрессии и побочные эффекты, иначе фикс ломает продакшен
- SBOM не панацея: если процесс обновления образов медленный или ручной, даже точный инвентарь не ускорит реакцию
- Гонка вооружений: атакующие тоже используют модели для поиска логических уязвимостей — gap между disclosure и эксплуатацией сокращается для обеих сторон
- Сложность внедрения: многие компании не готовы перестраивать CI/CD под автоматический rebuild образов при каждом CVE
Это не очередная страшилка про ИИ-хакеров. Google действительно поймал первый случай, когда модель помогла найти и эксплуатировать логическую дыру — не баг, а противоречие в логике доступа. Фаззеры такое не видят. И да, 90 zero-day за год — рекорд.
Но честно: проблема не в том, что ИИ ускорил атакующих. Проблема в том, что большинство компаний до сих пор не знают, какие библиотеки у них запущены и где. Log4Shell был в 2021-м — а половина индустрии до сих пор ищет уязвимости вручную. ИИ-агенты типа CodeMender могут генерить патчи за минуты, но если у тебя нет SBOM и автоматического rebuild — ты всё равно потратишь недели на поиск инстансов. Это вопрос инфраструктуры, а не хайпа вокруг моделей.
Комментарии