Сколько стоит пентест веб-приложения и что вы получаете за эти деньги

Краткий ответ

Пентест веб-приложения стоит от $539 за автоматизированную проверку по OWASP Top 10 до $8 000+ за полноценный ручной тест крупной SaaS-платформы с бизнес-логикой, ролями и API. Цена зависит от четырёх вещей: размера приложения, глубины проверки, типа доступа (чёрный или серый ящик) и того, входит ли в работу повторная проверка после исправлений. Средний срок — 9–10 рабочих дней. На выходе вы должны получить отчёт с оценкой уязвимостей по CVSS, шагами воспроизведения и рекомендациями по исправлению — а не список из сканера.

Пентест и сканирование уязвимостей — это разные вещи

Половина недоразумений с ценой возникает из-за того, что под словом «пентест» продают две разные услуги.

Сканирование уязвимостей (Vulnerability Assessment) — автоматическая проверка инструментами. Сканер обходит приложение, сверяет версии библиотек с базами CVE, проверяет типовые ошибки конфигурации и заголовков. Работает быстро, стоит недорого, находит то, что лежит на поверхности.

Пентест (тест на проникновение) — ручная работа инженера. Он пытается обойти вашу авторизацию, поднять привилегии обычного пользователя до администратора, получить чужие данные через подстановку идентификаторов, обойти лимиты в бизнес-логике. Сканер этого не умеет в принципе: он не знает, что в вашей системе «менеджер не должен видеть заявки чужого филиала».

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

Из чего складывается цена

1. Размер и сложность приложения. Считается не по страницам, а по количеству ролей, точек входа и уникальных бизнес-сценариев. Приложение с двумя ролями и десятью экранами и платформа с личным кабинетом, админкой, партнёрским порталом и мобильным API — это разные объёмы работы, даже если фронтенд выглядит похоже.

2. Тип доступа. Black box — тестировщик работает как внешний злоумышленник, без учётных записей. Grey box — ему выдают тестовые аккаунты каждой роли. Grey box дороже по подготовке, но находит существенно больше: большинство критичных проблем живёт за формой входа, а не перед ней.

3. Глубина. Проверка по OWASP Top 10 — базовый минимум. Полное тестирование по методологии OWASP WSTG v4.2 включает работу с бизнес-логикой, разграничением доступа между тенантами, обработкой файлов, интеграциями и API.

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

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

Ориентиры по ценам

Это фиксированные цены, а не часовые ставки. Объём фиксируется до старта, и счёт в конце совпадает со сметой.

Когда пентест действительно нужен

Не «раз в год для галочки», а по конкретным поводам:

• Клиент прислал опросник по безопасности. В корпоративных закупках и в enterprise-сделках требование «предоставьте отчёт о независимом тестировании за последние 12 месяцев» — стандартная строка.
• Вы готовитесь к ISO 27001, SOC 2 или PCI DSS. Пентест — доказательная база для аудитора, а не отдельная формальность.
• Вы обрабатываете чужие деньги или персональные данные. Финтех, МФО, медицина, HR-платформы, всё с платежами и документами.
• Крупный релиз или переезд. Новая авторизация, новая роль, новый мультитенантный контур, миграция в облако.
• Смена команды разработки. Код писали одни, поддерживают другие — независимая проверка показывает, что осталось внутри.

Если ни один пункт не про вас, начните с IT Health Check за $89: он покажет, есть ли смысл в полноценном тесте.

Что должно быть в отчёте

Отчёт — единственный материальный результат работы, и по нему легко отличить настоящий пентест от выгрузки из сканера. В нормальном отчёте есть:

• Резюме для руководства — без терминов, на одну страницу: что нашли, чем это грозит бизнесу, что делать в первую очередь.
• Каждая находка отдельно — описание, оценка по CVSS 3.1, затронутые компоненты.
• Шаги воспроизведения — конкретный запрос, конкретный параметр, скриншот. Ваш разработчик должен уметь повторить находку без созвона с тестировщиком.
• Рекомендации по исправлению — что именно менять в коде или конфигурации, а не «внедрить защиту от SQL-инъекций».
• Приоритеты. Тридцать находок без приоритизации — это не отчёт, а задача, переложенная обратно на вас.
• Письмо-аттестация — короткий документ для вашего клиента или аудитора.

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

Семь вопросов подрядчику

1. Тест ручной или автоматизированный? Какая доля ручной работы?
2. По какой методологии работаете — OWASP WSTG, PTES, что-то своё?
3. Кто конкретно будет тестировать и какие у него сертификации?
4. Входит ли ретест после исправлений и в какой срок?
5. Будет ли письмо-аттестация для наших клиентов и аудиторов?
6. Что произойдёт, если во время теста упадёт продакшен?
7. Цена фиксированная или почасовая? Что считается выходом за объём?

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

Как подготовиться и не переплатить

Половина перерасхода бюджета возникает из-за неготовности на стороне заказчика.

• Поднимите отдельный стенд, копию продакшена с реальными данными в обезличенном виде. Тест на живой системе возможен, но требует ограничений, а значит — меньшего покрытия.
• Выдайте учётные записи всех ролей заранее. Каждый день ожидания доступов — день простоя в оплаченном окне.
• Опишите бизнес-логику в двух абзацах. Что запрещено пользователю? Кто кого не должен видеть? Где деньги? Инженер потратит время на проверку, а не на реверс-инжиниринг ваших правил.
• Назначьте одного ответственного со своей стороны с правом отвечать на технические вопросы в течение дня.
• Заложите время на исправления. Отчёт без исправлений не улучшает безопасность и не закрывает требование аудитора.

Как это выглядит на практике

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

Это и есть разница между «просканировали» и «протестировали».

Частые вопросы

Сколько длится пентест?

Стандартный тест веб-приложения — 9–10 рабочих дней с момента выдачи доступов. Vulnerability Assessment — 3–5 дней. Крупные платформы — от трёх недель.

Не сломается ли продакшен?

Ограничения фиксируются в Rules of Engagement до старта: какие атаки исключены, в какие часы работаем, кому звонить при инциденте. Нагрузочные и разрушающие сценарии по умолчанию не проводятся.

Мы маленькая компания, нам это рано?

Размер компании не влияет на решение. Влияет то, чьи данные вы обрабатываете и кто у вас в клиентах. Если вы продаёте B2B и вас проверяет служба безопасности заказчика — уже не рано.

Нужен NDA?

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

Пентеста достаточно для ISO 27001?

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

Что делать сразу после отчёта?

Исправить критичные и высокие находки, заказать ретест, получить письмо-аттестацию. Дальше — планировать следующую проверку после крупных изменений в системе.