По данным исследования «Солара» и УЦСБ, 82% организаций уже используют ИИ для разработки ПО. Вайбкодинг ускоряет создание приложений в сотни раз, но вместе с объемом кода растет нагрузка на его проверку. Публичные языковые модели при этом неточно определяют до 40–50% уязвимостей, которые выявляют инструменты статического анализа кода.
Критичные уязвимости, по данным исследований безопасности приложений «Солара», содержатся в 75–80% массовых цифровых сервисов. Рост объемов разработки увеличивает число зависимостей, результатов сканирования и других находок, которые приходится разбирать AppSec-командам.
Как ИИ меняет безопасную разработку, разбирают эксперты ГК «Солар» — Антон Прокофьев, директор центра разработки решений по контролю безопасности ПО, Дмитрий Евдокимов, основатель и генеральный директор Luntry, и Дмитрий Частухин, основатель и технический директор Hexway. Они объясняют, где ИИ уже снимает рутинную нагрузку с AppSec, почему сгенерированный код все равно требует проверки и зачем контролировать ИИ-приложения уже во время исполнения.
Тренд на радикальное ускорение
Главное изменение в безопасной разработке за последние годы — радикальное ускорение процессов взлома и защиты. По данным «Солара», ИИ на стороне атакующих сократил окно для реализации уязвимостей с 63 дней в 2019 году до нескольких часов в 2025 году.
Антон Прокофьев связывает ускорение еще с двумя факторами: переходом на сторонние библиотеки и распространением вайбкодинга. Изменилась и стратегия злоумышленников. Вместо атаки на отдельное приложение они могут искать уязвимость в компоненте, который используют сразу многие компании.
«Вектор абсолютно поменялся. Большинство людей используют сторонние библиотеки, мало кто пишет собственный код. Мы даже замеряли — используется где-то 90–95% стороннего кода. Злоумышленники теперь нацелены на цепочку поставок, ведь проще взломать одну библиотеку, которую используют 10 000 компаний, чем пытаться взломать одно приложение».
Антон Прокофьев, директор центра разработки решений по контролю безопасности ПО
ИИ в разработке ведет себя совсем не так, как человек, добавляет Дмитрий Евдокимов. Модель может не использовать готовую библиотеку, а написать код сама, создавая другой набор рисков.
«Искусственный интеллект выдает уникальный код, но проблема в том, что его никто никогда не видел, не тестировал, он не покрыт никакими фазами, тестами, секьюрити-командами», — объясняет Дмитрий Евдокимов.
Проекты с открытым исходным кодом (open source) содержат массу уязвимостей, которые физически невозможно закрыть только «человеческими» силами, поэтому исследователи подключают ИИ и для их поиска. Здесь возникает дополнительный риск: библиотека может иметь отметку о проверке, хотя часть анализа фактически выполнила модель с неизвестным качеством, предупреждает Дмитрий Частухин.
Чем быстрее разработчики создают код, тем больше зависимостей, результатов сканирования и других артефактов поступает на проверку. Если тестирование и разбор находок не ускоряются следом, очередь растет быстрее, чем команда безопасности успевает ее разбирать.
Для компаний с закрытыми контурами остается вопрос передачи исходного кода во внешние ИИ-сервисы. В общем объеме утечек конфиденциальной информации в большие языковые модели (LLM) доля исходного кода составляет 41%.
ИИ-плагин Solar appScreener можно развернуть внутри инфраструктуры компании без доступа в интернет. Он работает в модуле статического анализа кода (SAST), помогает разбирать срабатывания и готовить варианты исправлений без передачи кода и результатов анализа внешнему провайдеру.
Тренд в поиске уязвимостей: «серебряная ИИ-пуля» или гибридный подход
ИИ уже используют на разных этапах разработки: при подготовке технического задания, распределении задач, генерации кода и тестов безопасности.
Еще один сценарий — разбор и верификация срабатываний (triage), а также подготовка исправлений кода (code fix). ИИ применяют и для автоматического подбора и обновления зависимостей (dependency gardening).
В Solar appScreener эти задачи выполняет ИИ-плагин, интегрированный в модуль статического анализа. Модель обучена на данных проектов по безопасной разработке более 1000 компаний за семь лет. Точность составляет более 90% на этапе триажа и до 85% при подготовке исправлений. По оценке «Солара», ИИ-плагин повышает емкость AppSec-команд в 10 раз.
ИИ можно подключать и к комплексной проверке приложения. Например, анализ состава ПО (SCA) находит уязвимую библиотеку в сервисе авторизации, статический анализ кода (SAST) проверяет, вызывает ли приложение уязвимую функцию, а динамический анализ (DAST) подтверждает, можно ли передать вредоносный параметр в работающий сервис.
Первичный разбор большого массива находок можно частично передать ИИ. Критические уязвимости и предложенные моделью исправления по-прежнему приходится перепроверять разработчикам и специалистам по безопасности.
«Можно автоматизировать многие процессы, но за моделью придется перепроверять: в случае критических уязвимостей риск пропуска достаточно высокий. ИИ может быть инструментом, но человека он не заменит. Его можно натравить на низкоуровневые уязвимости, но для критически важных проектов нужна повторная проверка разработчиков и безопасников», — отмечает Антон Прокофьев.
ИИ не избавляет от необходимости комплексной проверки, соглашается Дмитрий Частухин.
«Код, сгенерированный LLM, однозначно не доверенный. Его нужно проверять. Это как текст, по определенным паттернам можно понять, что он сгенерирован. Так что работы у безопасников стало больше».
Дмитрий Частухин, основатель и технический директор Hexway
При вайбкодинге возникает и менее очевидный риск, добавляет Дмитрий Евдокимов. Баги в сгенерированном коде — только часть проблемы. Если сотрудники перестают понимать, как код устроен изнутри и что в нем происходит, компания постепенно теряет собственную техническую экспертизу.
Безопасность придется масштабировать вместе с разработкой
Использование ИИ добавляет новые задачи и самой команде безопасности. Разработчикам приходится учитывать безопасность цепочки поставок, тестировать модели и приложения на устойчивость и контролировать их во время исполнения.
Пока модель только генерирует код, результат можно проверить до запуска. С ИИ-агентами этого уже недостаточно. Решение формируется во время выполнения, и на него одновременно влияют модель, запрос (prompt), внешние данные, память, доступные инструменты и права в инфраструктуре.
В Kubernetes и контейнерах контролировать приходится уже работающий код: какие ресурсы он использует, что делает внутри кластера и к каким объектам получает доступ. Платформа Luntry для комплексной безопасности контейнерных приложений и систем оркестрации Kubernetes учитывает контекст работы ИИ-кластеров и ИИ-агентов. В частности, она позволяет приоритизировать уязвимости в коде, созданном или проверенном с помощью ИИ, выявлять неизвестные угрозы и контролировать происходящее в кластере и контейнерах во время исполнения.
С ростом потока кода и находок сложнее становится и их разбор, отмечает Дмитрий Частухин. Дополнительный сканер сам по себе эту проблему не решает.
Платформа оркестрации безопасности приложений (ASOC) Hexway собирает результаты статического и динамического анализа, анализа состава ПО, пентестов и ручных проверок в одном контуре, нормализует их и убирает дубли. При приоритизации учитываются критичность приложения, достижимость и эксплуатируемость уязвимости, а также требования к срокам исправления. ИИ помогает провести первичный разбор и сгруппировать похожие находки.
На этапе исправления Hexway ASOC объясняет проблему в контексте приложения, формирует рекомендации и помогает подготовить безопасный вариант кода и проверочный тест. Платформа также отслеживает сроки, повторные проверки и статус уязвимости.
В едином контуре Solar appScreener отвечает за анализ приложений и автоматизацию части проверки кода, Hexway ASOC — за работу с результатами проверок и управление устранением уязвимостей, Luntry — за контейнеры Kubernetes и контроль в среде исполнения (runtime).
С дальнейшим внедрением ИИ российской сфере разработки предстоит интересное время, предсказывает Дмитрий Частухин: «Будут и изощренные атаки, и методы защиты от них интереснее».
Дмитрий Евдокимов рекомендует не откладывать вопросы защиты: «Чем раньше вы этим озаботитесь, тем больше вероятность, что будете на коне. А вот догонять будет больнее».
Что меняется для команд разработки
Ускорение разработки увеличивает объем работы для AppSec. Ручной разбор всех находок становится узким местом, поэтому часть триажа, подготовки исправлений и работы с зависимостями команды могут передавать ИИ.
Одной проверкой исходного кода процесс уже не ограничивается. С распространением ИИ-агентов контролировать приходится контейнеры Kubernetes и поведение приложения после запуска.
В связке Solar appScreener, Hexway ASOC и Luntry эти задачи распределены по всему жизненному циклу ПО — от разработки кода и тестирования до выхода в промышленную среду и эксплуатации.