RuStore внедрил AI в ИБ: как VK автоматизирует ревью задач, кода и DAST-проверки

RuStore показал прагматичный сценарий использования AI в информационной безопасности: не для красивой витрины и не для замены специалистов, а для разгрузки самых повторяющихся этапов работы внутри релизного цикла. Команда ИБ вынесла на автоматизацию три зоны, где инженер чаще всего тратит время на базовый разбор и фильтрацию: первичную обработку Security Check-задач, просмотр изменений в merge request и динамическое тестирование приложений. Логика простая: если машина умеет быстро собрать контекст, подсветить типовые риски и отсеять очевидные проблемы, у человека остается больше ресурса на действительно сложные решения, спорные кейсы и глубокий анализ архитектуры.

Это важный сдвиг в самом подходе к прикладной безопасности. В продуктовой разработке ИБ давно состоит не только из редких критических инцидентов и охоты за изощренными атаками. Большая часть нагрузки — это постоянная операционка: нужно читать постановки задач, смотреть, что именно меняется в функциональности, понимать, какие данные затрагиваются, какие интеграции появляются и где могут возникнуть уязвимости по уже известным шаблонам.

Такая работа обязательна, но именно она съедает часы экспертов. Масштабировать команду под этот поток не всегда рационально: вместе с числом специалистов растет и объем рутины, а не только глубина экспертизы. Поэтому ставка на AI здесь выглядит не модным экспериментом, а попыткой точечно перераспределить время внутри команды.

Первое направление — разбор Security Check-задач на раннем этапе. Обычно инженеру нужно быстро понять, о каком изменении идет речь, где потенциально затрагивается безопасность и насколько вообще нужен углубленный анализ. AI в таком процессе может собрать базовый контекст по постановке, выделить чувствительные участки и заранее подсветить то, что похоже на известные риск-паттерны.

Это особенно полезно там, где поток задач высокий, а значительная часть обращений в итоге требует не полноценного расследования, а быстрой квалификации и маршрутизации. Второе направление — анализ кода в merge request. Здесь особенно много однотипных проверок: работа с пользовательским вводом, доступами, токенами, секретами, логированием, валидацией, внешними вызовами.

Если модель умеет проходить по этим слоям как по чек-листу, она становится не «ревьюером вместо человека», а первым фильтром перед экспертной оценкой. Третья зона — AI-DAST, то есть использование модели в динамическом тестировании приложений. Для команды безопасности это логичное продолжение той же идеи: часть проверок можно стандартизировать, ускорить и запускать более последовательно, не дожидаясь, пока у инженера появится окно на ручной проход по типовым сценариям.

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

На уровне рынка это хороший пример того, как AI постепенно встраивается в зрелые внутренние процессы. Самая практичная ценность здесь не в громких обещаниях «автономной безопасности», а в снижении стоимости рутины и ускорении первичной проверки без потери контроля. Если такой подход закрепится, команды ИБ смогут тратить меньше времени на механическую сортировку задач и больше — на моделирование угроз, нетривиальные сценарии атак и профилактику ошибок еще до релиза.

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