Процесс
Что такое экспертиза кибербезопасности и как к ней подготовиться
Что проверяют на официальной экспертизе кибербезопасности, как выглядит отчёт и как спокойно подготовить к ней продукт.
· 6 мин. чтения

Перед запуском веб-сайта, портала или мобильного приложения многим организациям нужно пройти официальную экспертизу кибербезопасности. Её проводят специалисты Центра кибербезопасности. Цель простая: убедиться, что продукт не оставляет данные пользователей и инфраструктуру организации открытыми для известных угроз.
В этой статье на основе собственного опыта объясняем, как устроена экспертиза, на что в ней обычно смотрят и как подготовить продукт к проверке.
Что проверяет экспертиза
Экспертиза — это независимая оценка текущего состояния продукта. Специалисты смотрят на систему глазами внешнего атакующего и фиксируют каждую найденную уязвимость в отчёте.
Для веб-приложений
На веб-сайтах и порталах обычно рассматривают:
- Уязвимости уровня приложения — проблемы из категорий OWASP Top 10 (2021): ошибки контроля доступа, инъекции, небезопасные настройки.
- Бизнес-логику — выполняются ли процессы в правильном порядке и с нужными проверками.
- Раскрытие информации — лишние внутренние данные в ответах, сообщениях об ошибках или файлах, отправляемых в браузер.
- Сервер и сеть — открытые в интернет порты, ненужные сервисы, доступ к панелям управления.
- Транспортную безопасность — HTTPS, настройки TLS и заголовки безопасности.
Для мобильных приложений
В приложениях Android (APK) и iOS (IPA) проверка близка к направлениям OWASP MASVS и Mobile Top 10 (2024): защита бинарного файла (обнаружение root/jailbreak, защита от динамического анализа, проверка целостности), безопасное хранение данных на устройстве, корректная проверка сертификатов и сетевой трафик. Для переданных файлов также запрашивают контрольные суммы MD5, SHA1 и SHA256 — чтобы подтвердить, что проверялся именно ваш файл.
Как выглядит отчёт
Результат экспертизы — список найденных уязвимостей. Каждая находка обычно указывается с уровнем риска (высокий, средний, низкий), описанием и рекомендацией. Владелец продукта закрывает находки и подаёт продукт на повторную проверку.
На примере нашего собственного продукта — SaaS-платформы для налогов и финансов — веб-экспертиза вернула 6 находок: страница «успешной оплаты» показывалась до подтверждения от платёжного провайдера, host header injection, два случая раскрытия информации, действия без проверки состояния и открытые в интернет порты. Экспертиза мобильного приложения дала 9 находок по Android и iOS. Все были закрыты, но каждый круг занимал время.
При повторной подаче может проверяться не только исправленное место, но и весь продукт. Поэтому важно, закрывая одну находку, не добавить новую проблему: например, чтобы после добавления заголовков безопасности не сломалась часть сайта, а новая библиотека не принесла старую уязвимость.
Экспертиза — не экзамен, а независимое зеркало. Чем лучше вы к ней готовы, тем меньше кругов повторной подачи.
Подготовка: практический список
Следующие шаги полезны для любого веб- или мобильного продукта.
1. Проведите инвентаризацию
Чётко запишите, что входит в проверку: домены и поддомены, IP-адреса, API-эндпоинты, адреса админ-панелей, версии фреймворков и библиотек. Часто проблема находится на «забытом» тестовом поддомене или в старой версии API.
2. Закройте лишнее
- Неиспользуемые порты и сервисы (FTP, порт базы данных, панель сервера) должны быть закрыты из интернета.
- Панели управления должны открываться только с разрешённых IP-адресов.
- Тестовые и отладочные страницы,
phpinfo, старые резервные копии нужно удалить с сервера.
Быстро проверить сервер снаружи:
nmap -Pn -p- your-domain.uz
В результате должны остаться только нужные порты (обычно 80 и 443).
3. Проверьте режим production
Режим отладки выключен, сообщения об ошибках не показывают пользователю stack trace. В JavaScript, который уходит в браузер, нет списка внутренних маршрутов, ключей или лишней конфигурации.
4. Обновите зависимости
С помощью composer audit, npm audit и подобных инструментов найдите и обновите библиотеки с известными уязвимостями. Серверное ПО (nginx, PHP, база данных) тоже должно быть обновлено.
5. Настройте HTTPS и заголовки
HTTP-запросы перенаправляются на HTTPS, устаревшие версии TLS отключены, добавлены заголовки Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options и другие.
6. Вручную просмотрите бизнес-логику
Автоматические сканеры этого не найдут. В процессах оплаты, регистрации, восстановления пароля, смены статуса заказа проверьте, что каждый шаг валидируется на сервере. Например, статус оплаты должен опираться на подтверждающий запрос провайдера, а не на URL, по которому вернулся пользователь.
7. Отдельно для мобильного приложения
Собирайте release-сборку с обфускацией, добавьте обнаружение root/jailbreak и certificate pinning, храните секреты в Keystore/Keychain, отключите cleartext-трафик. Заранее посчитайте контрольные суммы для APK и IPA:
sha256sum app-release.apk
8. Ответственный и документация
Назначьте одного технического ответственного за общение с экспертизой. Коротко записывайте каждое исправление: что нашли, что изменили, как проверили. При повторной подаче это заметно экономит время.
Итог
Экспертиза независимо проверяет уровень безопасности продукта, и это полезный процесс. Подготовиться к ней — значит заранее самим найти и закрыть дыры, которые могут быть обнаружены. Тогда проверка завершится за меньшее число кругов, и команда быстрее вернётся к основной работе.
Хотите узнать, насколько ваш продукт готов к экспертизе? Оставьте заявку на сканирование — Claude AI агент и наш специалист посмотрят основные уязвимости и подскажут, с чего начать.


