Оформление находок и отчёта

Три Critical-уязвимости, 37 страниц с HTTP-дампами - и через два месяца ни одного исправления. Заказчик не проигнорировал результат: executive summary не объясняло бизнес-эффект, карточки не содержали шагов воспроизведения, а рекомендации сводились к «обновить ПО». Каждая находка (finding) была технически верной, но отчёт по пентесту не помог никому принять решение. Раздел 5 OWASP Web Security Testing Guide целиком про эту проблему: как структурировать документ, описать уязвимости и применить стандартные идентификаторы компонентов. Ниже - перевод и редакционная актуализация разделов 5.1 Reporting Structure и 5.2 Vulnerability Naming Schemes с дополнениями Codeby. Все рекомендации в WSTG - ориентир, а не жёсткие правила; описанная структура лучше всего подходит для консалтинговых отчётов и может быть избыточной для внутренних проверок или bug bounty. Вне зависимости от аудитории, WSTG рекомендует шифровать готовый отчёт и передавать его по защищённому каналу, чтобы доступ имела только принимающая сторона.

Структура отчёта по пентесту: обложка и управление​

Техническая сторона оценки - половина работы. Вторая половина - понятный отчёт по результатам тестирования на проникновение, который одинаково читается и руководством, и инженерами. Качество тестирования не имеет значения, если заказчик не понимает результаты. Звучит банально, но именно на этом этапе большинство отчётов разваливаются.

Контроль версий и оглавление​

Отчёт начинается с титульной страницы, истории изменений и оглавления.

Контроль версий фиксирует каждую редакцию документа:


Оглавление отражает все разделы документа с номерами страниц.

Команда, scope и ограничения​

Перечисление участников с указанием специализации и квалификации. Scope - согласованные с заказчиком рамки работ: какие системы тестировались, какие методы разрешены, какие среды затронуты.

Ограничения - обязательная часть отчёта. Это то, что НЕ было проверено и почему:

• Области, выведенные за рамки тестирования.
• Неработающая функциональность, которую невозможно было протестировать.
• Отсутствие сотрудничества со стороны заказчика.
• Нехватка времени.
• Отсутствие доступа или учётных данных.

Продолжительность работ с датами начала и окончания.

WSTG рекомендует включить дисклеймер, но уточняет: для юридически обязывающего документа нужен юрист. Текст ниже - исключительно иллюстрация; его не следует использовать как есть, он не является юридической консультацией:

Данное тестирование является оценкой «на момент времени» (point in time). Среда могла измениться с момента проведения тестов. Нет гарантии, что все возможные проблемы безопасности были выявлены или что новые уязвимости не появились после завершения работ. Отчёт служит ориентиром и не является гарантией полного представления рисков.

Нажмите, чтобы раскрыть...

Executive summary пентеста​

Управленческое резюме - «речь для лифта» всего документа. Аудитория - руководители, принимающие бизнес-решения. Задачи раздела:

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

Резюме должно быть конструктивным. Жаргон, негативные спекуляции и сенсационные формулировки исключены. Если используются графики или диаграммы - они должны доносить мысль яснее, чем текст.

Описание уязвимостей в отчёте: сводка и карточка находки​

Раздел находок адресован техническому персоналу. Здесь вся информация, необходимая для понимания уязвимости, её воспроизведения и устранения. WSTG рекомендует логическое разделение: например, отдельные подразделы «Внешний доступ» и «Внутренний доступ». Если проводится повторная проверка (retest), имеет смысл создать подраздел со статусом ранее выявленных уязвимостей и перекрёстными ссылками с текущим тестированием.

Сводная таблица находок​

Компактный перечень всех находок с уровнем риска - для быстрого ориентирования обеих команд:

Оформление уязвимостей: шаблон карточки​

Каждая находка подкрепляется техническим доказательством (evidence) - конкретным запросом, ответом или скриншотом - и оформляется карточкой со следующими полями:

• Ref. ID - идентификатор для коммуникации между сторонами и перекрёстных ссылок внутри отчёта.
• Название уязвимости - например, «IDOR: доступ к чужим заказам».
• Вероятность эксплуатации - насколько легко использовать, существует ли рабочий exploit, какой уровень доступа необходим, какова мотивация атакующего.
• Воздействие на систему - что произойдёт при эксплуатации.
• Уровень риска - Informational, Low, Medium, High или Critical. Критерии определения каждого уровня нужно вынести в приложение, чтобы читатель понимал, как формируется оценка.
• Описание - что собой представляет уязвимость, как её эксплуатировать и какой ущерб возможен. Все потенциально чувствительные данные (пароли, персональная информация, номера карт) маскируются.
• Рекомендации по устранению уязвимостей - конкретные шаги исправления с проверяемыми критериями закрытия, возможные улучшения защиты.
• Дополнительные ресурсы - изображения, видео, ссылки на CVE, внешние руководства.

