Статья Отчёт о пентесте: как составить понятный отчёт для заказчика

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

Зачем нужен отчёт и как сделать его полезным​

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

• Что было проверено?
• Какие угрозы обнаружены?
• Что делать дальше?

Для бизнеса важны риски и их последствия (потери данных, репутации, денег), для технарей — технические детали и шаги по исправлению. Успешный отчёт балансирует между этими аудиториями, избегая избыточного жаргона и сухих логов.

Структура отчёта: что включить​

Чтобы отчёт был логичным и понятным, придерживайтесь следующей структуры.

1. Краткое резюме (Executive Summary)​

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

• Цель пентеста (например, проверка веб-приложения на уязвимости).
• Ключевые находки (например, "обнаружены 3 критические уязвимости, позволяющие получить доступ к данным").
• Общий уровень риска и рекомендации в 2–3 предложениях.

Пример:

В ходе пентеста веб-приложения выявлено 5 уязвимостей, включая 2 критические (SQL-инъекция и XSS), которые могут привести к утечке данных. Рекомендуем немедленно обновить зависимости и внедрить WAF.

2. Введение и методология​

Опишите, что тестировали (приложение, сеть, API) и какие подходы использовали (например, OWASP Top 10, PTES). Укажите сроки, инструменты (Burp Suite, Nmap) и ограничения (например, запрет на DoS-атаки). Это покажет заказчику, что работа была системной.
Пример методологии:

Тестирование проводилось с 10 по 15 июля 2025 года по методологии OWASP. Использовались инструменты Burp Suite, Nikto и ручной анализ. Проверялись веб-приложение и API на SQL-инъекции, XSS, CSRF и другие уязвимости.

3. Список уязвимостей​

Сердце отчёта. Для каждой уязвимости: название, описание, критичность (по CVSS v4.0), доказательства, последствия, рекомендации.

Подробный пример для SQL-инъекции:

• Название: SQL-инъекция в поисковой форме.
• Описание: Уязвимость позволяет вводить SQL-код в поле поиска, обходя фильтры и извлекая данные из БД.
• Критичность: Высокая (CVSS: 9.8 — высокая доступность, конфиденциальность).
• Доказательства: Шаги: 1. Войти в форму поиска. 2. Ввести ' OR '1'='1; --. 3. Получить все записи пользователей.

PoC-код (Python для демонстрации):

import requests

url = "https://example.com/search"
payload = {"query": "' OR '1'='1; --"}
response = requests.post(url, data=payload)
print(response.text)  # Выводит все данные

• Последствия: Утечка ПДн, возможный доступ к админ-панели, штрафы по 152-ФЗ.
• Рекомендации: Использовать параметризованные запросы (Prepared Statements). Пример на PHP:

$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute(['name' => $input]);

Добавьте скриншоты: до и после эксплуатации.

4. Оценка рисков​

Составьте таблицу или график, показывающий критичность уязвимостей. Это помогает бизнесу понять приоритеты.

Пример таблицы:

Уязвимость	CVSS Score	Критичность	Вероятность	Рекомендации
SQL-инъекция	9.8	Высокая	Высокая	Параметризация, WAF
XSS	6.1	Средняя	Средняя	CSP, экранирование
Weak Passwords	5.3	Низкая	Низкая	Политика паролей

График: используйте инструменты вроде Tableau или даже Excel для экспорта.
В 2025 тренд — интеграция с SIEM: показывайте, как уязвимости коррелируют с логами.

5. Рекомендации и план действий​

Сформулируйте шаги по устранению уязвимостей, начиная с самых критичных. Укажите, что можно сделать быстро (low-hanging fruit), а что требует времени. Например:

• Краткосрочные: обновить библиотеки, включить заголовки безопасности.
• Долгосрочные: внедрить SIEM, обучить разработчиков безопасному коду.

Инструменты для генерации отчётов: Dradis vs Faraday​

Выбор инструмента для генерации отчётов может сэкономить время и повысить качество. Рассмотрим два популярных решения: Dradis и Faraday.

Dradis: коллаборация и кастомизация​

Dradis — это платформа для управления проектами пентеста с акцентом на совместную работу. Она помогает командам собирать данные, структурировать отчёты и экспортировать их в Word, PDF или HTML.

• Плюсы:
  • Поддержка шаблонов (OWASP, PTES).
  • Интеграция с Burp Suite, Nessus, Nmap.
  • Коллаборация в реальном времени для команд.
  • Кастомизация: добавляйте свои поля и форматы.
  • Open-source версия (Community Edition) бесплатна.
