Код создается быстрее, а контроль становится строже: как ИИ перестраивает DevSecOps
Искусственный интеллект заметно меняет подход к безопасной разработке. Он ускоряет написание программ, автоматизирует анализ уязвимостей и помогает специалистам обрабатывать результаты проверок. Однако вместе с производительностью растет и цена ошибки: сгенерированный код может быть уникальным, но непроверенным, а встроенная в приложение модель способна стать самостоятельной точкой атаки.
Главный сдвиг последних лет связан с резким ускорением как атак, так и защитных мер. По оценкам "Солара", применение ИИ злоумышленниками сократило период от обнаружения уязвимости до ее практической эксплуатации с 63 дней в 2019 году до нескольких часов в 2025-м. Это означает, что прежние циклы согласования, ручного тестирования и выпуска исправлений больше не соответствуют реальной скорости угроз.
Ситуацию усугубляют широкое использование сторонних библиотек и распространение так называемого вайбкодинга - разработки, при которой значительная часть программного кода создается по текстовым запросам к ИИ. Сегодня в корпоративных продуктах доля внешних компонентов может достигать 90-95%. Поэтому атакующим выгоднее искать слабое место не в отдельном сервисе, а в популярной библиотеке, которую используют тысячи организаций. Одна скомпрометированная зависимость способна открыть путь сразу к множеству систем.
Генеративные модели добавляют в эту цепочку новый фактор риска. В отличие от разработчика, который обычно опирается на знакомые фреймворки и проверенные шаблоны, ИИ иногда создает собственную реализацию задачи. Такой код может выглядеть аккуратно и успешно проходить базовые тесты, но при этом не иметь истории эксплуатации, экспертной оценки и полноценного покрытия проверками безопасности.
Особенно опасно, когда результат работы модели воспринимается как надежный только потому, что он синтаксически корректен. ИИ может предложить устаревший криптографический алгоритм, небезопасную обработку ошибок, отсутствие проверки входных данных или неправильное управление правами доступа. Если разработчик принимает ответ без ревью и дополнительных тестов, проблема попадает в production вместе с новой функциональностью.
ИИ активно используется и для исследования open source. Объем открытого кода настолько велик, что люди физически не способны вручную проверить все зависимости и исправить каждую потенциальную проблему. Модели помогают находить подозрительные конструкции, классифицировать уязвимости и подбирать варианты исправлений. Но автоматическая отметка о проверке еще не означает, что анализ был полным и корректным. Если качество модели неизвестно, результат нельзя приравнивать к полноценной экспертизе.
Ускорение генерации кода приводит к росту количества артефактов, которые должна обрабатывать AppSec-команда: отчетов SAST и DAST, результатов анализа зависимостей, pull request, тестов и предупреждений от различных средств контроля. Когда скорость проверки остается прежней, образуется очередь. В итоге критичные дефекты могут затеряться среди многочисленных ложных срабатываний и второстепенных замечаний.
Отдельный вопрос - передача исходников во внешние ИИ-сервисы. Для закрытых контуров это может быть неприемлемо с точки зрения режима конфиденциальности, требований заказчиков и регуляторных ограничений. По имеющимся оценкам, исходный код составляет около 41% всей конфиденциальной информации, которая попадает в большие языковые модели. Поэтому перед использованием облачного помощника необходимо определить, какие данные разрешено отправлять за пределы инфраструктуры.
Где ИИ уже помогает AppSec
На практике ИИ подключают к большинству этапов жизненного цикла продукта. Он может помогать формировать требования, разбивать крупные задачи на подзадачи, создавать тестовые сценарии, генерировать фрагменты кода и анализировать результаты автоматических проверок.
Одно из наиболее полезных направлений - triage, то есть разбор срабатываний. Модель сопоставляет предупреждение с контекстом приложения, оценивает вероятность реальной эксплуатации и помогает отделить критичную проблему от ложного сигнала. Это снижает нагрузку на специалистов и позволяет быстрее сосредоточиться на наиболее опасных дефектах.
Еще один сценарий - code fix. ИИ предлагает исправления непосредственно в исходном коде, объясняет причину проблемы и показывает, как изменение повлияет на поведение приложения. Однако такие предложения должны проходить повторный анализ: исправление одной уязвимости не должно создавать другую или нарушать бизнес-логику.
Модели также применяют для управления зависимостями. Они помогают находить устаревшие пакеты, выбирать безопасные версии, оценивать совместимость обновлений и выявлять компоненты, которые давно не поддерживаются. Такой процесс иногда называют dependency gardening - регулярный уход за деревом зависимостей.
В решениях класса Solar appScreener ИИ-плагин встроен в статический анализ и используется для классификации находок и подготовки исправлений. Модель обучалась на данных проектов безопасной разработки более чем 1000 компаний за семь лет. Заявленная точность превышает 90% при triage и достигает 85% при подготовке исправлений. По оценке разработчиков, автоматизация способна увеличить пропускную способность AppSec-команды в десять раз.
Почему одной модели недостаточно
Наиболее надежным считается гибридный подход, в котором ИИ не заменяет традиционные средства защиты, а объединяет их результаты. Например, SCA обнаруживает уязвимую библиотеку в сервисе авторизации, SAST проверяет, используется ли опасная функция в коде, а DAST показывает, можно ли передать через интерфейс вредоносный параметр. Совместное рассмотрение этих данных дает более точную картину риска, чем отдельный инструмент.
Важна и последовательность проверок. Анализ состава программного обеспечения целесообразно выполнять уже на этапе сборки, статический анализ - до объединения изменений с основной веткой, а динамические тесты - на тестовом стенде, максимально похожем на production. ИИ может расставлять приоритеты и объяснять результаты, но качество итоговой оценки зависит от полноты исходных данных.
Нельзя полностью доверять и автоматически сгенерированным тестам. Модель часто создает сценарии для очевидных случаев, но пропускает сложные комбинации ролей, нестандартные состояния системы и ошибки в бизнес-логике. Поэтому тестирование безопасности должно включать ручные проверки, негативные сценарии, fuzzing и экспертный анализ архитектуры.
Как контролировать приложения с ИИ
Если в продукте используется собственная модель или внешний ИИ-сервис, контроль должен продолжаться после выпуска. Проверять необходимо не только исходный код, но и поведение системы во время исполнения.
К числу ключевых угроз относятся prompt injection, утечка чувствительных данных через запросы и ответы, обход ограничений, подмена контекста, чрезмерные полномочия инструментов и небезопасное выполнение действий, предложенных моделью. Например, чат-бот поддержки не должен иметь прямой доступ к базе данных без четкого ограничения операций и журналирования запросов.
Для ИИ-приложений необходимы разграничение прав, фильтрация входных данных, контроль исходящих запросов, маскирование секретов и аудит действий модели. Важно также ограничивать набор инструментов, которыми она может пользоваться: генерация ответа и выполнение платежной операции - принципиально разные уровни риска.
Что меняется в работе команд
DevSecOps-командам придется переходить от разовых проверок к постоянному контролю. Безопасность должна быть встроена в конвейер разработки, а политики - применяться автоматически. При этом разработчикам важно объяснять не только то, что код заблокирован, но и почему конкретная конструкция опасна и как ее исправить.
Полезно вводить правила для работы с ИИ: запрещать передачу секретов во внешние сервисы, маркировать сгенерированные фрагменты, требовать обязательное ревью критичных участков и хранить историю запросов, если это не противоречит внутренним политикам. Для особо чувствительных проектов разумнее использовать локальные модели или изолированные корпоративные решения.
ИИ действительно способен сделать AppSec значительно производительнее, но только при наличии процессов, метрик и человеческого контроля. Он хорошо справляется с сортировкой, поиском закономерностей и подготовкой вариантов исправлений, однако не несет ответственности за архитектуру, бизнес-риски и последствия ошибочного решения. Поэтому будущее DevSecOps - не в замене специалистов алгоритмами, а в сочетании автоматизации, проверенных инструментов и экспертной оценки.