← Ко всем статьям
Как писать отчёт по пентестам: советы старшего аналитика, который подготовил уже 500
Автор статьи: Дмитрий Ларионов
← Ко всем статьям
Как писать отчёт по пентестам: советы старшего аналитика, который подготовил уже 500
Автор статьи: Дмитрий Ларионов
ПРИВЕТ!
Меня зовут Дмитрий Ларионов, я старший аналитик ИБ в Singleton Security. В индустрии давно, а последние пять лет занимаюсь аналитикой и готовлю отчёты по результатам исследований.
За годы практики сделал около 500 отчётов. От небольших — по узкому сервису, до детальных и объёмных — по сложным информационным инфраструктурам, когда важно не просто «найти уязвимости», а объяснить смысл, последствия и пути к исправлению так, чтобы это действительно работало.
В статье даю практический ориентир для начинающих пентестеров и аналитиков ИБ: какую структуру отчёта выбрать, что писать для разных аудиторий и как оформлять находки, чтобы ими и правда пользовались.
Меня зовут Дмитрий Ларионов, я старший аналитик ИБ в Singleton Security. В индустрии давно, а последние пять лет занимаюсь аналитикой и готовлю отчёты по результатам исследований.
За годы практики сделал около 500 отчётов. От небольших — по узкому сервису, до детальных и объёмных — по сложным информационным инфраструктурам, когда важно не просто «найти уязвимости», а объяснить смысл, последствия и пути к исправлению так, чтобы это действительно работало.
В статье даю практический ориентир для начинающих пентестеров и аналитиков ИБ: какую структуру отчёта выбрать, что писать для разных аудиторий и как оформлять находки, чтобы ими и правда пользовались.
ПОЧЕМУ ВАЖНО ЗНАТЬ, КАК ПИСАТЬ ОТЧЁТ
Эта тема часто кажется второстепенной: мол, главное — само тестирование, а оформление результата вторично. На практике всё наоборот.
Можно идеально сделать пентест: по методологии, с качественными находками, красивыми цепочками атак и убедительными доказательствами. Но если итоговый отчёт написан без структуры, перегружен техническими терминами, противоречив в выводах или не даёт ясного понимания дальнейших действий — ценность проделанной работы заметно падает.
В итоге бизнес получает тревожный набор терминов без понимания, что делать дальше. Технические команды — список проблем без внятной логики и контекста. А сама проверка превращается в событие, которое «было», но не изменило уровень защищённости систем.
Эта тема часто кажется второстепенной: мол, главное — само тестирование, а оформление результата вторично. На практике всё наоборот.
Можно идеально сделать пентест: по методологии, с качественными находками, красивыми цепочками атак и убедительными доказательствами. Но если итоговый отчёт написан без структуры, перегружен техническими терминами, противоречив в выводах или не даёт ясного понимания дальнейших действий — ценность проделанной работы заметно падает.
В итоге бизнес получает тревожный набор терминов без понимания, что делать дальше. Технические команды — список проблем без внятной логики и контекста. А сама проверка превращается в событие, которое «было», но не изменило уровень защищённости систем.
“
Отчёт — это не просто перечень уязвимостей и скриншотов
Это документ, который фиксирует картину рисков и превращает результаты тестирования в понятный, проверяемый и управляемый список действий.
Это документ, который фиксирует картину рисков и превращает результаты тестирования в понятный, проверяемый и управляемый список действий.
В хорошем отчёте важна не только точность фактов, но и логика описания:
Ещё один момент, который редко проговаривают вслух: качественно подготовленный отчёт — это мост между разными аудиториями.
👨💼 Руководству важно понимать влияние на бизнес, вероятность и масштаб ущерба, приоритетность работ и общую динамику безопасности.
👩💻 Инженерам и администраторам нужны конкретные детали для воспроизведения и устранения: шаги, условия, артефакты, ссылки на компоненты, а также корректные рекомендации.
🕵️ Службе ИБ необходим материал, который можно встроить в процесс управления уязвимостями и рисками, а также контроль исправлений и развития защитных мер.
✅ Если отчёт сделан правильно, он соединяет эти ожидания в единый документ без «перевода с переводчиком» и потери смысла.
- Что именно проверяли.
- Какие условия и ограничения влияли на результаты.
- Насколько реалистичны сценарии атак.
- Какие уязвимости действительно приводят к существенным последствиям, а какие являются скорее «шумом» на фоне более серьёзных проблем.
- И самое главное — что нужно сделать, чтобы завтра стало безопаснее, чем сегодня.
Ещё один момент, который редко проговаривают вслух: качественно подготовленный отчёт — это мост между разными аудиториями.
👨💼 Руководству важно понимать влияние на бизнес, вероятность и масштаб ущерба, приоритетность работ и общую динамику безопасности.
👩💻 Инженерам и администраторам нужны конкретные детали для воспроизведения и устранения: шаги, условия, артефакты, ссылки на компоненты, а также корректные рекомендации.
🕵️ Службе ИБ необходим материал, который можно встроить в процесс управления уязвимостями и рисками, а также контроль исправлений и развития защитных мер.
✅ Если отчёт сделан правильно, он соединяет эти ожидания в единый документ без «перевода с переводчиком» и потери смысла.
ЗАЧЕМ НУЖЕН ОТЧЁТ
Распространённая ошибка новичков — воспринимать отчёт как «обязательную бумажную работу» после исследований. На практике это основной результат, за который платит заказчик.
Хороший отчёт одновременно решает три задачи:
Распространённая ошибка новичков — воспринимать отчёт как «обязательную бумажную работу» после исследований. На практике это основной результат, за который платит заказчик.
Хороший отчёт одновременно решает три задачи:
- Для руководства — даёт понятную картину рисков для бизнеса и приоритетов, что может произойти и что «чинить» в первую очередь.
- Для технических команд — фиксирует конкретные уязвимости, доказательства, воспроизводимые шаги и рекомендации по устранению.
- Для юридической части — документирует рамки и результаты проверки и может использоваться как официальный документ.
АУДИТОРИЯ: ДЛЯ КОГО ПИШЕМ
Обычно отчёт читают две группы людей с разными ожиданиями:
Топ-менеджмент. Для него нужно писать кратко, без жаргона, с акцентом на бизнес-риски и план действий.
Технические специалисты. Им важны детали, доказательства, воспроизводимость, конкретные рекомендации и ссылки на документацию.
Отсюда и правильная структура: сначала резюме и выводы для менеджмента, затем техническая часть.
Обычно отчёт читают две группы людей с разными ожиданиями:
Топ-менеджмент. Для него нужно писать кратко, без жаргона, с акцентом на бизнес-риски и план действий.
Технические специалисты. Им важны детали, доказательства, воспроизводимость, конкретные рекомендации и ссылки на документацию.
Отсюда и правильная структура: сначала резюме и выводы для менеджмента, затем техническая часть.
МОИ РЕКОМЕНДАЦИИ ПО СТРУКТУРЕ ОТЧЁТА
Ниже универсальный «скелет». Его можно адаптировать под веб, инфраструктуру, мобильные приложения и внутренние проверки.
1. Титульный лист. Наименование работ, заказчик/исполнитель, дата.
2. Резюме для руководства (Executive summary)
Этот раздел читают чаще всего. Пишите коротко и «безопасно»: избегайте команд, эксплойтов и узких технических терминов.
Что сюда включить:
В этот раздел рекомендуют включать наглядные материалы: графики, диаграммы, схемы цепочек атак и другое. Руководство лучше воспримет графическую информацию, нежели «простыню» текста с техническими терминами.
Также полезной практикой считается отметить и сильные стороны команды заказчика. Например, корректные настройки WAF, оперативное реагирование SOC, зрелый выстроенные процесс управления патчами безопасности и другое. Это повышает доверие и делает оценку объективной.
3. Область работ и ограничения
Чтобы снять юридические и организационные риски, зафиксируйте рамки:
Важно: любые работы по тестированию проводятся только с письменного согласия заказчика и в рамках договора.
4. Методика и модель нарушителя
Опишите, как именно проводилось тестирование:
В этот раздел рекомендую добавить схемы с описанием потенциальных действий злоумышленников. Например, как они могут реализовать вектор атак на информационную инфраструктуру заказчика.
Ниже универсальный «скелет». Его можно адаптировать под веб, инфраструктуру, мобильные приложения и внутренние проверки.
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. Подробное описание уязвимостей
Техническая часть — это ядро отчёта. Каждую уязвимость оформляйте одинаково, чтобы читателю было легко сравнивать и исправлять.
На каждую выявленную уязвимость создаётся отдельная карточка. Вот шаблон:
Сделайте отчёт сканируемым. Здесь уместны таблицы и графики:
- Перечень проверенных ресурсов и компонентов.
- Сводная таблица уязвимостей, распределённых по уровню критичности, с указанием ресурса, на котором они были выявлены.
6. Подробное описание уязвимостей
Техническая часть — это ядро отчёта. Каждую уязвимость оформляйте одинаково, чтобы читателю было легко сравнивать и исправлять.
На каждую выявленную уязвимость создаётся отдельная карточка. Вот шаблон:
- Наименование уязвимости. Некоторые исследователи указывают идентификаторы уязвимости и, если есть — CWE и CVE.
- Критичность по CVSS: версия, базовый балл, вектор.
- Скомпрометированный ресурс: например, URL, IP-адрес
- Описание уязвимости: что именно неверно настроено, реализовано. Подробно опишите выявленную уязвимость.
- Эксплуатация уязвимости: скриншоты, ответы сервера, логи, найденные артефакты и шаги, необходимые при воспроизведении уязвимости.
- Рекомендации: конкретные действия для устранения уязвимости (версии, конфиги, настройки). Если нужно, дополнительные сведения и ссылки на документацию.
Типичная структура карточки уязвимости
7. Приложение. Здесь могут быть:
- Список инструментов и версий, без избыточных деталей.
- Логи, результаты сканирования.
- Термины и сокращения.
ТИПИЧНЫЕ ОШИБКИ НОВИЧКОВ
Чего не стоит делать:
❌ Перегружать резюме для руководства техническими деталями и сленгом.
❌ Давать размытые рекомендации, а не конкретику. Например, писать «нужно исправить» вместо «обновить X до версии Y», «включить настройку Z».
❌ Не фиксировать рамки работ и ограничения. Это риск и для заказчика, и для исполнителя.
❌ Пропускать «незначительные» проблемы. Они важны для общей картины и часто складываются в цепочки атак.
❌ Писать только про «плохое», не отмечая сильные стороны и компенсирующие меры.
❌ Добавлять некачественные скриншоты и рисунки. Чувствительные и конфиденциальные сведения нужно скрыть, в остальном скриншоты должны быть читабельными.
Чего не стоит делать:
❌ Перегружать резюме для руководства техническими деталями и сленгом.
❌ Давать размытые рекомендации, а не конкретику. Например, писать «нужно исправить» вместо «обновить X до версии Y», «включить настройку Z».
❌ Не фиксировать рамки работ и ограничения. Это риск и для заказчика, и для исполнителя.
❌ Пропускать «незначительные» проблемы. Они важны для общей картины и часто складываются в цепочки атак.
❌ Писать только про «плохое», не отмечая сильные стороны и компенсирующие меры.
❌ Добавлять некачественные скриншоты и рисунки. Чувствительные и конфиденциальные сведения нужно скрыть, в остальном скриншоты должны быть читабельными.
Пример плохого скриншота: размытый текст не различить
ЧЕК-ЛИСТ: КАК ПОДГОТОВИТЬ ОТЧЁТ
Хорошо составленный отчёт по результатам пентеста — не просто перечень уязвимостей. Для заказчика это понятная дорожная карта, которая поможет повысить безопасность.
Если учитываете разные аудитории, даёте конкретные рекомендации и сохраняете объективность, документ будет полезен и руководству, и инженерам.
Все этапы работы коротко:
1. Соберите находки: заметки, доказательства, скриншоты, результаты сканирований, контекст, затронутые активы и ресурсы.
2. Приведите данные к единому формату. Используйте шаблон карточки уязвимости.
3. Сформируйте резюме для руководства и приоритеты для исправления уязвимостей.
4. Проверьте логическую связность. Выводы в резюме должны содержать ссылки на находки.
5. Отредактируйте. Соблюдайте пунктуацию и единую терминологию, не допускайте утечек чувствительных данных — скрывайте конфиденциальную информацию.
6. Подготовьте финальную версию.
👋 Желаю удачи!
Хорошо составленный отчёт по результатам пентеста — не просто перечень уязвимостей. Для заказчика это понятная дорожная карта, которая поможет повысить безопасность.
Если учитываете разные аудитории, даёте конкретные рекомендации и сохраняете объективность, документ будет полезен и руководству, и инженерам.
Все этапы работы коротко:
1. Соберите находки: заметки, доказательства, скриншоты, результаты сканирований, контекст, затронутые активы и ресурсы.
2. Приведите данные к единому формату. Используйте шаблон карточки уязвимости.
3. Сформируйте резюме для руководства и приоритеты для исправления уязвимостей.
4. Проверьте логическую связность. Выводы в резюме должны содержать ссылки на находки.
5. Отредактируйте. Соблюдайте пунктуацию и единую терминологию, не допускайте утечек чувствительных данных — скрывайте конфиденциальную информацию.
6. Подготовьте финальную версию.
👋 Желаю удачи!
и зарабатывай на знаниях прямо во время обучения
Получи востребованную профессию в ИБ
Оплачиваемые стажировки
для лучших студентов
Поможем выбрать подходящую специальность
Поддержка наставников во время и после обучения
Теория и практика от топовых экспертов из Kaspersky Lab, Positive Technologies, Bi. Zone и других лидеров отрасли