ИИ-агент и специалист: как устроена проверка Sipar

Два самых частых вопроса о проверке Sipar: «ИИ-агент будет смотреть наш код?» и «Если всё делает ИИ, насколько можно доверять результату?». В этой статье мы открыто описываем процесс от начала до конца: кто что делает, на каком этапе и в каких рамках.

Короткий ответ: ИИ-агент Claude ускоряет просмотр, а специалист подтверждает каждую находку и отвечает за исправление. Доступ предоставляется только на чтение, работа ведётся по NDA.

Зачем нужны оба

Официальная экспертиза по кибербезопасности обычно находит проблемы двух типов.

Первые — типовые, повторяющиеся: отсутствующие заголовки безопасности, устаревшие библиотеки, открытые порты, небезопасная конфигурация, оставшиеся в коде ссылки http://. Чтобы их найти, нужно быстро и последовательно просмотреть множество файлов и настроек. Здесь ИИ-агент силён.

Вторые — логические: может ли пользователь увидеть чужие данные, показывается ли страница «успешно» до подтверждения оплаты, можно ли выполнить действие в неправильном состоянии. Они требуют понимания бизнес-процесса продукта. Здесь решающую роль играет ручная проверка специалиста.

На экспертизе нашего собственного продукта встретились оба типа: наряду с типовыми находками вроде открытых портов и раскрытия информации была и ошибка бизнес-логики — страница успешной оплаты показывалась до подтверждения платежа. Поэтому наш процесс объединяет оба подхода.

Этап 1: заявка и NDA

Всё начинается с заявки: какой продукт (сайт, портал, мобильное приложение), какие технологии, к какой экспертизе вы готовитесь и какие сроки.

До начала работы подписывается соглашение о конфиденциальности (NDA) и согласуются рамки доступа:

• доступ к репозиторию только на чтение (read-only);
• при необходимости — доступ к тестовой среде;
• для мобильного приложения — файлы APK/IPA.

Доступ к production-базе данных, реальным данным пользователей или права на запись не нужны, и мы их не запрашиваем.

Этап 2: автоматический и ИИ-скан

На этом этапе автоматические инструменты и ИИ-агент Claude широко просматривают продукт:

• Код — опасные паттерны, места без проверки авторизации, оставшиеся в коде ключи и секреты;
• Конфигурация — настройки фреймворка, режим отладки, доверенные прокси и настройки хоста, в мобильном приложении — манифест и Info.plist;
• Зависимости — версии библиотек с известными уязвимостями;
• HTTP-заголовки — CSP, HSTS, X-Frame-Options и другие;
• Сервер — открытые порты, настройки TLS, лишние сервисы.

Результат — список находок, каждая привязана к категории OWASP Top 10, ASVS, MASVS или CWE. Но это ещё не итоговый отчёт. ИИ-агент иногда даёт ложные срабатывания (false positive) или неверно оценивает уровень риска. Поэтому следующий этап обязателен.

Этап 3: ручная проверка

Специалист делает две вещи.

Во-первых, подтверждает или отклоняет находки ИИ. Каждая находка перепроверяется: действительно ли она эксплуатируема, при каких условиях, каков уровень риска.

Во-вторых, вручную проверяет то, что автоматические инструменты находят плохо:

• Бизнес-логика — можно ли в процессах оплаты, заказа или подачи заявки обойти шаги или выполнить действие в неправильном состоянии;
• Авторизация — может ли обычный пользователь получить доступ к функциям администратора;
• IDOR — можно ли, изменив идентификатор в запросе, получить данные другого пользователя;
• Загрузка файлов — правильно ли ограничены тип, размер и место хранения файла, может ли загруженный файл быть исполнен.

Этап 4: исправление

После подтверждения находок наступает этап их закрытия. Есть два удобных для клиента формата:

• Патч или pull request — мы готовим исправление, ваша команда его просматривает и принимает. Код остаётся под вашим контролем, напрямую мы ничего не меняем.
• Инструкция — если внутренняя команда предпочитает менять код сама, для каждой находки даётся точное указание: какой файл, какая настройка и почему.

Серверные настройки (firewall, закрытие портов, перенос панели управления за список разрешённых IP) обычно даются в виде инструкции и выполняются вашим администратором.

Этап 5: повторный скан и отчёт о готовности

После внесения исправлений проверки этапов 2 и 3 проводятся повторно: действительно ли находка закрыта и не создало ли исправление новую проблему.

В итоге выдаётся отчёт о готовности: что найдено, что закрыто, что осталось (если осталось) и почему. Для мобильного приложения в отчёт входят и практические детали, например сдаваемый файл и его контрольные суммы.

Отчёт о готовности — не официальный сертификат. Сертификат или заключение выдаёт только официальная экспертиза. Мы готовим к ней ваш продукт и заранее закрываем известные уязвимости.

Границы этого подхода

О чём нужно сказать прямо:

• ИИ ускоряет просмотр, но не заменяет специалиста. Каждая находка подтверждается человеком.
• Никакая проверка не гарантирует обнаружения всех уязвимостей. Мы работаем по стандартам, которые проверяет экспертиза (OWASP, ASVS, MASVS), и стремимся последовательно их охватить.
• Доступ только на чтение и по NDA. Ваши данные не выходят за согласованные рамки.

Сканирование

Хотите увидеть процесс на своём продукте? Оставьте заявку на сканирование. На первом этапе мы оценим общее состояние продукта и подскажем, на какие направления обратить внимание до экспертизы.