Код быстрее, проверок больше: как ИИ меняет DevSecOps

В конце августа мы провели по ИИ в безопасной разработке и решили собрать в этом материалы основные тезисы наших экспертов. Тема - горячая, важная, поэтому добро пожаловать в комментарии!

Итак, начинаем разбираться, как ИИ меняет безопасную разработку вместе с Антоном Прокофьевым, директором центра разработки решений по контролю безопасности ПО ГК «Солар»; Дмитрием Евдокимовым, основателем и генеральным директором Luntry; Дмитрием Частухиным, основателем и техническим директором Hexway.

Где ИИ уже снимает рутинную нагрузку с AppSec? Почему сгенерированный код все равно требует проверки и зачем контролировать ИИ-приложения уже во время исполнения?

Тренд на радикальное ускорение

Главное изменение в безопасной разработке за последние годы – радикальное ускорение процессов взлома и защиты. По данным «Солара», ИИ на стороне атакующих сократил окно для реализации уязвимостей с 63 дней в 2019 году до нескольких часов в 2025 году. Антон Прокофьев связывает ускорение еще с двумя факторами: переходом на сторонние библиотеки и распространением вайбкодинга. Изменилась и стратегия злоумышленников. Вместо атаки на отдельное приложение они могут искать уязвимость в компоненте, который используют сразу многие компании.

«Вектор абсолютно поменялся. Большинство людей используют сторонние библиотеки, мало кто пишет собственный код. Мы даже замеряли – используется где-то 90–95% стороннего кода. Злоумышленники теперь нацелены на цепочку поставок: проще взломать одну библиотеку, которую используют 10 000 компаний, чем пытаться взломать одно приложение», – отмечает Антон Прокофьев.

ИИ в разработке ведет себя совсем не так, как человек, добавляет Дмитрий Евдокимов. Модель может не использовать готовую библиотеку, а написать код сама, создавая другой набор рисков. «Искусственный интеллект выдает уникальный код, но проблема в том, что его никто никогда не видел, не тестировал, он не покрыт никакими фазами тестами, секьюрити-командами», – объясняет Дмитрий Евдокимов.

Еще одна проблема возникает, когда модель уже встроена в обычный процесс разработки и воспринимается как легитимный инструмент. Она может предложить синтаксически корректный код с небезопасными решениями – например, устаревшей криптографией или без проверки входных данных. Если разработчик доверяет результату модели и не проводит отдельную проверку, такие ошибки могут остаться незамеченными.

Проекты с открытым исходным кодом (open source) содержат массу уязвимостей, которые физически невозможно закрыть только «человеческими» силами. Поэтому исследователи подключают ИИ и для их поиска. Здесь возникает дополнительный риск: библиотека может иметь отметку о проверке, хотя часть анализа фактически выполнила модель с неизвестным качеством, предупреждает Дмитрий Частухин.

Чем быстрее разработчики создают код, тем больше зависимостей, результатов сканирования и других артефактов поступает на проверку. Если тестирование и разбор находок не ускоряются следом, очередь растет быстрее, чем команда безопасности успевает ее разбирать. Для компаний с закрытыми контурами остается вопрос передачи исходного кода во внешние ИИ-сервисы. В общем объеме утечек конфиденциальной информации в большие языковые модели (LLM) доля исходного кода составляет 41%.

Тренд в поиске уязвимостей: «серебряная ИИ-пуля» или гибридный подход

ИИ уже используют на разных этапах разработки: при подготовке технического задания, распределении задач, генерации кода и тестов безопасности.

Еще один сценарий – разбор и верификация срабатываний (triage), а также подготовка исправлений кода (code fix). ИИ применяют и для автоматического подбора и обновления зависимостей (dependency gardening). В Solar appScreener эти задачи выполняет ИИ-плагин, интегрированный в модуль статического анализа. Модель обучена на данных проектов по безопасной разработке более 1000 компаний за семь лет. Точность составляет более 90% на этапе триажа и до 85% при подготовке исправлений. По оценке «Солара», ИИ-плагин повышает емкость AppSec-команд в 10 раз.

ИИ можно подключать и к комплексной проверке приложения. Например, анализ состава ПО (SCA) находит уязвимую библиотеку в сервисе авторизации, статический анализ кода (SAST) проверяет, вызывает ли приложение уязвимую функцию, а динамический анализ (DAST) подтверждает, можно ли передать вредоносный параметр в работающий сервис. Первичный разбор большого массива находок можно частично передать ИИ. Критические уязвимости и предложенные моделью исправления по-прежнему приходится перепроверять разработчикам и специалистам по безопасности.

