Сколько стоит пентест и почему предложения подрядчиков отличаются в разы

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

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

Материал актуален на 2026 год

Пентест проверяет конкретный контур, а не «компанию целиком»

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

Пентест может потребоваться:

1. перед запуском нового сервиса;
2. после существенного изменения архитектуры;
3. при подготовке к требованиям заказчика или тендера;
4. после инцидента;
5. для периодической проверки внешнего или внутреннего периметра.

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

Главное ограничение пентеста — его заранее определенный периметр.

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

Поэтому корректное предложение на пентест должно начинаться не с цены, а с ответа на вопрос: что именно входит в проверку.

Нужно сначала определить периметр?

Б-152 проводит тестирование на проникновение внешнего и внутреннего периметра. До начала проекта можно определить состав систем, модель нарушителя, ограничения и ожидаемый результат, чтобы оценка отражала реальный объем работ.

Почему количество IP-адресов почти ничего не говорит о сложности

При предварительной оценке подрядчики обычно спрашивают количество:

1. доменов;
2. IP-адресов;
3. приложений;
4. API;
5. сетевых сегментов.

Это полезные данные, но сами по себе они не показывают реальную трудоемкость.

За одним IP-адресом может находиться простой информационный сайт без авторизации.

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

Формально объектов одинаковое количество. Фактически во втором случае тестировщикам придется проверить значительно больше функций и сценариев.

Поэтому оценка «за один IP» или «за один сайт» слишком грубая, если она не учитывает внутреннее устройство системы.

На стоимость влияет поверхность атаки, а не размер бизнеса

Крупная организация не обязательно заказывает большой пентест.

Она может ограничить проверку одним публичным сервисом, хотя внутри работает сложная распределенная инфраструктура.

И наоборот: небольшая технологическая компания может предоставить на проверку платформу с большим количеством API, ролей, интеграций и внешних интерфейсов.

Важнее поверхность атаки — совокупность компонентов, функций и интерфейсов, через которые потенциальный нарушитель может воздействовать на систему.

В установленном периметре к ней могут относиться:

1. веб-приложения;
2. API;
3. системы авторизации;
4. облачные сервисы;
5. интеграции;
6. сетевые сервисы;
7. другие точки взаимодействия.

Чем больше элементов и связей между ними, тем больше сценариев предстоит исследовать.

Для распределенной инфраструктуры периметр приходится описывать подробнее

Если компания работает на нескольких площадках, недостаточно перечислить системы.

Одинаковые по назначению компоненты в филиалах могут иметь разные:

1. настройки;
2. сетевые подключения;
3. права доступа;
4. ограничения;
5. ответственных.

До оценки проекта полезно согласовать:

1. какие площадки входят в проверку;
2. кто предоставляет доступы;
3. какие работы выполняются удаленно;
4. где требуется присутствие специалиста;
5. в какие временные окна разрешено тестирование;
6. как выдаются и отзываются учетные записи;
7. нужен ли единый отчет или отдельные результаты;
8. как команда сообщает о критичных уязвимостях.

Внешний и внутренний пентест при этом решают разные задачи.

Внешний пентест показывает, какие сценарии доступны со стороны публичного периметра.

Внутренний моделирует действия нарушителя, который уже получил определенный доступ к корпоративной сети или действует изнутри инфраструктуры.

В распределенной компании эти форматы могут относиться к разным площадкам и требовать отдельной оценки.

Пользовательские роли тоже увеличивают трудоемкость

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

Нужно понять, может ли пользователь делать только то, что ему разрешено.

Предположим, в сервисе есть:

1. клиент;
2. оператор;
3. руководитель;
4. администратор.

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

Подобные недостатки часто связаны с бизнес-логикой и не обнаруживаются одним автоматическим сканером.

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

Black Box, Grey Box и White Box — не тарифы «хорошо, лучше, максимально»

Формат определяет, какой объем информации получает команда до начала проверки.

Black Box

Специалисты получают минимум сведений об объекте.

Такой подход подходит, когда нужно исследовать поверхность атаки с позиции внешнего нарушителя, который не знает внутреннего устройства системы.

Grey Box

Команда получает часть информации и, например, тестовые учетные записи.

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

White Box

Исполнителю могут передаваться архитектурные сведения, расширенная документация, настройки или исходный код.

Так можно детально анализировать реализацию и сложные сценарии взаимодействия.

White Box нельзя автоматически считать «лучше» Black Box.

Все зависит от вопроса.

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

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

Иногда подходы комбинируют: например, публичный периметр проверяют Black Box, а отдельные внутренние сценарии — с предоставленными учетными записями.

«Проверить сайт на уязвимости» тоже можно очень по-разному

Одинаковая формулировка может означать совершенно разную глубину.

В одном случае речь идет о поиске наиболее очевидных технических проблем.

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

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

Чтобы выявить такую цепочку, недостаточно получить результат сканера. Специалисту приходится анализировать взаимосвязь между недостатками и проверять, реализуем ли сценарий на практике.

При этом цель пентеста — подтвердить риск, а не нанести системе максимальный ущерб.

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

Допустимую глубину нужно определить заранее.

Чем больше ограничений, тем сложнее организация проверки

Пентест — активная работа с системой, поэтому стороны заранее согласовывают Rules of Engagement.

В них определяют:

1. периметр;
2. разрешенные методы;
3. временные окна;
4. ограничения по нагрузке;
5. порядок экстренной остановки;
6. действия при обнаружении критичной уязвимости.

Для чувствительной продуктивной системы ограничения могут быть достаточно жесткими.

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

Это снижает эксплуатационный риск, но увеличивает объем планирования.

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

