Искусственный интеллект ускоряет эксплуатацию уязвимостей. Таблицы уязвимостей не успевают
6 октября 2026 г. · 3 мин чтения
Искусственный интеллект изменил почти каждый аспект разработки программного обеспечения и кибербезопасности. Но, возможно, одно из самых глубоких изменений происходит в области, традиционно получившей меньше стратегического внимания: как организации управляют программными уязвимостями.
Основная модель управления уязвимостями оставалась относительно стабильной в течение многих лет. Сканирование программного обеспечения, выявление CVE, присвоение оценок тяжести, приоритизация результатов и передача их разработчикам для исправления. Этот подход никогда не был идеальным представлением риска. В эпоху искусственного интеллекта его ограничения становятся невыносимыми.
Проблема не только в том, что у организаций больше уязвимостей для исправления. Объем создаваемого программного обеспечения растет быстро, обнаружение уязвимостей ускоряется, а время, необходимое для создания эксплойтов, сокращается. Искусственный интеллект ускоряет атаки, объединяя уязвимости в пути, которые трудно предвидеть вручную.
В результате растет разрыв между количеством уязвимостей, которые могут выявить команды безопасности, и теми, которые они могут реально изучить и устранить. Чтобы сократить этот разрыв, нужно изменить задаваемый вопрос. Вместо «Сколько CVE у нас есть?», следует спрашивать «Какие уязвимости создают значимый риск в нашей среде?».
Тяжесть не равна риску
CVE сообщает о существовании публично известной уязвимости. Она не указывает, насколько вероятно её эксплуатация против конкретной организации. Это фундаментальное различие.
Система оценки уязвимостей (CVSS) предназначена для передачи технической тяжести и потенциального воздействия при успешной эксплуатации. Но тяжесть не всегда говорит о том, что уязвимость эксплуатируется в реальном мире, доступна для эксплуатации, экспонирована внешне или выполняется в конкретной среде.
Две организации могут иметь одинаковую CVE и сталкиваться с разными уровнями риска. Одна может иметь уязвимый компонент за множеством защитных слоёв, без внешнего доступа и без релевантного пути выполнения. Другая может запускать его в интернет‑фacing производственном приложении, поддерживающем критический бизнес‑процесс. CVE одинаковая, но риск различается.
Поэтому программы управления уязвимостями, построенные вокруг статических оценок тяжести, создают вводящее в заблуждение ощущение прогресса. Команды тратят усилия на закрытие больших количеств результатов, не уменьшая при этом наиболее опасные экспозиции. Это приводит к тому, что называют «театром CVE»: измеряется активность, а не реальное снижение риска.
Искусственный интеллект меняет экономику эксплуатации
Срочность этого перехода усиливается благодаря искусственному интеллекту. Объем создаваемого кода растет стремительно. Даже если плотность уязвимостей в строке кода снижается, рост общего объема программного обеспечения может привести к большему общему воздействию. При этом всё больше современного программного обеспечения зависит от открытых компонентов, увеличивая объем кода, который организации должны понимать и защищать.
Атакующие также выигрывают от автоматизации. Задачи, требовавшие значительных ручных усилий, всё больше ускоряются с помощью искусственного интеллекта. Сочетание большего количества уязвимостей и сокращающегося времени до эксплуатации создает фундаментально новый контекст кибербезопасности.
Это означает, что организации не могут позволить себе процессы управления уязвимостями, основанные на длительных последовательных ручных проверках. Программы безопасности должны стать более контекстными, непрерывными и автоматизированными.
Один из самых эффективных способов улучшить управление уязвимостями, перестать думать только об устранении уязвимостей после их появления. Нужно также задавать вопросы о том, как уменьшить количество уязвимостей, попадающих в среду. Это начинается с программного фундамента.
Использование закалённых или отобранных базовых образов и языковых библиотек может снизить объём уязвимостей до развертывания приложений. Код, разработанный внутри организации, можно обрабатывать с помощью статического анализа безопасности приложений и сканирования, поддерживаемого искусственным интеллектом, а конфигурационные слабости можно обнаруживать с помощью рамок, таких как STIG.
Это важно, потому что уязвимости, лишь одна из сторон программной безопасности. Система может содержать относительно мало CVE и всё равно представлять серьёзную опасность. Избыточные привилегии, слабые настройки аутентификации или другие конфигурационные проблемы могут предоставить злоумышленникам возможность получить первоначальный доступ или перемещаться по сети.
Сканирование по STIG адресует эту вторую сторону, оценивая конфигурацию против установленных требований безопасности. Эти инструменты представляют собой автоматизированные чек‑листы, способные выявлять и, в некоторых случаях, устранять конфигурационные слабости. Цель, сделать программное обеспечение максимально защищённым до того, как оно станет проблемой для других.
Ещё один важный сдвиг, который должны рассмотреть лидеры безопасности: производство, источник истины.
Исторически организации часто сканировали реестры или репозитории перед тем, как программное обеспечение достигнет производства. Это предоставляет полезную информацию, но отражает предполагаемый риск, а не то, что фактически развернуто. Производственные среды меняются. Образцы меняются. Конфигурации меняются. Новые уязвимости раскрываются после развертывания. Поэтому организациям нужна видимость того, что действительно запущено, и возможность оценивать это непрерывно. Именно здесь вступают в силу сканирование в продакшене, анализ доступности и контекст среды.