«Можно автоматизировать многие процессы, но за моделью придется перепроверять: в случае критических уязвимостей риск пропуска достаточно высокий. ИИ может быть инструментом, но человека он не заменит. Его можно натравить на низкоуровневые уязвимости, но для критически важных проектов нужна повторная проверка разработчиков и безопасников», – отмечает Антон Прокофьев.

ИИ не избавляет от необходимости комплексной проверки, соглашается Дмитрий Частухин. «Код, сгенерированный LLM, однозначно не доверенный. Его нужно проверять. Это как текст: по определенным паттернам можно понять, что он сгенерирован. Так что работы у безопасников стало больше», – считает Дмитрий Частухин.

При вайбкодинге возникает и менее очевидный риск, добавляет Дмитрий Евдокимов. Баги в сгенерированном коде – только часть проблемы. Если сотрудники перестают понимать, как код устроен изнутри и что в нем происходит, компания постепенно теряет собственную техническую экспертизу.

Безопасность придется масштабировать вместе с разработкой

Разработчикам приходится учитывать безопасность цепочки поставок, тестировать модели и приложения на устойчивость и контролировать их во время исполнения. Пока модель только генерирует код, результат можно проверить до запуска. С ИИ-агентами этого уже недостаточно. Решение формируется во время выполнения, и на него одновременно влияют модель, запрос (prompt), внешние данные, память, доступные инструменты и права в инфраструктуре.

Проверять приходится и сами средства ИИ-автоматизации. Эксперты Solar 4RAYS изучили уязвимости в нескольких таких инструментах и агентах, для которых с начала 2025 года по середину 2026 года появились публичные способы эксплуатации. В выборке встречались кража API-ключей и токенов, обход аутентификации, удаленное выполнение кода и «побег из песочницы». К привычной поверхности атаки добавляются специфичные для ИИ-среды риски – например, инъекции в запросы (prompt injection), вредоносные сценарии автоматизации и расширения. И это только проблемы, обнаруженные в исследованном наборе инструментов, а не полный перечень уязвимостей ИИ-систем. В Kubernetes и контейнерах контролировать приходится уже работающий код: какие ресурсы он использует, что делает внутри кластера и к каким объектам получает доступ.

Платформа Luntry для комплексной безопасности контейнерных приложений и систем оркестрации Kubernetes учитывает контекст работы ИИ-кластеров и ИИ-агентов. В частности, она позволяет приоритизировать уязвимости в коде, созданном или проверенном с помощью ИИ, выявлять неизвестные угрозы и контролировать происходящее в кластере и контейнерах во время исполнения. С ростом потока кода и находок сложнее становится и их разбор, отмечает Дмитрий Частухин. Дополнительный сканер сам по себе эту проблему не решает.

Платформа оркестрации безопасности приложений (ASOC) Hexway собирает результаты статического и динамического анализа, анализа состава ПО, пентестов и ручных проверок в одном контуре, нормализует их и убирает дубли. При приоритизации учитываются критичность приложения, достижимость и эксплуатируемость уязвимости, а также требования к срокам исправления. ИИ помогает провести первичный разбор и сгруппировать похожие находки.

На этапе исправления Hexway ASOC объясняет проблему в контексте приложения, формирует рекомендации и помогает подготовить безопасный вариант кода и проверочный тест. Платформа также отслеживает сроки, повторные проверки и статус уязвимости.

В едином контуре Solar appScreener отвечает за анализ приложений и автоматизацию части проверки кода, Hexway ASOC – за работу с результатами проверок и управление устранением уязвимостей, Luntry – за контейнеры, Kubernetes и контроль в среде исполнения (runtime).

С дальнейшим внедрением ИИ российской сфере разработки предстоит интересное время, предсказывает Дмитрий Частухин: «Будут и изощренные атаки, и методы защиты от них интереснее». Дмитрий Евдокимов рекомендует не откладывать вопросы защиты: «Чем раньше вы этим озаботитесь, тем больше вероятность, что будете на коне. А вот догонять будет больнее».

Что меняется для команд разработки

Ускорение разработки увеличивает объем работы для AppSec. Ручной разбор всех находок становится узким местом, поэтому часть триажа, подготовки исправлений и работы с зависимостями команды могут передавать ИИ. Одной проверкой исходного кода процесс уже не ограничивается. С распространением ИИ-агентов контролировать приходится контейнеры, Kubernetes и поведение приложения после запуска.

В связке Solar appScreener, Hexway ASOC и Luntry эти задачи распределены по всему жизненному циклу ПО – от разработки кода и тестирования до выхода в промышленную среду и эксплуатации.