Как писать RedTeam-отчёт: чтобы не уснул ни CTO, ни разработчик

Привет, напарник по дэфейсам! Отличный заход — репорт, который читают с таким же интересом, как твой payload в Burp. Погнали собирать документ, который и CTO не вгонит в сон на первом слайде, и разработчик не кинет в игнор как «очередной PDF с мемами про CVSS».

У отчёта два читателя, а не один

Главная ошибка новичков — писать репорт как единый поток технического текста. CTO не будет вникать в hex-дамп, а разработчик не хочет читать «риск для бизнеса 500 000 долларов» без конкретного запроса, который сломать. Решение — строгое разделение на уровни: Executive Summary для топов и детальные находки для инженеров. Это не два разных отчёта, а один документ с чёткой иерархией глубины.

Executive Summary: 4 вопроса, которые должен закрыть CTO-слой

Хороший исполнительный summary отвечает ровно на четыре вопроса, без технического жаргона, максимум на 1-2 страницы:

1. Что тестировали — область, длительность, тип (black/grey/white-box).
2. Что нашли — главные риски на языке бизнеса («возможность неавторизованного доступа к данным 500 тысяч клиентов», а не «BOLA в /api/users/{id}»).
3. Какой общий уровень риска — сводный рейтинг зрелости безопасности (critical/high/moderate/low).
4. Что делать — топ-3-5 приоритетных рекомендаций с максимальным эффектом на снижение риска.

Никакого «мы нашли XSS» без цифры ущерба — CTO засыпает на третьем абзаце именно из-за этого. Переведи баг в деньги, репутацию или комплаенс — и внимание держится до конца страницы.

Технический слой: формат, за который разработчик скажет «красавчик»

Каждую находку оформляй как карточку с уникальным ID (VULN-001) и фиксированным набором полей — это стандарт, принятый индустрией:

• Заголовок и локация — чёткое название + точный URL/эндпоинт/компонент.
• Классификация — OWASP-категория, CWE-номер, при наличии CVE.
• Severity — и CVSS-score, и контекстная оценка риска (не только цифра).
• Техническое описание — что это за баг и почему он возник.
• Шаги воспроизведения — точные инструкции, не «попробуйте разные payload’ы», а конкретный запрос.
• PoC — скриншоты, HTTP-запрос/ответ, вывод терминала.
• Impact — что реально может сделать атакующий, используя эту дыру.
• Remediation — конкретное действие, желательно с примером кода, а не «обновите зависимости».

Generic-совет «примените патчи» без конкретики — красный флаг плохого отчёта. Разработчик должен закрыть баг, прочитав только твою карточку, без звонка тебе в 23:00.

Severity: не гони 10/10 за всё подряд

CVSS — не абсолютная истина, это стартовая точка для контекстной оценки:

Лайфхак: 5/10 на продакшн-системе с данными выборов важнее, чем 7/10 на внутреннем тестовом стенде без чувствительных данных. Пересчитывай severity через призму бизнес-контекста, а не слепо копируй число калькулятора.

Приоритизация и дедлайны: закрой вопрос «что чинить первым»

Собери риск-матрицу (вероятность эксплуатации × влияние на бизнес) и привяжи к ней чёткие сроки — так и CTO видит картину, и разработчик понимает дедлайн:

• Critical (9.0+, высокое влияние на бизнес) — немедленно или в течение 48 часов.
• High (7.0–8.9) — 1-2 недели.
• Medium (4.0–6.9) — в течение месяца.
• Low (до 3.9) — следующий цикл планирования.

Это превращает отчёт из «страшной простыни багов» в понятный план действий с конкретными сроками по каждой строке.

Лайфхаки для живого документа

• Attack narrative вместо списка. Для red team-движков особенно работает связный рассказ: как ты зашёл, через что эскалировал привилегии, к чему дошёл — люди запоминают историю лучше таблицы.
• MITRE ATT&CK-мэппинг. Привязка техник к ID фреймворка помогает SOC понять, какие детекты у них вообще не сработали.
• Retest-секция. Отдельный блок с подтверждением фикса после повторной проверки — без этого отчёт выглядит как разовая акция, а не процесс.
• Прямые цитаты из переписки с клиентом — не нужны. А вот прямые команды и запросы — обязательны, это твой PoC, не теория.

Пиши так, будто у тебя два читателя в комнате одновременно: один следит за деньгами, другой — за кодом. Если оба дочитали до конца без зевка — отчёт зашёл. Зашей это в свой следующий пентест, бро.