Описание должно давать инженеру достаточно информации для действия. «Обновите ПО» - антипаттерн: разработчик не знает, что именно обновить и как проверить результат.

CVSS score в отчёте. В ряде проектов требуется указание CVSS-оценки. Текущая спецификация FIRST CVSS v4.0 определяет четыре группы метрик: Base, Threat, Environmental и Supplemental. Спецификация явно указывает, что регуляторные требования, количество затронутых клиентов, финансовые потери или репутационный ущерб находятся за пределами CVSS. Эти аспекты оцениваются отдельно в рамках процесса управления рисками конкретной организации. CVSS-балл отражает техническую severity уязвимости, но не подменяет бизнес-оценку риска. Если CVSS не является обязательным требованием - его включение иногда полезно, а иногда лишь добавляет сложности отчёту.

Учебный пример: карточка IDOR в учебном приложении. Лабораторное приложение содержит два синтетических заказа. Пользователь с ролью buyer (user_id=1001) запрашивает заказ другого пользователя (order_id=2002, принадлежит user_id=1002).


Условие: аутентифицированный пользователь с ролью buyer.

Запрос (доказательство):
Фактическое поведение: сервер вернул HTTP 200 с полным содержимым заказа order_id=2002 - имя, адрес и сумма другого покупателя (в отчёте данные обезличены).

Контроль (негативный): после применения исправления тот же запрос возвращает HTTP 403 Forbidden. Разработчик воспроизводит уязвимость без доступа к реальным данным клиентов.

Бизнес-эффект: любой аутентифицированный пользователь может перебирать идентификаторы заказов и получать персональные данные других покупателей.

Рекомендуемое исправление: на стороне API реализовать проверку владельца ресурса (order.user_id == request.user_id) перед возвратом данных. Критерий закрытия: запрос чужого order_id возвращает 403.

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

Человеческие факторы и коммуникация​

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

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

• Фишинг и утечка информации. Фиксировать тексты UI, сообщения об ошибках и страницы, раскрывающие полезную для атакующего информацию: перечисление существующих аккаунтов, избыточно детальные ошибки, детали процессов восстановления.
• UX аутентификации и восстановления. Проверять процессы сброса пароля, восстановления аккаунта, резервных кодов, SMS-фоллбэка - могут ли они быть использованы злоумышленником или побуждать пользователя к небезопасным обходным путям.
• 2FA и фоллбэк-потоки. Убедиться, что второй фактор реализован безопасно (нет слабых фоллбэков) и что UX не побуждает пользователей отключать защиту.
• Экспозиция к социальной инженерии. Выявить функции и процессы (поддержка, непроверенные ссылки в профиле, общие аккаунты), которые может использовать атакующий, выдающий себя за легитимного пользователя.
• Обработка сессий и учётных данных. Долгоживущие сессии, «запомнить меня» или утечка токенов увеличивают риск в сочетании с социальной инженерией или вредоносным ПО.

Рекомендации по коммуникации. Сначала - технические контроли (rate limiting, блокировка аккаунтов, безопасный 2FA, усиленные процессы восстановления, минимальная информация в сообщениях об ошибках), потом - процессные исправления и адресное руководство для пользователей. Показывать обезличенные примеры или редактированные скриншоты, демонстрирующие проблему в пользовательском контексте. Предлагать конкретные, приоритизированные шаги устранения, по которым инженеры и продуктовые команды смогут действовать. Указывать, кто в организации должен владеть исправлением (продуктовая команда, поддержка или ИБ), и какие краткосрочные меры возможны (feature flags, временные rate limits).

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

Proof of concept и воспроизводимые артефакты​

WSTG рекомендует включать в отчёт воспроизводимые артефакты тестирования, которые помогут разработчикам верифицировать исправления:

• Команды curl, демонстрирующие уязвимый запрос.
• Proof of Concept - например, HTML-формы для CSRF.
• HAR-файлы, фиксирующие пары запрос/ответ.
• Простые скрипты автоматизации (Selenium, Puppeteer).

Артефакты позволяют разработчику быстро проверить уязвимость и провести повторную проверку после исправления.

Обязательная очистка. Согласно рекомендациям OWASP (Logging Cheat Sheet, Secrets Management Cheat Sheet), из любых артефактов - запросов, HAR-файлов, скриншотов - необходимо исключить: токены доступа, аутентификационные пароли, персональные данные (данные о здоровье, государственные идентификаторы), строки подключения к базам данных, ключи шифрования и другие первичные секреты, данные платёжных карт. Маскировка - замена на заполнители: [I]*[/I][MASKED], [REDACTED]. Если в ходе тестирования были получены учётные данные или секреты - после завершения проекта и передачи отчёта эти секреты необходимо ротировать и отозвать. Оставлять живые секреты в теле отчёта или в приложенных артефактах недопустимо.

