Работа ИБ в продуктовой разработке — это не только поиск сложных уязвимостей и редких атакующих сценариев. Значительная её часть состоит из регулярной операционной нагрузки: нужно разбирать новые задачи, смотреть изменения в коде, проверять релизы, собирать контекст и вовремя замечать потенциальные риски.
Именно на этом уровне возникает основной объём рутины. Инженер по безопасности снова и снова выполняет одни и те же базовые действия: читает постановку, анализирует контекст, проверяет типовые паттерны, отсеивает очевидные проблемы. Эта работа необходима, но она отнимает кучу времени, которое должно уходить на более сложный анализ и принятие решений.
Увеличивать команду ради такой нагрузки — не всегда лучший путь, поскольку вместе с экспертностью масштабируется и рутина. Поэтому для нас следующим логичным шагом стало использование AI — не как замены инженера, а как инструмента, который берёт на себя первичный слой проверки.
Мы посмотрели на процесс ИБ внутри релизного цикла и выделили участки с наибольшей повторяемостью. Таких точек оказалось три: первичный разбор Security Check-задач, анализ кода в merge request и динамическое тестирование приложений. Во всех этих сценариях сначала выполняется типовая работа, и только потом начинается действительно экспертная часть.
Именно этот слой мы и решили автоматизировать тремя практическими инструментами:
-
сервис для первичного ревью Security Check-задач, который помогает быстрее обрабатывать входящий поток и выделять потенциальные риски;
-
AI Code Review, встроенный в процесс проверки кода и помогающий находить типовые уязвимости и ошибки;
-
AI DAST — мультиагентная система для автоматизации динамического тестирования, которая работает как «робот-пентестер» на уровне junior-специалиста.
Важно уточнить, что во всех этих сценариях AI не принимает финальных решений. Он снимает рутинную нагрузку, ускоряет сбор контекста и помогает инженеру быстрее переходить к тому, что действительно требует экспертизы: оценке рисков, разбору нетривиальных кейсов и выбору решений.
Ниже мы — директор по информационной безопасности Дмитрий Морев, руководитель команды продуктовой безопасности Никита Иванов и инженер по информационной безопасности RuStore Алексей Крохин — подробно расскажем, как внедряли эти инструменты, как встроили их в существующие процессы разработки и какие результаты уже получили.
Первый инструмент: AI для ревью Security Check-задач
Внутри продуктового цикла у нас есть Security Check — обязательный контур, который позволяет оценивать изменения с точки зрения безопасности ещё на стадии работы с задачей. Идея простая: любая производственная задача потенциально может повлиять на безопасность, а значит её надо хотя бы быстро и адекватно отфильтровать.
Проблема в том, что далеко не каждая задача действительно требует глубокого участия ИБ. В релизном потоке всегда много изменений, которые не несут значимого риска: правки интерфейса, изменение текстов, feature-флаги, нерелевантные технические корректировки, второстепенные рефакторинги без влияния на функциональность и доступы. Но чтобы понять, что задача нерелевантна, инженер всё равно тратит время.
Именно этот этап мы и решили автоматизировать.
Как работает сервис
Мы разработали сервис RuStore Security Check Review, который подключается к задаче после появления Merge Request и работает на стадиях от code review до ready for deploy. Он собирает контекст из нескольких источников: описание задачи, связанные артефакты, код из Merge Request, архитектурные записи, API-спецификации и другие доступные данные, которые помогают понять смысл изменений.
После этого сервис формирует два ключевых результата.
Первый — суммаризацию изменений с акцентом на безопасность. По сути, это краткий разбор того, что именно поменялось в коде и какие классы рисков здесь вообще имеют смысл. Например: есть ли изменения в логике авторизации, появляются ли новые эндпоинты, меняются ли сценарии доступа к данным, добавляются ли потенциально чувствительные операции, затрагиваются ли SQL-запросы или механизмы фильтрации.
Второй — предварительный вердикт о релевантности задачи для команды ИБ. Если по содержанию MR видно, что задача не влияет на функциональность, безопасность и модель доступа, сервис может пометить её как нерелевантную и закрыть автоматически. Если же изменения значимы, он не подменяет собой решение инженера, а наоборот помогает быстрее начать осмысленный анализ: показывает, где смотреть в первую очередь и какие риски наиболее вероятны.
Именно здесь AI даёт заметный эффект. Раньше такой первичный разбор занимал от 5 минут до часа — в зависимости от объёма изменений, качества описания и необходимости уточнять детали у разработчиков. Теперь базовый анализ происходит за секунды.
Что это дало на практике
За 4 месяца после запуска сервис обработал 2538 задач. Из них 617 были закрыты автоматически как нерелевантные для ИБ. Это дало около 24% прироста производительности только за счёт отсечения лишнего потока.
Важно уточнить: речь не идёт о том, что «нейросеть стала делать работу безопасников». Речь о другом. Команда перестала тратить ощутимую часть времени на задачи, которые изначально не требовали ручной проверки. Освободившийся ресурс ушёл туда, где он действительно нужен: на архитектурный анализ, на новые интеграции, на спорные изменения, на более глубокую проработку сложных кейсов.
Что было сложным
Снаружи такие истории часто выглядят слишком гладко: придумали сервис, подключили модель, всё сразу заработало. На деле, конечно, было не так.
Одна из проблем была связана не с инфраструктурой, а с качеством ответов модели. На ранних этапах мы давали ей слишком жёсткие и переусложнённые инструкции. Это привело к предсказуемому эффекту: сервис начал выдавать очень усреднённые, стерильные и малоценные ответы. Формально всё выглядело правильно, но практической пользы было мало — вместо релевантных замечаний модель стабильно возвращала «среднюю температуру по больнице».
Пришлось идти в другую сторону: не делать промпты ещё строже, а наоборот — тонко перенастроить правила, дать модели больше пространства для рассуждения и больше автономности в выборе акцентов. После этого качество заметно выросло: ответы стали менее шаблонными и гораздо лучше привязанными к конкретным изменениям.
Это вообще один из самых полезных выводов всей работы: если вы встраиваете LLM в процессы безопасности, не надо думать только в категориях «запретить всё лишнее» и «максимально закрутить промпт». Иногда переизбыток ограничений снижает качество сильнее, чем недостаток.
Что важно помнить
Security Check Review — это не автомат по принятию решений. Это инструмент предварительного анализа.
Мы регулярно смотрим, какие задачи он закрывает, проверяем его вердикты и отслеживаем, не начинает ли система ошибаться или съезжать в сторону излишней уверенности. Именно поэтому мы говорим не про «полную автоматизацию», а про калибруемый и наблюдаемый AI-контроль.
Для ИБ это принципиально. Нельзя просто увидеть красивую цифру по автозакрытию и решить, что всё теперь работает само. Любой AI-контроль требует обратной связи, периодической валидации и нормального логирования результатов.
Второй инструмент: AI Code Review как обязательный контроль в пайплайне
Следующий этап — анализ безопасности не задач, а непосредственно кода.
У команды разработки RuStore уже была собственная мультиагентная система AI Code Review, встроенная в процесс работы с Merge Request. Она использовалась для общего анализа качества кода, и мы подключились к этому контуру со своей частью — проверками безопасности. Так появился отдельный security-агент внутри AI Code Review, который анализирует изменения в каждом MR и ищет уязвимости, которые сложно или неудобно ловить классическими статическими анализаторами.
Это важное уточнение. Мы не пытались заменить SAST. Классические сканеры хороши, но у них есть предел. Они не всегда понимают бизнес-контекст, архитектурные особенности, реальные потоки авторизации и нетривиальные сценарии доступа. А для ИБ именно такие вещи часто и оказываются самыми опасными.
Какие проверки мы встроили
На базовом уровне агент анализирует код на предмет типовых проблем безопасности: корректность аутентификации и авторизации, лишняя выдача данных, настройки rate limiting, риски mass assignment, различные варианты инъекций, CORS и ограничения на формат и размер запросов и ответов.
Но ключевое направление для нас — это контроль нарушений доступа, прежде всего IDOR/ BOLA. Такие уязвимости особенно неприятны тем, что они нередко прячутся в «почти правильной» логике. Код может выглядеть аккуратно, запросы могут быть параметризованы, тесты могут проходить, но в реальности пользователь получает доступ к чужому объекту просто потому, что где-то в новой ручке забыли проверить принадлежность сущности или неверно перенесли логику авторизации при смене архитектуры.
В большом продукте, который активно развивается и рефакторится, это очень реальный риск.
Почему IDOR стал приоритетом
В какой-то момент команда RuStore начала активно переводить сервисы на новую архитектуру с gateway-подходом: внешние коммуникации и точки входа унифицировались, менялись паттерны обработки запросов, пересматривались ручки и маршрутизация.
Это было правильное архитектурное движение, но такие изменения всегда опасны с точки зрения деградации старых гарантий безопасности. Можно сохранить бизнес-логику, не сломать функциональность и всё равно незаметно потерять часть контроля доступа.
Собственно, гипотеза о таком риске подтвердилась на практике: один из багбаунти-отчётов как раз принёс IDOR с нарушением доступа между проектами в консоли разработчика. Это стало важным сигналом: подобные вещи нельзя оставлять только на постфактум-проверки и ручной анализ. Нужен обязательный контроль прямо на этапе code review.
Как это встроено в процесс
Проверки AI Code Review обязательны для запуска: без них релизная ветка не проходит дальше по пайплайну. И это уже само по себе меняет дисциплину — каждый Merge Request гарантированно проходит через AI-анализ с точки зрения безопасности.
Следующий шаг, к которому команда идёт, — не просто блокировать отсутствие проверки, а делать блокирующими сами находки. То есть если security-агент подсветил критичную проблему, MR должен останавливаться до исправления или до осознанного разбора со стороны тимлида и ответственных инженеров.
Это принципиальная разница между «полезной подсказкой» и настоящим защитным контролем.
Где пришлось дорабатывать модель
Здесь тоже не обошлось без шероховатостей.
Первая сложность была в том, что готовая модель поначалу плохо понимала контекст нашего продукта. Например, она не учитывала особенности внутренней авторизации, где часть проверок должна происходить на уровне gateway, а не в каждом внутреннем сервисе. Из-за этого на старте возникало много ложных срабатываний: модель ругалась на случаи, которые в нашей архитектуре были допустимыми.
Проблему пришлось решать не «докручиванием модели» как таковой, а адаптацией промптов и контекста. Мы начали добавлять в инструкции особенности архитектуры, включать примеры из реального проекта и постепенно переводить агент из режима «универсального ревьюера всего подряд» в режим специализированного помощника именно для наших репозиториев и наших паттернов разработки.
Вторая проблема была не технической, а организационной. Даже хороший сигнал бесполезен, если разработчики его игнорируют или читают по диагонали. На первых этапах мы видели, что часть выводов AI Code Review просто теряется в интерфейсе: замечание есть, но оно не выглядит как нечто, требующее внимания прямо сейчас.
Отсюда два вывода. Во-первых, security-сигнал должен быть встроен в реальный путь разработчика, а не жить отдельно «где-то там в логах». Во-вторых, для внутренних AI-инструментов UX тоже критичен. Если вывод перегружен, плохо структурирован или выглядит как очередная «болтовня нейросети», его начнут пропускать.
Поэтому параллельно с точностью анализа мы улучшали и форму выдачи результатов: делали вывод более читаемым, более конкретным и более пригодным для быстрого действия.
Что получили в итоге
Мы не любим рисовать искусственные метрики там, где их нельзя честно посчитать. Для security-агента внутри code review гораздо важнее другой показатель: после внедрения такого контроля мы перестали видеть повторяемые проблемы того класса, ради которого он и создавался — прежде всего нарушения контроля доступа и типовые ошибки, возникающие на фоне архитектурных изменений.
Это не значит, что система стала идеальной. Это значит, что контроль встроился в ежедневную практику и начал отрабатывать там, где раньше ошибки проскакивали до более поздних этапов.
А это для ИБ один из самых ценных эффектов: находить проблему не на багбаунти, не на пентесте после релиза и не в проде, а в моменте, когда разработчик ещё работает с MR.
Третий инструмент: AI DAST — когда агент начинает вести себя как пентестер
Если Security Check Review помогает фильтровать задачи, а AI Code Review — анализировать код, то следующая логичная ступень — динамическое тестирование безопасности.
Именно этим занимается наш AI DAST.
Решение практически готово к внедрению в продакшен, и мы уже можем поделиться MVP и рабочими сценариями. По сути, речь идёт о мультиагентной системе для динамического тестирования, которая должна дополнить классический DAST и снять одно из его главных ограничений: неспособность качественно тестировать сложные продуктовые API без живого контекста.
Почему классического DAST недостаточно
У нас уже был и есть собственный DAST-контур. Он отслеживает API-спецификации, видит изменения и запускает на соответствующие эндпоинты набор инструментов вроде Nuclei, sqlmap, ZAP и других сканеров.
Но у классического динамического анализа есть фундаментальная проблема. Чтобы эффективно тестировать реальные продуктовые ручки, недостаточно просто знать URL и метод запроса. Нужно уметь собрать валидные данные: userId, appId, companyId, токены авторизации, корректные связи между сущностями, формат параметров, допустимые последовательности вызовов. А в крупных сервисах такие данные часто нельзя получить «в один шаг».
В результате обычный DAST хорошо ловит базовые вещи, но быстро упирается в потолок, если перед ним сложный endpoint с нетривиальным контекстом.
Именно этот потолок мы и хотим пробить за счёт AI-агентов.
Что делает AI DAST
Внутри системы несколько специализированных агентов, которые работают как небольшая команда.
На вход подаются OpenAPI-спецификация и задача: какой endpoint надо протестировать и на какой класс рисков обратить внимание. Дальше в дело вступает агент, который внутри команды мы называем Request Builder Agent.
Его задача — не просто сгенерировать curl-команду, а построить валидный запрос, который действительно дойдёт до целевого endpoint и вернёт 2xx-ответ. То есть не формально «собрать строку запроса», а реально пройти путь, который проходил бы инженер или пентестер, пытаясь добраться до рабочей точки входа.
Если для запроса уже хватает данных, задача простая: агент быстро формирует корректный вызов и отдаёт его дальше в контур тестирования.
Если данных недостаточно, начинается более интересный сценарий.
Сначала подключается OpenAPI Analyzer. У него есть карта доступных сервисов и эндпоинтов, и он начинает искать, через какие API можно получить недостающие значения. Например, какие ручки позволяют узнать список приложений, связанных с пользователем, или вытащить идентификаторы нужных сущностей. По сути, он строит цепочку вспомогательных вызовов, чтобы добыть недостающий контекст.
Если этого всё ещё недостаточно, подключается Repository Analyzer. Он идёт уже в код монорепозитория, находит реализацию endpoint, прослеживает поток выполнения, понимает схему валидации параметров и смотрит, к каким таблицам и данным обращается конкретная ручка. Это даёт намного более глубокое понимание того, какие значения вообще допустимы и что нужно для успешного прохождения сценария.
Следующий уровень — Database Analyzer. Если система уже поняла, какие данные лежат в конкретной базе и в какой таблице их искать, агент может через предусмотренные механизмы получить реальные значения из dev-стендов. Не абстрактные «примерные appId», а живые идентификаторы, связанные с тестовым пользователем или, наоборот, с чужими сущностями.
Это важно, потому что анализ не ограничивается HTTP-ответом. В ряде сценариев (например, при попытках инъекций — SQL, NoSQL, command, stored XSS или race condition) внешне всё может выглядеть корректно: сервис вернёт 200 OK без явных изменений. Но при этом под капотом может произойти запись в базу или изменение данных.
Database Analyzer позволяет AI DAST проверить это напрямую:
-
появились ли ошибки или аномалии в логах БД;
-
изменились ли данные в целевых таблицах;
-
отработала ли вредоносная нагрузка асинхронно.
За счёт этого система начинает видеть слепые уязвимости, которые классические DAST-сканеры часто пропускают из-за отсутствия контекста выполнения.
И вот здесь начинается та часть, ради которой всё и затевалось.
Как это выглядит на примере IDOR
Представим endpoint вида GET /api/users/{userId}/apps/{appId}.
Задача — проверить, можно ли через него получить доступ к чужим данным.
Чтобы сделать это руками, нужно сначала понять, какие userId и appId вообще валидны, какие из них принадлежат текущему пользователю, какие — другим, как выглядит правильный токен, какие связки допустимы и как сервис себя ведёт при подстановке «своих» и «чужих» значений.
Для человека это нормальная работа пентестера. Для классического DAST — почти тупик. А для AI DAST — это как раз типовой сценарий.
Система находит способ получить «свои» данные, затем находит или извлекает из базы чужие значения, а после этого строит два набора запросов: эталонный, который должен работать, и атакующий, который не должен проходить. Если атакующий запрос возвращает успешный ответ, мы получаем полноценный сигнал о нарушении контроля доступа.
То есть AI DAST не просто запускает сканер по API. Он собирает контекст, понимает связи, строит рабочие сценарии и начинает действовать ближе к тому, как действовал бы реальный пентестер.
Настройка баланса: универсальность vs управляемость
Ключевая задача при разработке AI DAST, как и в случае с Security Check Review, — найти баланс в инструкциях для агента. Если задать их слишком жёстко, он быстро приходит к результату, но теряет гибкость и начинает хуже работать на сервисах с другой логикой. Если, наоборот, оставить слишком много свободы, агент может уходить в перебор сценариев и тратить время на неэффективный поиск.
Эта проблема становится особенно заметной, если учитывать контекст продукта: у нас разная архитектура и множество сервисов. Настраивать агента под каждый из них отдельно — нецелесообразно. Поэтому одна из ключевых целей — сделать универсальный инструмент, который можно применять без ручной доработки под конкретный сервис.
Отсюда и выбранный компромиссный подход. С одной стороны, мы оставили инструкции достаточно гибкими, чтобы агент мог самостоятельно искать точки входа и строить сценарии. С другой — ограничили его поведение через набор специализированных инструментов в MCP (Model Context Protocol). Каждый инструмент решает конкретную задачу и делает работу агента управляемой: получение и нормализация контекста, вызовы к тестовым стендам, работа с логами и аудитом, генерация и прогон payload, проверка прав доступа, воспроизведение сценариев и фиксация артефактов. За счёт этого мы не зашиваем всю логику в инструкции, а выносим её в инструменты. Это же упрощает развитие системы. Когда появляется новый тип ручной находки, мы не переписываем агента целиком, а добавляем или донастраиваем нужный MCP-инструмент и связываем его с соответствующим сценарием.
Дополнительно мы ввели этап первичного исследования. Перед запуском тестирования агент получает спецификацию API, документацию и другие источники, собирает общий контекст сервиса и сохраняет его в долговременную память. Это позволяет ему не начинать каждый раз с нуля, а опираться на уже собранное понимание.
Параллельно мы постоянно обучаем систему на реальных кейсах. Каждый уникальный баг, найденный вручную, разбираем на ретроспективе и превращаем в улучшения AI DAST: обновляем промпт-правила, добавляем новые цепочки действий для получения контекста и расширяем инструменты MCP. В результате со временем закрываем классы уязвимостей, которые раньше находились только человеком.
Что это даёт бизнесу и команде
Тут эффект шире, чем просто «ещё одна автоматизация».
Во-первых, это снижение нагрузки на небольшую команду ИБ. Базовые сценарии проверки, которые раньше занимали много времени, можно переложить на автономный инструмент.
Во-вторых, это экономия на раннем обнаружении уязвимостей. Найти проблему до релиза почти всегда дешевле, чем ловить её потом через багбаунти, внешний пентест или, тем более, через инцидент.
В-третьих, это возможность глубже покрывать то, что классический DAST не дотягивает без ручного участия. И именно здесь AI становится реальным усилителем защиты.
Что всё это меняет в работе команды ИБ
Есть банальная фраза, что «AI забирает рутину и освобождает время на интересные задачи». Она давно приелась и сама по себе мало что объясняет. На практике для ИБ важнее другая формулировка: AI забирает рутину и освобождает время на важные задачи.
Это не про то, что безопасники теперь сидят и занимаются только чем-то захватывающим. Это про то, что вместо механического просмотра сотен задач, которые не влияют на безопасность, команда может глубже смотреть новые интеграции, архитектурные изменения, нетривиальные сценарии доступа, сложные бизнес-риски и действительно опасные классы уязвимостей.
Именно так мы на это и смотрим: всё, что можно отдать условному «джуну в виде нейронки», можно и нужно отдавать. Но решение по значимым вопросам, особенно архитектурным и рискованным, всё равно остаётся за инженером.
Чему нас научило внедрение AI в процессы безопасности
За время работы над этими инструментами у нас сформировалось несколько выводов, которые, как нам кажется, полезны любой продуктовой команде.
Первый: не пытайтесь строить универсальный AI-контроль с нуля. Гораздо лучше работает другой подход — взять существующий процесс и встроить в него AI как дополнительный слой. Там, где уже есть Security Check, code review или DAST, внедрение получается намного приземлённее и эффективнее.
Второй: модели не понимают ваш продукт автоматически. Их придётся калибровать под архитектуру, паттерны авторизации, внутренние правила и реальные сценарии. Чем ближе AI-контроль к вашей предметной области, тем выше шанс, что он будет реально полезен.
Третий: слишком жёсткие инструкции могут ухудшать результат. Иногда качественный ответ появляется не тогда, когда вы максимально зарегламентировали модель, а когда дали ей достаточно контекста и достаточно свободы для осмысленного вывода.
Четвёртый: AI в безопасности нельзя оставлять без наблюдения. Нужны логи, дашборды, выборочная ручная проверка, регулярная калибровка. Если перестать смотреть на его результаты, очень быстро можно потерять доверие либо к инструменту, либо к собственному процессу.
И пятый: блокирующий контроль почти всегда полезнее рекомендательного, если речь идёт о действительно значимых рисках. Но внедрять его важно постепенно — параллельно с доработками и повышением уверенности в качестве самих проверок. Иначе даже полезные контроли могут вызвать сопротивление у разработки и бизнеса.
Вместо вывода
Сегодня вокруг AI в безопасности много крайностей. Кто-то считает, что нейросети скоро заменят половину ИБ-процессов. Кто-то, наоборот, уверен, что всё это игрушки и модный шум. Наш опыт пока говорит о более приземлённой и, как нам кажется, более полезной вещи.
AI хорошо работает там, где у команды уже есть зрелый процесс и понятная задача. Он не заменяет экспертизу, но отлично усиливает контуры, в которых раньше люди тратили слишком много времени на однотипные действия: сбор контекста, первичную фильтрацию, поиск типовых проблем, подготовку валидных сценариев для тестирования.
Именно в этом месте и появляется реальная ценность. В RuStore мы уже используем AI для ревью Security Check-задач и для анализа Merge Request’ов в пайплайне. Следующий шаг — довести до промышленного использования AI DAST и закрыть ещё один большой пласт рутинной, но дорогой по времени работы.
Главный вывод для нас очень простой: в ИБ не нужно выбирать между «делать всё руками» и «полностью довериться AI». Рабочий путь — строить инструменты, которые помогают команде быстрее видеть важное, раньше находить риски и тратить человеческую экспертизу там, где она действительно незаменима.
Автор: feynrich