• Минусы:
  • Требует настройки (особенно для интеграций).
  • Интерфейс может быть неинтуитивным для новичков.
  • Платная версия (Pro) дорогая для фрилансеров.

Пример настройки шаблона в Dradis:

# template.yml
title: Pentest Report
sections:
  - Executive Summary
  - Methodology
  - Findings
  - Recommendations
export_format: docx

Faraday: автоматизация и аналитика​

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

• Плюсы:
  • Интеграция с 70+ инструментами (Metasploit, Qualys, OpenVAS).
  • Автоматическое объединение дубликатов уязвимостей.
  • Дашборды для визуализации рисков.
  • API для кастомных скриптов.
  • Поддержка Bug Bounty программ.
• Минусы:
  • Сложная начальная настройка.
  • Нет бесплатной версии (только trial).
  • Меньше гибкости в шаблонах по сравнению с Dradis.

Кейс: В проекте для e-commerce Faraday объединил результаты Nessus и Burp Suite, автоматически создав график рисков. Заказчик оценил наглядность, фиксы начались через 2 дня.

Пример экспорта данных в Faraday (Python API):

import faraday_api

client = faraday_api.Client("http://faraday-server:5985")
client.add_vulnerability(
    name="SQL Injection",
    severity="high",
    description="SQLi in search form",
    poc="curl -X POST --data \"query=' OR '1'='1; --\"",
    recommendation="Use prepared statements"
)

Что выбрать?​

• Dradis — Идеально для небольших проектов или фриланса.
• Faraday — для крупных пентестов с множеством инструментов и необходимостью автоматизации.
• Совет: Попробуйте Community Edition Dradis для старта. Если работаете с большими данными, протестируйте Faraday (trial доступен на 14 дней).

Как писать понятно и профессионально​

1. Минимум жаргона. Вместо "RCE позволяет выполнить произвольный код" напишите "Уязвимость позволяет хакеру запустить вредоносный код на сервере".
2. Наглядность. Используйте таблицы, графики, скриншоты. Например, график распределения уязвимостей по критичности.
3. Избегайте обвинений. Вместо "разработчики не настроили CORS" пишите "отсутствие настройки CORS создаёт риск утечки данных".
4. Краткость. Не перегружайте отчёт сырыми логами. Если нужно, вынесите их в приложение.

Частые ошибки и как их исправить​

1. Неструктурированность. Плохой отчёт — это свалка логов и терминов. Решение: следуйте структуре выше, выделяйте главное.
2. Отсутствие приоритизации. Не все уязвимости одинаково важны. Указывайте, что исправить в первую очередь.
3. Сухой технический стиль. Бизнес не поймёт отчёт, полный аббревиатур. Пишите проще, добавляйте примеры последствий.

Пример плохого описания уязвимости:

Обнаружен SQLi в /login. Ввод ' OR '1'='1 возвращает доступ.

Улучшенная версия:

В форме авторизации (/login) обнаружена SQL-инъекция. Злоумышленник может ввести специальный запрос (' OR '1'='1), чтобы обойти авторизацию и получить доступ к данным. Рекомендуем использовать параметризованные запросы.

Проверка и доработка​

Перед отправкой заказчику:

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

Пример контрольного списка:

• Все уязвимости описаны с доказательствами?
• Рекомендации конкретны и выполнимы?
• Резюме понятно для руководства?

Заключение и призыв к действию​

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

Есть свои лайфхаки по составлению отчётов? Делитесь в комментариях!

Если вы новичок и только начинаете прокладывать свой путь в ИБ, рекомендую ознакомиться с рядом статей:

1. С чего начать изучение информационной безопасности
2. Руководство для начинающего пентестера: как войти в профессию с нуля
3. Освойте пентест: Комплексный Roadmap для будущих экспертов по кибербезопасности
4. Чеклист пентестера: 15+ пунктов, чтобы не упустить ни одной уязвимости

FAQ​

1. Нужно ли включать все логи?
Нет, только ключевые. Полные логи вынесите в приложение или предоставьте по запросу.

2. Какие инструменты упрощают написание отчётов?
Dradis, Faraday, PlexTrac. Для визуализаций — Canva, Tableau. Для черновиков — AI-инструменты с ручной доработкой.

3. Можно ли использовать шаблоны?
Да, но кастомизируйте под проект. GitHub (например, pentest-report-template) — хороший старт.