Что такое пентест простыми словами: что заказывать, чего ждать, как проверить отчёт

Зачем заказчику разбираться в тонкостях пентеста

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

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

В чём разница между пентестом и сканированием уязвимостей

Это первое, на чём подрядчики зарабатывают на путанице терминологии. Сканирование уязвимостей это автоматическая проверка вашей инфраструктуры на наличие известных проблем по базе CVE. Запускается сканер, проходит по портам и сервисам, выдаёт список найденных уязвимостей с CVSS-баллами. Стоит относительно недорого, занимает часы или дни, выполняется регулярно. Это полезная гигиеническая процедура, но это не пентест.

Пентест это попытка реально пробить вашу защиту с использованием тех же тактик, которые применяют злоумышленники. Сканер тоже используется на старте, потому что глупо игнорировать автоматизированный охват. Дальше работает специалист, который анализирует найденное, ищет цепочки эксплуатации, пробует обходы средств защиты, тестирует логические уязвимости в приложениях, эксплуатирует социальную инженерию если это в скоупе. Результатом является не список технических находок, а описание реальных сценариев компрометации с шагами воспроизведения.

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

Какие бывают типы пентестов

В зависимости от объёма информации, которую заказчик предоставляет исполнителю, выделяют три модели работы. Black box означает, что исполнитель получает только название компании и должен сам найти всю инфраструктуру, идентифицировать сервисы и эксплуатировать уязвимости. Это максимально близко к реальной атаке внешнего злоумышленника, но требует большего времени на разведку. Gray box добавляет частичную информацию: список IP-адресов, доменов, иногда учётные записи с минимальными правами. Это самая распространённая модель, потому что она экономит время на разведке и позволяет глубже работать с найденными активами. White box даёт исполнителю полный доступ к документации, исходному коду, схемам сетей. Это эффективно для глубокой проверки конкретного приложения или системы, но дальше от модели реальной атаки.

По периметру тестирования различают внешний пентест, внутренний пентест, пентест веб-приложений, пентест мобильных приложений, пентест Wi-Fi сетей, пентест облачной инфраструктуры. Каждый тип требует разного набора инструментов и компетенций. Команда, которая отлично делает внешний пентест корпоративной инфраструктуры, может не справиться с пентестом мобильного приложения, потому что это другой стек технологий и другие классы уязвимостей.

Как составить техническое задание

Тут заказчики чаще всего совершают одну из двух ошибок. Либо ставят слишком общую задачу "проверьте нашу безопасность", либо наоборот описывают детали с такой точностью, что у подрядчика не остаётся пространства для творческих атак. Хорошее ТЗ находится посередине.

В минимальном виде ТЗ на пентест должно содержать следующие позиции. Цели тестирования: что именно вы хотите узнать. Найти все уязвимости. Проверить устойчивость к конкретному классу атак. Подтвердить эффективность определённых средств защиты. Объём работ: какие IP-диапазоны, домены, приложения, учётные записи входят в скоуп. Что строго исключено из скоупа. Модель доступа: black, gray или white box. Какие учётные данные предоставляются. Какие данные исполнитель должен искать сам. Ограничения по времени проведения: рабочие часы, ночные часы, выходные. Ограничения по типам атак: что разрешено, что запрещено. Например, DoS-тесты обычно запрещены в продакшн. Согласованные контактные лица с обеих сторон для оперативного взаимодействия. Требования к отчёту: формат, объём, перечень обязательных разделов. Сроки: когда начало, когда завершение, когда ретест после исправления.

В нашей практике мы видим, что компании часто пропускают пункт про ретест. Без него получается следующая ситуация. Подрядчик находит уязвимости, передаёт отчёт, заказчик исправляет проблемы, после чего нет независимой проверки, что исправления реально закрыли уязвимости. Часто оказывается, что разработчики закрыли только то, что описано в отчёте, но рядом остались такие же уязвимости в другом месте. Ретест должен быть частью контракта.

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

В России на рынке пентеста есть несколько десятков сильных команд и значительно больше компаний, которые продают сканирование под видом пентеста. Отличить их по сайту почти невозможно, потому что у всех написано примерно одно и то же. Реальная проверка происходит на этапе обсуждения технических деталей.

