Pre-audit: зачем проверять продукт самим до экспертизы

Если официальная экспертиза кибербезопасности находит уязвимости, процесс не останавливается, но затягивается: приходит отчёт, команда исправляет, продукт подаётся повторно, и снова ожидание. Каждая находка — ещё один круг. Pre-audit нужен именно для того, чтобы этих кругов стало меньше.

Что такое pre-audit

Pre-audit — внутренняя или независимая проверка, которая проводится до официальной экспертизы. Её задача — заранее найти и закрыть уязвимости, которые может обнаружить экспертиза. Pre-audit не заменяет официальную проверку и не даёт никаких официальных документов. Он готовит продукт к проверке.

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

Зачем проверять самим

Большинство находок типичны

Из нашего опыта: веб-экспертиза нашей SaaS-платформы для налогов и финансов дала 6 находок. Среди них не было сложных или редких атак. Открытые порты FTP и панели, библиотека, отправлявшая в браузер полный список маршрутов, приложение, доверявшее заголовку X-Forwarded-Host, — всё это можно было найти заранее по чек-листу.

В мобильном приложении картина похожая: нет обнаружения root и jailbreak, данные хранятся без шифрования, слабая проверка сертификата. Это требования, прямо описанные в OWASP MASVS и Mobile Top 10 (2024).

«Слепая зона» разработчика

Команда, написавшая код, знает его с точки зрения «как он должен работать». Атакующий же смотрит, «как его можно использовать иначе». Например, у нас страница «оплата прошла успешно» открывалась, даже если платёжный провайдер ещё не подтвердил оплату. Для разработчика это была просто страница возврата, для проверяющего — ошибка бизнес-логики.

Время и внимание

Каждая повторная подача отвлекает команду от основной работы: вспомнить контекст, исправить, пересобрать, подготовить документы. Закрыть все типичные проблемы за один раз гораздо дешевле, чем закрывать их частями несколько раз.

Pre-audit не облегчает экспертизу, он начинает её раньше — в удобное для вас время.

Что охватывает pre-audit

Хороший pre-audit повторяет направления, на которые смотрит экспертиза.

Веб-приложения

• Проверка по OWASP Top 10 (2021): контроль доступа, инъекции, небезопасные настройки, устаревшие компоненты.
• Бизнес-логика: оплата, регистрация, восстановление пароля, смены состояний.
• Раскрытие информации: сообщения об ошибках, ответы API, конфигурация, уходящая в браузер.
• Сервер: открытые порты, сервисы, TLS, заголовки безопасности, доступ к админ-панелям.

Мобильные приложения

• Защита бинарного файла: обнаружение root/jailbreak и эмулятора, защита от инструментов динамического анализа вроде Frida, проверка целостности, обфускация.
• Хранение данных: Keystore/Keychain, allowBackup, данные WebView.
• Сеть: certificate pinning, отключение cleartext-трафика.
• Для подачи: контрольные суммы MD5, SHA1, SHA256.

Когда начинать pre-audit

Лучшее время — когда продукт функционально готов, но ещё не подан на экспертизу. Если начать слишком рано, последующие изменения могут принести новые проблемы. Если слишком поздно, на исправления не останется времени, и команда будет работать в спешке.

На практике хорошо работает отдельный этап pre-audit в плане релиза: код «замораживается», проводится проверка, находки закрываются, затем повторная проверка и только после неё — официальная подача. Для мобильных приложений это особенно важно, потому что каждое исправление требует новой сборки, новой подписи и новых контрольных сумм.

7 проверок, с которых можно начать самим

Многое можно проверить и без найма специалиста:

1. Просканируйте сервер снаружи через nmap и убедитесь, что открыты только нужные порты.
2. Проверьте, что в production выключен режим отладки, а страница ошибки не показывает stack trace.
3. Через «Просмотр кода» и DevTools посмотрите, какие данные уходят в браузер в JavaScript: не должно быть списка маршрутов, ключей, внутренних URL.
4. Запустите composer audit или npm audit.
5. Проверьте сайт в открытых сканерах заголовков (например, Mozilla Observatory).
6. Отправьте запрос с чужим заголовком хоста и убедитесь, что этот домен не появляется в ответе:

curl -s -H "X-Forwarded-Host: example.org" https://your-domain.uz/ | grep example.org

7. Пройдите по шагам каждый процесс, где меняются оплата или состояние, и вручную измените запросы: проверяет ли сервер каждый шаг сам?

Как работает pre-audit Sipar

Мы проводим анализ вместе — Claude AI агент и специалист. Агент быстро просматривает кодовую базу, конфигурацию и настройки сервера и отмечает подозрительные места. Специалист вручную подтверждает каждую находку, отсеивает ложные срабатывания и выполняет исправление или даёт вашей команде точные инструкции.

В результате вы получаете:

• Список находок, отсортированный по уровню риска, с исправлением для каждой.
• Закрытые дыры и результат повторной проверки.
• Готовность к подаче на экспертизу: инвентаризация, контрольные суммы, журнал изменений.

Мы не гарантируем заранее результат экспертизы — это полномочие официального проверяющего. Наша задача — чтобы вы пришли туда без известных и типичных дыр.

Итог

Pre-audit — это повторение официальной проверки в то время, которым вы управляете сами. Если типичные уязвимости закрыты заранее, экспертиза завершается за меньшее число кругов, а внимание команды остаётся на продукте.

Хотите начать со своего продукта? Оставьте заявку на сканирование — мы посмотрим основные уязвимости и подскажем следующие шаги.