Каждый артефакт сопровождается контекстом: роль пользователя, среда (staging/production), версия тестируемого приложения, дата и время выполнения. Доказательства хранятся в зашифрованном виде, доступ ограничен по принципу need-to-know.

Приложения к отчёту​

К отчёту можно приложить:

• Методология тестирования - какой подход использовался (OWASP WSTG, PTES, другие фреймворки).
• Объяснение уровней severity и оценки риска - критерии присвоения уровней Informational, Low, Medium, High, Critical.
• Релевантный вывод инструментов - обязательно очищенный; необработанные дампы без интерпретации не допускаются.
• Чек-листы проведённых проверок - например, чек-листы WSTG, приложенные как отдельные документы.
• Непроверенные области - что не было покрыто тестированием и почему (ссылка на ограничения из вводного раздела).
• Результаты повторной проверки - если отчёт обновляется после ретеста: статус каждой ранее выявленной находки с перекрёстными ссылками.

Схемы именования: SWID, CPE и PURL​

Когда активов становится много, нужен способ однозначно назвать каждый программный компонент - так, чтобы сканер, IDS и антивирус говорили на одном языке. Без стандартной идентификации отчёты расходятся, корреляция превращается в ручную работу, а ресурсы тратятся впустую. Раздел 5.2 WSTG описывает три основные схемы именования.

SWID - Software Identification Tag​

SWID-тег определён стандартом ISO/IEC 19770-2:2015. Стандарт был подтверждён как актуальный в 2021 году; по состоянию на 2026 год проходит систематический обзор. NIST рекомендует SWID как основную схему идентификации разработанного или установленного ПО.

Каждый SWID-тег - XML-документ из трёх групп элементов: обязательные (7 предопределённых элементов для валидного тега), необязательные (до 30 элементов для детальной информации) и расширенные (Extended - произвольные элементы создателя тега). Высокая гранулярность SWID позволяет описать не только конкретный продукт, но и его текущий статус в жизненном цикле. Из SWID можно сгенерировать CPE, но обратное преобразование невозможно.

Примеры из WSTG. Патч «ACME Roadrunner Service Pack 1» описывается XML-тегом SoftwareIdentity с атрибутами name, tagId, patch="true", version, элементами Entity (создатель и роль) и Link (ссылка на патчируемый продукт через swid:com.acme.rms-ce-v4-1-5-0). Red Hat Enterprise Linux 8 для x86-64 использует versionScheme="multipartnumeric" и media="(OS:linux)".

CPE - Common Platform Enumeration​

CPE - схема структурированного именования для ИТ-систем, ПО и пакетов, поддерживаемая NVD. Текущая опубликованная версия - CPE 2.3. CPE считается устаревающей схемой, вытесняемой SWID, но по-прежнему широко используется. CPE часто применяется совместно с идентификаторами CVE (например, CVE-2017-0147).

Структура кода CPE: cpe:part:vendor:product:version:update:edition:lang, где part принимает значения h (hardware), o (operating system) или a (application).

Примеры из WSTG. Microsoft Internet Explorer 8.0.6001 Beta: cpe:/a:microsoft:internet_explorer:8.0.6001:beta. Foo\Bar Big$Money Manager 2010 Special Edition для iPod Touch 80GB: cpe:/a:foo%5cbar:big%24money_manager_2010:::~~special~ipod_touch~80gb~.

Унифицированный идентификатор пакета (Package URL)​

Унифицированный идентификатор пакета (Package URL, PURL) стандартизирует представление метаданных программных пакетов, позволяя однозначно находить пакет вне зависимости от вендора или среды. Спецификация стандартизирована Ecma International как ECMA-427.

PURL - валидная ASCII-строка по RFC 3986, состоящая из семи компонентов:

scheme:type/namespace/name@version?qualifiers#subpath

• scheme - константа pkg (обязательный).
• type - тип пакета: maven, npm, nuget, gem, pypi и т. д. (обязательный).
• namespace - префикс: владелец, groupId (необязательный).
• name - имя пакета (обязательный).
• version - версия (необязательный).
• qualifiers - ОС, архитектура, дистрибутив (необязательный).
• subpath - подпуть внутри пакета (необязательный).

Примеры из WSTG. Curl, .deb-пакет для Debian Jessie на i386: pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie. Docker-образ Apache Cassandra: pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c.

Выбор схемы и ограничения преобразования​

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

Учебный пример: инвентарь приложения. Условное учебное веб-приложение работает на Ubuntu и использует Python-пакет Flask.