В качестве методических ориентиров для технического тестирования могут использоваться NIST SP 800-115 и OWASP Web Security Testing Guide. При этом конкретная программа пентеста должна учитывать реальную архитектуру и функции проверяемого объекта.

Сравниваете несколько предложений на пентест?

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

Обсудить объем и формат проверки

Отчет — тоже часть стоимости пентеста

Сравнивать предложения только по часам технической работы некорректно.

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

Команде разработки или ИБ нужно понимать:

1. где находится уязвимость;
2. при каких условиях она воспроизводится;
3. к чему может привести;
4. как ее устранить.

Руководству важны другие вопросы:

1. какие сценарии наиболее значимы;
2. какие процессы затрагиваются;
3. что исправлять в первую очередь.

Поэтому качественный результат обычно включает:

1. область и сроки проверки;
2. ограничения;
3. модель нарушителя;
4. подтвержденные уязвимости;
5. доказательства;
6. возможные сценарии эксплуатации;
7. последствия;
8. оценку критичности;
9. рекомендации по устранению;
10. обнаруженные цепочки атак;
11. ограничения, которые могли повлиять на полноту результатов.

Для оценки технической тяжести уязвимости, например, может использоваться CVSS.

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

Б-152 проводит пентесты внешнего и внутреннего периметра в форматах Black Box, Grey Box и White Box. По итогам заказчик получает отчет с подтвержденными уязвимостями, сценариями и рекомендациями по устранению.

Ретест может входить в цену, а может оплачиваться отдельно

После исправления обнаруженных уязвимостей проводится повторная проверка — ретест.

Его задача — подтвердить, что ранее обнаруженная проблема действительно устранена и исходный сценарий больше не воспроизводится в согласованном объеме.

Ретест обычно не равен повторному полному пентесту. Он сфокусирован на ранее найденных недостатках.

Но еще до старта стоит выяснить:

1. входит ли ретест в коммерческое предложение;
2. сколько циклов предусмотрено;
3. в какой срок можно запросить повторную проверку;
4. входит ли консультация по результатам.

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

Срочный пентест не всегда означает, что техническую работу можно просто ускорить

На календарный срок влияют не только сами тесты.

До старта нужно:

1. согласовать периметр;
2. организовать доступ;
3. подготовить учетные записи;
4. определить ответственных;
5. установить Rules of Engagement.

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

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

Возможна и обратная ситуация. Само тестирование небольшое, но проект растягивается, потому что заказчик долго предоставляет доступы или согласовывает потенциально опасные действия.

Поэтому в предложении лучше отдельно смотреть на трудоемкость и календарный срок.

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

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

Перед запросом стоимости компании полезно описать:

Периметр

Какие приложения, домены, IP-адреса, API и сегменты нужно проверить?

Роли

Сколько типов пользователей есть в системе и какие полномочия у них различаются?

Среду

Есть ли тестовый контур или работа будет проводиться на продуктивной системе?

Критичные функции

Какие операции и данные особенно важны?

Модель нарушителя

Нужно проверить внешний периметр или сценарий с определенным внутренним доступом?

Ограничения

Какие действия и методы запрещены?

Результат

Какой уровень детализации должен быть у отчета?

Ретест

Нужна ли повторная проверка после исправлений и сколько циклов должно входить в проект?

После этого можно сравнивать не абстрактные предложения «провести пентест сайта», а одинаковый объем работ.

Что еще проверить при выборе исполнителя

Цена важна, но она не показывает качество проверки сама по себе.

Имеет смысл отдельно узнать:

1. какая часть работы выполняется вручную;
2. как валидируются результаты автоматических инструментов;
3. кто будет проводить тестирование;
4. какую методику использует команда;
5. как защищаются переданные учетные данные;
6. что происходит с информацией, полученной в ходе тестов;
7. как заказчика уведомляют о критичных находках;
8. что входит в итоговый отчет;
9. предусмотрен ли ретест.

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

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

Что на самом деле покупает компания

Заказчик платит не за максимальное количество запущенных сканеров и не за самый длинный список замечаний.

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

Именно поэтому два подрядчика могут по-разному оценить одну систему, и обе оценки при этом окажутся обоснованными.

Главное — убедиться, что исполнители действительно считают один и тот же проект.

Перед сравнением цены достаточно определить четыре вещи:

1. Что именно проверяется.
2. По какой модели нарушителя.
3. Насколько глубокой должна быть проверка.
4. Какой результат компания должна получить после завершения работ.

Пока эти параметры не согласованы, стоимость остается предварительной.

Частые вопросы о стоимости пентеста

Почему у разных подрядчиков цена пентеста отличается?

Стоимость зависит от периметра, количества функций и ролей, формата проверки, глубины ручного анализа, ограничений, требований к отчету и наличия ретеста. Одно название услуги не означает одинаковый объем.

Чем пентест отличается от автоматического поиска уязвимостей?

Автоматические средства помогают обнаруживать известные технические признаки проблем. Пентест дополнительно включает ручную работу, анализ бизнес-логики и проверку того, можно ли объединить найденные недостатки в реальный сценарий атаки.

Что лучше: внешний или внутренний пентест?

Зависит от задачи. Внешний исследует возможности атакующего со стороны публичного периметра. Внутренний показывает, какие действия возможны после получения определенного доступа к корпоративной сети или учетной записи.

Можно ли проверить только сайт?

Да, если именно веб-ресурс составляет согласованный периметр.

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

Главное

Разброс цен на пентест чаще говорит не о разнице в тарифах подрядчиков, а о том, что они оценили разные по содержанию проекты.

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

Если нужно определить периметр и получить оценку уже для конкретной системы, можно заказать пентест в Б-152. До начала проверки специалисты уточнят объекты, модель нарушителя, ограничения и требования к результатам.