Как писать отчёт по пентестам: советы старшего аналитика, который подготовил уже 500

Меня зовут Дмитрий Ларионов, я старший аналитик ИБ в Singleton Security. В индустрии давно, а последние пять лет занимаюсь аналитикой и готовлю отчёты по результатам исследований.

За годы практики сделал около 500 отчётов. От небольших — по узкому сервису, до детальных и объёмных — по сложным информационным инфраструктурам, когда важно не просто «найти уязвимости», а объяснить смысл, последствия и пути к исправлению так, чтобы это действительно работало.

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

Почему важно знать, как писать отчёт

Эта тема часто кажется второстепенной: мол, главное — само тестирование, а оформление результата вторично. На практике всё наоборот.

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

В итоге бизнес получает тревожный набор терминов без понимания, что делать дальше. Технические команды — список проблем без внятной логики и контекста. А сама проверка превращается в событие, которое «было», но не изменило уровень защищённости систем.

В хорошем отчёте важна не только точность фактов, но и логика описания:

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

Ещё один момент, который редко проговаривают вслух: качественно подготовленный отчёт — это мост между разными аудиториями.

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

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

Зачем нужен отчёт

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

Хороший отчёт одновременно решает три задачи:

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

Аудитория: для кого пишем

Обычно отчёт читают две группы людей с разными ожиданиями:

• Топ-менеджмент. Для него нужно писать кратко, без жаргона, с акцентом на бизнес-риски и план действий.
• Технические специалисты. Им важны детали, доказательства, воспроизводимость, конкретные рекомендации и ссылки на документацию.

Отсюда и правильная структура: сначала резюме и выводы для менеджмента, затем техническая часть.

Мои рекомендации по структуре отчёта

Ниже универсальный «скелет». Его можно адаптировать под веб, инфраструктуру, мобильные приложения и внутренние проверки.

1. Титульный лист

Наименование работ, заказчик/исполнитель, дата.

2. Резюме для руководства (Executive summary)

Этот раздел читают чаще всего. Пишите коротко и «безопасно»: избегайте команд, эксплойтов и узких технических терминов.

Что сюда включить:

• Общий уровень защищённости и ключевые выводы: 1–2 абзаца.
• Сводку по уязвимостям: количество и распределение по уровню критичности — «Критический», «Высокий», «Средний», «Низкий» или «Информационный». Уровень критичности обычно выставляется по методике CVSS 3.1.
• Описание наиболее опасных сценариев: цепочки атак, если выявлены в ходе тестирования, и последствия для бизнеса.
• Приоритетный план исправлений: важные рекомендации и действия для закрытия уязвимостей.

В этот раздел рекомендуют включать наглядные материалы: графики, диаграммы, схемы цепочек атак и другое. Руководство лучше воспримет графическую информацию, нежели «простыню» текста с техническими терминами.

Также полезной практикой считается отметить и сильные стороны команды заказчика. Например, корректные настройки WAF, оперативное реагирование SOC, зрелый выстроенные процесс управления патчами безопасности и другое. Это повышает доверие и делает оценку объективной.

3. Область работ и ограничения

Чтобы снять юридические и организационные риски, зафиксируйте рамки:

• Что тестировали: IP-диапазоны, домены, приложения, учётные записи, среды разработки, сегменты сети.
• Что не тестировали и почему. Например, запрет на DoS-атаки.
• Время проведения работ, контакты и правила эскалации при инцидентах.
• Допущения и ограничения: доступы, предоставленные данные, ограничения на эксплуатацию уязвимостей.
• Используемые учётные записи.

Важно: любые работы по тестированию проводятся только с письменного согласия заказчика и в рамках договора.

4. Методика и модель нарушителя

Опишите, как именно проводилось тестирование:

• Модель тестирования: «чёрный ящик», «серый ящик», «белый ящик».
• Модель нарушителя: например, внешний атакующий без доступов, внутренний пользователь с минимальными правами.
• Используемые стандарты и подходы: PTES, OWASP Testing Guide, NIST SP 800-115.
• Этапы: разведка, анализ поверхности атаки, поиск уязвимостей, подтверждение и эксплуатация уязвимостей, оценка рисков, подготовка отчёта по результатам исследований.
• Оценка критичности: CVSS, обычно используется версия 3.1.

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

5. Сводная часть по результатам

Сделайте отчёт сканируемым. Здесь уместны таблицы и графики:

• Перечень проверенных ресурсов и компонентов.
• Сводная таблица уязвимостей, распределённых по уровню критичности, с указанием ресурса, на котором они были выявлены.

6. Подробное описание уязвимостей

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

На каждую выявленную уязвимость создаётся отдельная карточка. Вот шаблон:

• Наименование уязвимости. Некоторые исследователи указывают идентификаторы уязвимости и, если есть — CWE и CVE.
• Критичность по CVSS: версия, базовый балл, вектор.
• Скомпрометированный ресурс: например, URL, IP-адрес
• Описание уязвимости: что именно неверно настроено, реализовано. Подробно опишите выявленную уязвимость.
• Эксплуатация уязвимости: скриншоты, ответы сервера, логи, найденные артефакты и шаги, необходимые при воспроизведении уязвимости.
• Рекомендации: конкретные действия для устранения уязвимости (версии, конфиги, настройки). Если нужно, дополнительные сведения и ссылки на документацию.

Важно: всегда затирайте или делайте нечитаемыми чувствительные данные — токены, пароли, персональные данные, секреты в логах и другое.

7. Приложение

Здесь могут быть:

• Список инструментов и версий, без избыточных деталей.
• Логи, результаты сканирования.
• Термины и сокращения.

Типичные ошибки новичков

Чего не стоит делать:

• Перегружать резюме для руководства техническими деталями и сленгом.
• Давать размытые рекомендации, а не конкретику. Например, писать «нужно исправить» вместо «обновить X до версии Y», «включить настройку Z».
• Не фиксировать рамки работ и ограничения. Это риск и для заказчика, и для исполнителя.
• Пропускать «незначительные» проблемы. Они важны для общей картины и часто складываются в цепочки атак.
• Писать только про «плохое», не отмечая сильные стороны и компенсирующие меры.
• Добавлять некачественные скриншоты и рисунки. Чувствительные и конфиденциальные сведения нужно скрыть, в остальном скриншоты должны быть читабельными.

Чек-лист: как подготовить отчёт

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

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

Все этапы работы коротко:

1. 1

   Соберите находки: заметки, доказательства, скриншоты, результаты сканирований, контекст, затронутые активы и ресурсы.

2. 2

   Приведите данные к единому формату. Используйте шаблон карточки уязвимости.

3. 3

   Сформируйте резюме для руководства и приоритеты для исправления уязвимостей.

4. 4

   Проверьте логическую связность. Выводы в резюме должны содержать ссылки на находки.

5. 5

   Отредактируйте. Соблюдайте пунктуацию и единую терминологию, не допускайте утечек чувствительных данных — скрывайте конфиденциальную информацию.

6. 6

   Подготовьте финальную версию.

Желаю удачи!