• Пакет Flask идентифицируется через PURL: pkg:pypi/flask@2.3.2
• ОС Ubuntu идентифицируется через CPE: cpe:2.3:o:canonical:ubuntu_linux:22.04:[I]:[/I]:[I]:lts:[/I]:[I]:[/I]
• Где нужен SWID? Если на сервере установлено коммерческое ПО, не распространяемое через пакетный менеджер (например, проприетарный WAF) - его описывают SWID-тегом, отражающим версию, статус лицензии и жизненный цикл.

Что недостаточно. Совпадение имени пакета (наличие Flask в проекте) не доказывает наличие конкретной CVE. Чтобы связать пакет с уязвимостью, необходимо сопоставить точную версию с затронутыми версиями в записи CVE. CPE и PURL идентифицируют программный компонент, а не уязвимость.

Справочные материалы из WSTG 5.2: NISTIR 8060 (руководство по созданию SWID-тегов), NISTIR 8085 (формирование CPE-имён из SWID-тегов), ISO/IEC 19770-2:2015, Official Common Platform Enumeration (CPE) Dictionary, спецификация CPE Dictionary Version 2.3, спецификация PURL (ECMA-427). Среди известных реализаций PURL - библиотеки packageurl-go, packageurl-dotnet, packageurl-java (а также package-url-java), packageurl-python, packageurl-rust, packageurl-js.

WSTG ID, CWE, CVE и CVSS score в отчёте: разграничение​

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


WSTG ID обозначает, что именно тестировалось (сценарий проверки). CWE описывает тип слабости. CVE - конкретная зарегистрированная уязвимость в конкретном продукте и версии. CVSS - метрика технической серьёзности. CPE, PURL и SWID идентифицируют не уязвимость, а программный компонент.

Распространённая ошибка - использовать CPE или PURL как идентификатор отдельной уязвимости. Эти схемы обозначают приложение, ОС или пакет. Связь между компонентом и уязвимостью устанавливается через CVE-запись и сопоставление версий.

Справочные материалы из WSTG 5.1. Раздел References не входит в рекомендуемый формат отчёта - это дополнительные ресурсы для авторов: NIST SP 800-63 (Digital Identity Guidelines), OWASP Cheat Sheet Series (фишинг, аутентификация, предотвращение социальной инженерии), публикации SANS - «Tips for Creating a Strong Cybersecurity Assessment Report» и «Writing a Penetration Test Report», Infosec Institute - «The Art of Writing Penetration Test Reports», Dummies - «How to Structure a Pen Test Report», Rhino Security Labs - «Four Things Every Penetration Test Report Should Have».



Большинство отчётов, которые не приводят к исправлениям, проваливаются не на техническом уровне - а на уровне коммуникации. Разделение между управленческим резюме и техническим доказательством - самое важное архитектурное решение в документе: руководитель принимает бюджетное решение по executive summary, разработчик работает по карточке находки. Если оба раздела смешаны - ни одна аудитория не получает нужное.

CVSS-балл при этом часто воспринимается как абсолютная мера риска, хотя спецификация FIRST явно исключает бизнес-факторы из скоупа оценки. Ставить 9.8 и ожидать немедленной реакции руководства без объяснения финансовых последствий - значит не понимать, как работает процесс принятия решений на стороне заказчика.

Второй недооценённый момент - воспроизводимость. Карточка без контрольного результата после исправления - полработы: разработчик внёс патч, но не знает, как проверить закрытие. Тестировщик не знает, как провести ретест через месяц, если забыл записать версию и окружение. Отчёт - рабочий инструмент на полгода-год вперёд, а не демонстрация найденного. Возьмите свой последний отчёт и попробуйте по нему воспроизвести любую находку через три месяца - сразу станет понятно, чего не хватает.



Основа материала: OWASP Web Security Testing Guide (WSTG), раздел 5. Reporting, включая 5.1 Reporting Structure и 5.2 Vulnerability Naming Schemes. OWASP Foundation и авторы исходных материалов. Снимок источников: октябрь 2026 года.

Русский перевод и редакционная актуализация: Codeby. Изменения относительно оригинала: перевод на русский язык; добавлены учебные примеры (IDOR-карточка и инвентарь с PURL/CPE); актуализированы ссылки на спецификацию CVSS v4.0 (FIRST) и ECMA-427 (PURL); добавлены пояснения по маскированию чувствительных данных на основе OWASP Cheat Sheet Series (Logging Cheat Sheet, Secrets Management Cheat Sheet, User Privacy Protection Cheat Sheet); добавлен раздел о разграничении WSTG ID, CWE, CVE и CVSS.

Лицензия перевода и адаптации: CC BY-SA 4.0.

Вся серия WSTG · Предыдущая статья