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

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

ИИ в разработке ведёт себя иначе, чем человек, отмечает Дмитрий Евдокимов. Модель может не использовать готовую библиотеку, а сгенерировать уникальный код, который никто никогда не тестировал и не проверял секьюрити-командами. Это создаёт новый набор рисков: даже синтаксически корректный код может содержать небезопасные решения, такие как устаревшая криптография или отсутствие проверки входных данных. Если разработчик доверяет результату модели и не проводит дополнительную проверку, ошибки остаются незамеченными. Дмитрий Частухин добавляет, что open source проекты содержат множество уязвимостей, и для их поиска всё чаще подключают ИИ, но это порождает риск: библиотека может иметь отметку о проверке, хотя анализ выполнен моделью с неизвестным качеством. Таким образом, доверие к автоматизированным инструментам может обернуться новыми брешами.

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

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

ИИ можно подключать и к комплексной проверке приложения. Например, анализ состава ПО (SCA) находит уязвимую библиотеку в сервисе авторизации, статический анализ кода (SAST) проверяет, вызывает ли приложение уязвимую функцию, а динамический анализ (DAST) подтверждает, можно ли передать вредоносный параметр в работающий сервис. Первичный разбор большого массива находок можно частично передать ИИ. Однако критические уязвимости и предложенные моделью исправления по-прежнему требуют перепроверки разработчиками и специалистами по безопасности. Антон Прокофьев подчёркивает: «Можно автоматизировать многие процессы, но за моделью придётся перепроверять: в случае критических уязвимостей риск пропуска достаточно высокий. ИИ может быть инструментом, но человека он не заменит». Дмитрий Частухин соглашается: «Код, сгенерированный LLM, однозначно не доверенный. Его нужно проверять. Это как текст: по определённым паттернам можно понять, что он сгенерирован. Так что работы у безопасников стало больше». При вайбкодинге возникает и менее очевидный риск, добавляет Дмитрий Евдокимов. Баги в сгенерированном коде — только часть проблемы. Если сотрудники перестают понимать, как код устроен изнутри и что в нём происходит, компания постепенно теряет собственную техническую экспертизу. Это может привести к снижению качества разработки и увеличению зависимости от ИИ-инструментов. В долгосрочной перспективе это ослабляет способность компании самостоятельно находить и исправлять ошибки. Для российских компаний, которые стремятся к технологическому суверенитету, такая потеря компетенций может стать стратегической угрозой, ведь без собственных специалистов невозможно ни развивать безопасные продукты, ни эффективно противостоять атакам.

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