Как читать отчёт экспертизы: высокий, средний, низкий и «информационный» уровни

После экспертизы по кибербезопасности вы получаете отчёт на несколько страниц: список находок, уровень каждой и рекомендации. С первого прочтения он может показаться тяжёлым — незнакомые термины, номера CWE, ссылки на OWASP. На деле отчёт — это план работ. Если читать его правильно, становится ясно, какую проблему, когда и как закрывать.

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

Из чего состоит одна находка

Форматы отчётов бывают разными, но в каждой находке обычно есть:

• Название — краткое описание проблемы, например «Внедрение через заголовок Host» или «Не реализовано обнаружение root».
• Уровень — высокий, средний, низкий или информационный.
• Описание — в чём проблема и где она найдена: URL, параметр, экран или файл.
• Доказательство — запрос и ответ, скриншот или шаги воспроизведения.
• Влияние — что может произойти, если уязвимостью воспользуются.
• Рекомендация — направление исправления.
• Ссылки — идентификатор CWE, OWASP Top 10, пункт ASVS или MASVS.

Не пропускайте ссылки. Например, если в мобильном отчёте указаны MASWE-0097 и M7 «Insufficient Binary Protections» из OWASP Mobile Top 10 (2024), на этих страницах описано, что именно ожидает проверяющий. Это позволяет исправлять не «примерно», а в соответствии со стандартом.

Что означают уровни

Уровень — это оценка, объединяющая серьёзность уязвимости и простоту её эксплуатации. Точные критерии зависят от методики организации, проводящей экспертизу, поэтому воспринимайте описанное ниже как общий ориентир.

Высокий

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

Средний

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

Низкий

Случаи с ограниченным влиянием или опасные только в связке с другими проблемами. Например, незашифрованные ссылки http:// внутри приложения. Исправление обычно быстрое и недорогое, поэтому их разумно закрыть одновременно с остальными.

Информационный

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

Уровень определяет порядок исправлений, а не то, нужно ли исправлять. Подготовьте ответ по каждому пункту отчёта.

Из нашего опыта: как выглядит отчёт

Когда наш собственный продукт — налогово-финансовая SaaS-платформа — проходил экспертизу, по веб-части было 6 находок:

• страница «оплата прошла успешно» показывалась до того, как платёжный провайдер подтвердил платёж (бизнес-логика);
• внедрение через заголовок Host: приложение доверяло X-Forwarded-Host и неверно формировало абсолютные ссылки и ссылки сброса пароля;
• два раскрытия информации: браузеру передавался полный список маршрутов, а в ответах были лишние данные;
• возможность выполнить действие без проверки состояния (бизнес-логика);
• открытые из интернета порты: FTP и порты панели управления.

По мобильному приложению (Android APK и iOS IPA) было 9 находок, большинство — высокого уровня: обнаружение root и jailbreak, защита от инструментов динамического анализа (Frida и др.), проверка целостности приложения, проверка сертификата, шифрованное хранение данных. Обнаружение эмулятора было среднего уровня, ссылки http — низкого. Все 15 пунктов закрыты.

Обратите внимание: несколько веб-находок имели один корень — приложение слишком доверяло прокси-заголовкам. Поэтому группировка пунктов по первопричине экономит время.

Порядок работы с находками

1. Воспроизведите каждый пункт. Выполните шаги из доказательства в своей среде. Если вы не видите проблему, вы не сможете доказать, что исправили её.
2. Сгруппируйте по первопричине. Одна ошибка конфигурации может проявиться несколькими находками.
3. Выстройте очередь по уровню. Сначала высокий, затем средний, потом низкий и информационный. Быстрые низкие пункты закрывайте попутно.
4. Исправляйте причину, а не симптом. Например, при внедрении через Host нужно не чинить одну страницу, а ограничить доверенные прокси-заголовки для всего приложения и принудительно задать базовый URL в production.
5. Перепроверьте. После каждого исправления снова воспроизведите доказательство из отчёта и зафиксируйте, что результат изменился.
6. Подготовьте ответный документ. По каждому пункту: что сделано, какой файл или настройка изменены, как проверено. Для мобильных приложений приложите контрольные суммы MD5, SHA1 и SHA256 нового APK/IPA.

Частые ошибки

• Исправить только высокий уровень, а остальное оставить «до следующей версии».
• Выполнить рекомендацию дословно и не проверить, есть ли та же проблема в других местах.
• Исправить в тестовой среде и не включить изменения в сданную сборку.
• Вообще не читать информационные пункты.

Вывод

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

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