Несколько вопросов, которые мы рекомендуем задать потенциальному подрядчику. Какие сертификации есть у конкретных специалистов, которые будут работать на проекте. Не у компании в целом, а у поимённого состава команды. Если у вас идут OSCP, OSWE, GPEN это хороший знак. Если только сертификаты вендорских курсов это не показатель пентест-компетенций. Какие методологии применяются. PTES, OWASP Testing Guide, NIST SP 800-115 это базовые ссылки. Если подрядчик не может назвать методологию, это плохой знак. Сколько в команде специалистов, которые работают именно с вашим типом систем. Если у вас Kubernetes-инфраструктура, а в команде нет ни одного человека с опытом kubectl и kube-bench, проект пройдёт поверхностно. Покажите примеры обезличенных отчётов из похожих проектов. Серьёзная команда без проблем покажет вам структуру и качество отчётов, удалив идентификаторы клиента. Если отчётов нет, либо они выглядят как формальный документ, это повод задуматься.

Цена тоже сигнал, и в обе стороны. Слишком дешёвое предложение в среднем сегменте чаще всего означает автоматизированное сканирование с минимальной ручной работой. Слишком дорогое не гарантирует качество, иногда это просто маркетинговая надбавка крупного бренда. Здравый диапазон для среднего корпоративного пентеста в 2026 году в России это от семисот тысяч до двух с половиной миллионов рублей в зависимости от объёма и глубины.

Что должно быть в качественном отчёте

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

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

Описание методологии с указанием используемых стандартов и инструментов. Период проведения работ. Состав команды с указанием квалификации. Скоуп и ограничения. Все эти данные нужны для повторяемости и для аудита самого процесса.

Детальное описание найденных уязвимостей, отсортированных по уровню критичности. Для каждой уязвимости должно быть указано следующее. Тип уязвимости и ссылка на классификацию (CVE, CWE). Затронутые системы. Шаги воспроизведения с скриншотами или текстом запросов. Доказательства эксплуатации, которые показывают реальное влияние. Оценка критичности с обоснованием. Рекомендации по устранению с конкретными техническими шагами.

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

Рекомендации по улучшению процессов, не только технических уязвимостей. Например, отсутствие процесса инвентаризации активов, недостаток сегментации сети, слабый контроль доступа. Эти рекомендации часто имеют большее долгосрочное значение, чем закрытие конкретных дыр.

Приложения с техническими данными: скриншоты, выгрузки запросов, использованные инструменты, временная шкала проведения работ. Эти приложения нужны вашим инженерам для глубокой работы с находками.

Красные флаги в отчёте

Есть несколько признаков, которые говорят о некачественной работе подрядчика, и которые легко распознать.

Первый признак: в отчёте только результат сканирования. Список CVE, скопированные описания из публичных баз, нет шагов реальной эксплуатации, нет цепочек атак. Это чистое сканирование, выданное за пентест.

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

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

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

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

Что делать с отчётом после получения

Получение отчёта это не финал, это только середина процесса. Дальше начинается самая важная часть, в которой ценность пентеста реализуется или теряется.

Первый шаг: классификация находок по бизнес-приоритету. CVSS-оценка от подрядчика это техническая характеристика, но критичность для вашего бизнеса может отличаться. Уязвимость в публичном API критичнее, чем уязвимость во внутренней админке, доступной только из VPN. Соберите команду из ИТ, ИБ и владельцев бизнес-процессов, и пройдитесь по всем находкам, определяя реальный приоритет.

Второй шаг: назначение ответственных и сроков. Каждая уязвимость должна иметь владельца, который отвечает за её устранение, и зафиксированный срок. Для критических находок срок обычно не более двух недель, для средних до двух месяцев, для низкокритичных до полугода. Без сроков уязвимости висят в трекере годами.

Третий шаг: исправление и тестирование. Разработчики и администраторы исправляют найденные проблемы. Важно проверять каждое исправление в тестовой среде, прежде чем накатывать в продакшн. Часто фикс одной уязвимости создаёт другую.

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

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

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

Когда пентест точно нужен прямо сейчас

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

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

Что делать дальше

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