Почему два пентеста одной системы могут стоить по-разному
изображение: grok
Компания запрашивает у нескольких подрядчиков стоимость пентеста и получает предложения, которые отличаются в разы. Один исполнитель планирует проверить приложение за несколько дней. Другой включает в проект изучение архитектуры, тестирование API, проверку нескольких пользовательских ролей и ретест после устранения уязвимостей и раздувает срок до месяца.
Разница в сроках и стоимости не всегда означает, что один подрядчик работает медленнее или оценивает свои услуги дороже. Чаще исполнители по-разному определяют периметр, глубину и содержание проверки, хотя используют одно название услуги.
Поэтому до сравнения цен необходимо установить, одинаковую ли задачу оценили подрядчики: какие объекты вошли в периметр, согласно какой модели нарушителя будет действовать команда, какие методы тестирования на проникновение будут применяться и какой результат получит заказчик.
Подрядчика по пентесту выбирают по согласованному периметру и формату проверки, квалификации команды, составу ручных и автоматизированных работ, требованиям к отчету и порядку действий после обнаружения уязвимостей. Предложения можно корректно сравнить только после приведения этих параметров к единой структуре.
Материал актуален на 2026 год
Когда компании нужен пентест
Пентест нужен, когда компании необходимо проверить, может ли нарушитель использовать уязвимости для проникновения в согласованный контур, повышения привилегий, доступа к данным или развития атаки внутри инфраструктуры.
Проведение пентеста может потребоваться перед запуском нового сервиса, после существенного изменения архитектуры, при подготовке к требованиям заказчика или тендера, после инцидента, а также для периодической проверки внешнего и внутреннего периметра.
При этом пентест не заменяет другие методы анализа защищенности. В зависимости от задачи дополнительно могут потребоваться анализ уязвимостей, проверка конфигураций, анализ исходного кода или оценка архитектуры.
Пентест — не проверка компании целиком
Тестирование на проникновение проводится в отношении заранее определенной области: приложения, API, внешнего периметра, внутренней инфраструктуры, беспроводной сети или другого согласованного контура.
Специалисты пытаются обойти механизмы защиты и проверить, можно ли использовать обнаруженные недостатки в условиях, приближенных к действиям реального нарушителя. Это отличает пентест от автоматического сканирования, которое преимущественно ищет известные технические признаки уязвимостей.
Однако результаты всегда ограничены установленным периметром. Если команда проверяла одно веб-приложение, выводы в отношении этого приложения нельзя автоматически распространить на всю инфраструктуру организации. Если из тестирования исключили мобильное приложение или часть API, эти компоненты остаются за пределами оценки.
Поэтому корректное коммерческое предложение должно начинаться не со стоимости, а с описания границ.
Если задача состоит не просто в поиске типовых уязвимостей, а в проверке реализуемых сценариев атаки, имеет смысл заранее определить модель нарушителя, границы и допустимую глубину тестирования на проникновение.
Количество адресов не показывает реальный объем
При предварительной оценке подрядчики часто запрашивают число доменов, IP-адресов, приложений, API и сетевых сегментов. Эти сведения нужны, но сами по себе мало говорят о сложности проекта.
За одним IP-адресом может находиться небольшой информационный ресурс без авторизации. За другим — платформа с личными кабинетами, административной панелью, десятками методов API, загрузкой файлов, интеграциями и несколькими типами пользователей.
Формально объектов в обоих случаях может быть поровну. Но во втором проекте потребуется проверить больше функций, ролей и вариантов взаимодействия.
По этой причине оценка только «за один IP-адрес» или «за один сайт» может оказаться слишком грубой. Она не учитывает внутреннее устройство объекта и количество сценариев, которые предстоит исследовать.
На стоимость влияет не размер компании, а поверхность атаки
Крупная компания не всегда означает большой пентест, а небольшой бизнес — маленький. Все зависит от того, что включено в область тестирования.
Организация может заказать проверку одного своего публичного сервиса, хотя внутри у нее работает большая распределенная инфраструктура. И наоборот: относительно компактная технологическая компания может заказать проверку сложной платформы с большим количеством интеграций и пользовательских ролей.
На объем работ влияет поверхность атаки — совокупность доступных компонентов, функций и интерфейсов, через которые нарушитель потенциально может воздействовать на систему.
При ее оценке учитывают объекты установленного периметра: веб-приложения, API, облачные сервисы, сервисы авторизации, интеграции и другие точки взаимодействия. Чем больше таких элементов и связей между ними, тем больше сценариев предстоит проверить.
Как выбрать исполнителя для распределенной инфраструктуры
Пентест распределенной инфраструктуры требует предварительно определить не только перечень систем, но и владельцев, ответственных лиц и технические ограничения на каждой площадке. Одинаковые по назначению системы в филиалах могут иметь разные настройки, каналы подключения и уровни доступа.
До оценки проекта необходимо согласовать:
- какие системы и площадки входят в периметр;
- кто предоставляет доступы и сопровождает проверку;
- какие работы проводятся удаленно, а какие требуют присутствия на площадке;
- в какие рабочие окна разрешено тестирование с учетом часовых поясов;
- как передаются и отзываются учетные записи;
- нужен ли единый отчет или отдельные результаты по площадкам;
- как производится уведомление о критичных уязвимостях.
Внешний пентест показывает, какие сценарии доступны со стороны публичного периметра. Внутренний пентест моделирует действия нарушителя, который уже получил доступ к корпоративной сети или действует с определенной позиции внутри инфраструктуры. Для распределенной компании эти форматы могут охватывать разные площадки и требовать отдельного согласования границ.
Почему пользовательские роли увеличивают объем проверки
Для приложения с авторизацией важно не только выяснить, можно ли войти в систему. Необходимо проверить, что пользователь способен выполнять только разрешенные ему действия.
Предположим, в сервисе есть клиент, оператор, руководитель подразделения и администратор. Для каждой роли может действовать свой набор функций и ограничений. В связи с чем нужно проверить разграничение доступа: может ли обычный пользователь получить доступ к административной функции, чужому профилю или данным другой организации.
Часть таких недостатков невозможно обнаружить одним лишь автоматическим сканером. Они проявляются в логике приложения и последовательности действий.
Поэтому две внешне похожие системы могут отличаться по времени проверки. Например, проверка сервиса без механизма разграничения ролей может занять значительно меньше времени, чем проверка сервиса с настраиваемыми ролями и полномочиями пользователей.
Black Box, Grey Box и White Box — это не уровни качества
На трудоемкость и результат влияет объем исходных данных, который получает команда.
Нельзя сказать, что White Box всегда лучше Black Box. Формат зависит от вопроса, на который компания хочет получить ответ.
Если задача — понять, насколько далеко сможет пройти внешний нарушитель без исходных сведений, подойдет Black Box. Если необходимо глубже проверить авторизацию, разграничение доступа или бизнес-логику, команде могут предоставить часть сведений и тестовые учетные записи, это соответствует подходу Grey Box. При этом внешний или внутренний характер пентеста определяется отдельно исходя из моделируемой позиции нарушителя.
Иногда форматы комбинируют: внешний периметр исследуют с минимальными исходными данными, а внутренний — с использованием учетных записей.
Глубина проверки тоже бывает разной
Формулировка «проверить сайт на уязвимости» может означать как поиск наиболее очевидных технических проблем, так и полноценное исследование бизнес-логики и возможных цепочек атак.
Уязвимость редко существует в отрыве от архитектуры. Несколько недостатков средней критичности могут последовательно привести к серьезному ущербу: сначала к компрометации учетной записи, затем к повышению привилегий и получению доступа к закрытым данным.
Проверка такой цепочки требует ручного анализа. Специалист должен не только найти недостатки, но и установить, можно ли объединить их в реализуемый сценарий.
При этом задача пентеста — подтвердить риск, а не нанести максимальный ущерб. Для демонстрации последствий обычно не требуется выгружать большой массив реальных данных, нарушать работу системы или получать доступ к учетной записи с правами администратора. Допустимую глубину необходимо определить до начала работ.
Ограничения защищают систему, но усложняют проект
Пентест является активной проверкой, поэтому стороны заранее согласовывают правила проведения работ — Rules of Engagement.
В них фиксируют область тестирования, разрешенные методы, временные окна, ограничения по нагрузке, порядок экстренной остановки и действия при обнаружении критичной уязвимости.
Чем чувствительнее система, тем строже могут быть ограничения. Например, могут быть введены ограничения в отношении времени проверки, могут быть запрещены определенные способы воздействия, а также может быть определена необходимость согласования потенциально опасных действий.
Такие ограничения снижают эксплуатационный риск, но требуют дополнительного планирования. Команда не может действовать так же свободно, как реальный нарушитель, и должна адаптировать сценарии к установленным границам.
Особенно аккуратно необходимо планировать проверку систем в продуктовой среде. Тестовая среда уменьшает часть рисков, но полезна только тогда, когда достаточно точно воспроизводит значимые свойства рабочей системы.
Подходы к планированию и проведению технических проверок подробно рассматриваются в NIST SP 800-115. Для веб-приложений одним из ориентиров может служить OWASP Web Security Testing Guide, но программа конкретного пентеста должна учитывать архитектуру и функции исследуемого объекта.
Каким должен быть результат пентеста
Иногда предложения сравнивают по количеству часов технического тестирования, не учитывая требования к результатам. Но после завершения проекта компании нужен не просто список найденных проблем.
Техническая команда должна понимать, где обнаружена уязвимость, при каких условиях она воспроизводится и как ее устранить. Руководству требуется другая картина: какие сценарии наиболее опасны, на какие процессы они влияют и что следует исправлять в первую очередь.
Качественный отчет обычно включает:
- область, сроки и ограничения тестирования;
- использованную модель нарушителя;
- подтвержденные уязвимости и доказательства;
- возможные сценарии и последствия;
- оценку критичности уязвимостей и, при необходимости, их приоритет для конкретной организации;
- рекомендации по устранению;
- описание выявленных цепочек атак;
- ограничения, повлиявшие на полноту результатов.
Уязвимости могут оцениваться, например, по CVSS. Но числовой балл CVSS не следует рассматривать как готовую оценку риска для организации. Он характеризует техническую серьезность уязвимости с учетом установленных метрик, тогда как при определении приоритета исправления необходимо дополнительно учитывать контекст конкретной системы, актуальность угроз, критичность актива и возможные последствия для бизнеса.
Б-152 проводит пентесты внешнего и внутреннего периметра в форматах Black Box, Grey Box и White Box. Периметр, модель нарушителя, ограничения и требования к результатам фиксируются до начала технических работ.
Ретест не всегда входит в первоначальную оценку
После устранения уязвимостей проводится повторная проверка — ретест. Он нужен, чтобы подтвердить, что ранее выявленная проблема действительно устранена и исходный сценарий больше не воспроизводится в согласованном объеме повторной проверки.
Ретест обычно не равен новому полному пентесту. Он сосредоточен на ранее выявленных недостатках. Но еще до начала проекта стоит согласовать, включена ли такая проверка в предложение, сколько циклов предусмотрено и в какой срок она может быть проведена.
Если одно предложение включает ретест и помощь с разбором результатов, а другое заканчивается передачей первичного отчета, сравнивать их только по цене некорректно.
Срочность может увеличить трудоемкость организации
На календарный срок влияют не только технические работы. До начала тестирования нужно организовать доступ, подготовить тестовые учетные записи, уточнить контакты ответственных лиц и согласовать правила.
Если результат требуется срочно, подрядчику может понадобиться расширенная команда и параллельное выполнение отдельных этапов. Но ускорить можно не все: сложную бизнес-логику и цепочки атак по-прежнему придется анализировать последовательно.
Бывает и обратная ситуация: технический объем небольшой, но проект растягивается из-за задержек с предоставлением доступов или согласованием безопасных действий. Поэтому в предложении стоит разделять трудоемкость и календарную продолжительность.
Чек-лист для выбора подрядчика по пентесту
Разброс цен становится понятнее, если привести предложения к единой структуре.
До запроса оценки компании полезно подготовить краткое описание:
- какие приложения, адреса, API и сегменты требуется проверить;
- какие пользовательские роли существуют;
- есть ли тестовая среда;
- какие функции и данные считаются критичными;
- какая модель нарушителя интересует заказчика;
- какие действия запрещены;
- насколько подробным должен быть отчет;
- требуется ли ретест.
После этого предложения можно сравнивать по одинаковым параметрам.
Особое внимание стоит обратить на ручные проверки. Автоматические инструменты полезны для поиска типовых проблем, но не заменяют анализ бизнес-логики, разграничения прав и сложных цепочек воздействия.
Нужно также выяснить, как подрядчик валидирует находки сканеров, как сообщает о критических уязвимостях и что делает с полученными во время проверки данными.
До заключения договора также стоит уточнить квалификацию специалистов, применяемую методику тестирования на проникновение, порядок защиты полученных доступов и данных, состав отчета и условия проведения ретеста.
Что в действительности покупает заказчик
Компания платит не за количество запущенных инструментов и не за максимально длинный перечень найденных недостатков.
Результат пентеста — подтвержденное понимание того, какие сценарии атаки доступны в согласованном контуре, к каким последствиям они могут привести и что необходимо изменить, чтобы закрыть выявленные возможности.
Поэтому два пентеста одной системы могут стоить по-разному и при этом оба предложения будут обоснованными. Вопрос в том, одинаковую ли задачу решают исполнители.
Перед выбором подрядчика стоит уточнить четыре вещи: что именно проверяется, согласно какой модели нарушителя, с какой глубиной и какой результат должен остаться после завершения работ. Пока эти параметры не определены, любая цена остается предварительной.
Частые вопросы о пентесте
Почему стоимость пентеста у разных подрядчиков отличается?
Стоимость зависит от периметра, количества функций и пользовательских ролей, формата проверки, глубины ручного анализа, ограничений, состава отчета и наличия ретеста. Одинаковое название услуги не означает одинаковый объем работ.
Чем пентест отличается от автоматического анализа уязвимостей?
Автоматические инструменты помогают выявлять известные технические признаки уязвимостей. Пентест включает ручную проверку, анализ бизнес-логики и попытку объединить отдельные недостатки в реализуемые сценарии атаки.
Что лучше: внешний или внутренний пентест?
Выбор зависит от задачи. Внешний пентест оценивает публично доступную поверхность атаки, а внутренний пентест показывает, какие действия возможны после получения доступа к корпоративной сети или внутренней учетной записи.
Можно ли заказать пентест только сайта?
Да, если область проверки ограничена веб-ресурсом. Однако до начала работ необходимо определить, входят ли в пентест сайта API, личные кабинеты, административные функции, интеграции и связанные домены.
Если нужно определить периметр пентеста и получить оценку работ для сопоставимого объема проверки, можно обсудить задачу со специалистами Б-152.
