The pentest report

Авторизация прежде всего: отчёт — это запись, а не просто результат

Всё в этом юните предполагает, что работа была авторизована: подписанный scope, rules of engagement и определённое окно — так, как фаза pre-engagement в PTES требует до отправки первого пакета. Отчёт — это место, где авторизация становится постоянной записью. Хороший отчёт повторяет scope и даты вверху именно потому, что месяцы спустя именно этот документ доказывает: ты тестировал только то, что было разрешено, и тогда, когда было разрешено. Находка без контекста scope вокруг неё — это обвинение; находка внутри чётко ограниченной работы — это доказательство. Так что отчёт — не только список багов: это артефакт, привязывающий каждое наблюдение к авторизации, сделавшей его законным, и именно эта рамка позволяет защитнику доверять ему и действовать, а не воспринимать его как угрозу.

Два читателя, один документ

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

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

Инженер — бэкенд-разработчик, SRE, security-чемпион — читает, чтобы действовать: какой обработчик, какое именно изменение, как проверить, что починено. Он будет читать глубокую техническую секцию, и для него краткость — враг; ему нужны полное воспроизведение, точный запрос, исправление корневой причины и доказательства. То, что для руководителя шум, для инженера — вся ценность отчёта.

Архитектура, обслуживающая обоих, — многослойная, а не разделённая: один документ, упорядоченный от наименее технического к наиболее. Executive summary стоит впереди и самодостаточен — читаем сам по себе при нулевой подготовке в безопасности. За ним таблица находок — мост, общий для обеих аудиторий. За ней детальные находки несут всё, что нужно инженеру. Никого не заставляют читать слой не для него, и один и тот же артефакт отвечает на оба вопроса.

Что входит в каждый слой

Executive summary — страница с наибольшим рычагом в отчёте и та, что юниоры пишут хуже всего. Это проза, а не таблица, и она отвечает на четыре вопроса в бизнес-терминах: что тестировали и когда (scope и даты, одна строка), какова общая картина риска (защитимое предложение, например «приложение хорошо построено, но один конфигурационный изъян раскрывает облачные учётки»), какие немногие вещи действительно важны (назови две-три находки, чьё влияние почувствует нетехнический читатель — «атакующий мог бы прочитать платёжные данные каждого клиента»), и какова форма работы (примерный объём, это быстрые фиксы или архитектурные). Никаких тел запросов, никаких CVSS-векторов, никакого жаргона — если умный неинженер не может по этому действовать, summary провалился.

Таблица находок — мост. Одна строка на находку, отсортированная по серьёзности, ровно столько, чтобы триажить: заголовок, серьёзность, затронутый компонент и однострочное влияние. Руководитель просматривает её, чтобы перепроверить summary; инженер просматривает её, чтобы построить очередь работ, и кликает в строки, которые его. Детальные находки за ней несут полную анатомию, которую ты научился писать, — воспроизведение с ожидаемым-против-фактического, конкретное влияние, обоснованную серьёзность, исправление корневой причины — одну самодостаточную секцию на находку. А приложения держат то, что ни одной аудитории не нужно по тексту, но обеим иногда нужно: сырые доказательства запрос/ответ, методологию и инструменты (чтобы тест был повторяемым, а покрытие — аудируемым) и точные scope и авторизацию.

Коммуникация риска без «волки-волки»

Executive summary живёт и умирает на калибровке. Два режима отказа зеркальны. Преувеличение — рисовать компетентное приложение пожаром пятой категории, чтобы выглядеть дотошно, — заставляет не доверять отчёту и сжигает отношения; реальный критикал следующего отчёта обесценится, потому что в прошлый раз всё было кризисом. Преуменьшение — смягчить единственную действительно серьёзную находку, чтобы readout ощущался спокойнее, — хуже, потому что позволяет бизнесу невольно отгрузить риск, который его кончит. Зрелый ход — честное предложение о картине, которое отделяет сигнал от шума: «приложение в целом хорошо построено; восемь low и informational находок — рутинное усиление, но один конфигурационный изъян даёт атакующему прочитать облачные учётки и должен быть исправлен до запуска». Это предложение позволяет нетехническому читателю распределить внимание правильно — что и есть вся работа summary.

Риск надо выражать в последствии, а не в механизме. Руководитель не действует по «SSRF к metadata-эндпоинту»; он действует по «атакующий мог бы получить ключи к нашему облачному аккаунту и доступ ко всем данным клиентов». Переводи каждую заглавную находку из того, что она есть, в то, что она позволяет кому-то сделать с бизнесом, и ставь число на вероятность и усилие там, где честно можешь, потому что «высокое влияние, низкое усилие на починку» — предложение, которое VP может профинансировать прямо на том совещании, где он его читает.

Как защитник читает отчёт

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