Пентест перед запуском продукта: объём, глубина и критерии релиза

До публичного запуска остаётся одиннадцать дней. Возьмём условную B2B-платформу для выставления счетов: у каждого клиента свой кабинет, бухгалтеры загружают реестры в CSV, партнёры подключаются через открытый API, а сотрудники поддержки работают в отдельной консоли, где есть кнопка «войти как клиент», чтобы разобраться с проблемой. Маркетинг оплачен, дата объявлена, пентест заказан на последнюю неделю — «чтобы проверить уже готовое».

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

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

Что даёт тестирование на проникновение перед релизом — и чего не даёт

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

Инициатива CISA Secure by Design настаивает на том, что безопасность закладывают на этапе проектирования, а не добавляют после выхода продукта. Пентест вписывается в эту логику как проверка: он показывает, выдержали ли проектные решения встречу с человеком, который целенаправленно ищет, где они ломаются. Заменить безопасное проектирование он не может.

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

Пентест — не сертификация, не аттестация и не заключение о соответствии. Именно поэтому его результат полезно читать как материал для решения о риске, а не как печать «безопасно».

Как определить объём пентеста перед запуском

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

Отдельно стоит назвать служебные поверхности. Консоли администрирования, инструменты поддержки и внутренние эндпоинты операционной команды могут иметь широкие привилегии и всё же выпасть из объёма с аргументом «это не для клиентов».

Активы, роли и арендаторы

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

Не стоит недооценивать функции «только для чтения». Даже если экспорт, отчёты, поиск и предпросмотр документов не изменяют бизнес-объекты, они могут раскрывать чужие данные. Режим только чтения сам по себе не означает низкий риск.

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

Поверхность атаки и подтверждение владения

Перед активным тестированием полезно собрать фактическую поверхность атаки: поддомены, публичные бакеты, тестовые стенды, «забытые» версии API. Но найденный актив ещё не означает, что его можно атаковать. Сначала нужно подтвердить, что он принадлежит заказчику и что заказчик вправе разрешить проверку. Домен, похожий на ваш, может принадлежать подрядчику, бывшему партнёру или постороннему человеку. Как выстроить такую разведку и расставить приоритеты по её результатам, разобрано в статье про оценку внешней поверхности атаки.

Разрешение и правила проведения работ

Разрешение — часть объёма, а не бюрократия. Тестирование должен письменно согласовать человек, у которого есть полномочия в отношении каждой системы в границах работ. Если часть компонентов размещена у облачного провайдера или обслуживается подрядчиком, могут действовать их собственные правила тестирования, и иногда требуется отдельное согласие. Подразумеваемое разрешение («это же наш сервис») не годится.

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

Если изменённые пути продукта понятны, а объём работ — пока нет, это удобнее обсудить до заказа. На странице согласования объёма пентеста можно описать продукт, роли и ограничения среды, а мы предложим, какие границы и какую глубину проверки имеет смысл обсуждать.

Стенд и боевая среда: что переносится, а что нет

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

Но результаты стенда не переносятся на продуктив автоматически. В боевой среде может быть иначе настроен обратный прокси или WAF, включены другие флаги функций, заданы другие права облачных ролей, стоять другие версии библиотек — а на стенде, наоборот, могут быть отключены проверки «для удобства тестирования». Стоит заранее составить короткую сверку различий и решить, какие из них существенны для безопасности.

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

Любой вывод отчёта стоит читать с оговоркой: «в этой среде, с этим доступом, в этих сценариях». Это не формальность, а честная граница того, что тест способен утверждать.

Глубина проверки: от чёрного ящика до assume-breach

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

Перед запуском задача — найти как можно больше серьёзных дефектов, пока исправления не затрагивают клиентов, поэтому дополнительный доступ может увеличить глубину проверки в пределах того же окна. Сценарии assume-breach устроены иначе: тестирование начинается из заранее согласованного «скомпрометированного» состояния, например с учётной записью рядового сотрудника или с доступом к одному контейнеру. Это полезно, чтобы понять, насколько далеко может зайти атакующий. Но такой тест не доказывает, что первоначальный доступ действительно был достижим, — он его предполагает.

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

На что опереть методику: WSTG, ASVS и Top 10

Для применимых веб-проверок приложений и HTTP API методологической основой может служить OWASP Web Security Testing Guide. Удобно попросить исполнителя заранее показать, какие разделы WSTG он покроет, какие сознательно исключит и почему. До начала работ такой список фиксирует планируемое покрытие; после работ отчёт и журнал выполненных проверок должны отдельно показать, что действительно проверено и что осталось исключённым. Версию руководства стоит фиксировать — например, 4.2, — чтобы через год было понятно, по какой редакции велась работа.

OWASP Application Security Verification Standard (ASVS) полезен по другой причине: он описывает проверяемые требования к механизмам защиты. В версии 5.0.0 ASVS рекомендует ссылаться на требования с префиксом версии, в формате вроде v5.0.0-1.2.5, потому что нумерация между версиями меняется. Для применимых веб-контролей это делает ASVS удобным языком критериев приёмки: соответствующие находки и пройденные проверки можно привязать к конкретным требованиям. Для мобильных, облачных, инфраструктурных и других проверок нужны свои явные критерии.

Граница и здесь та же. Ограниченная по объёму проверка может подкрепить выполнение требования в проверенных сценариях, но не превращает продукт в «сертифицированный по ASVS».

OWASP Top 10 в редакции 2025 года — документ для повышения осведомлённости о самых критичных рисках веб-приложений. Для запуска это нижняя планка, а не потолок: тест, который проверяет только заголовки Top 10, заметно уже теста, построенного на WSTG и ASVS. А если в продукте есть мобильный клиент, LLM-функции или промышленные компоненты, понадобятся свои методики — универсальный веб-набор их не заменит.

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

Время теста всегда конечно, и распределять его разумно по классам дефектов, которые одновременно опасны и правдоподобны для вашего стека. MITRE опубликовала редакцию CWE Top 25 Most Dangerous Software Weaknesses за 2025 год. В выпуске 2025 года вместе с основным списком вышли CWE Top 10 KEV Weaknesses, построенный по каталогу известных эксплуатируемых уязвимостей CISA, и список «On the Cusp» — слабости, которые едва не попали в основной рейтинг.

Здесь легко ошибиться в интерпретации. CWE — это классификация типов слабостей, а не оценка вероятности эксплуатации конкретного продукта. Позиция класса отражает методику и исходные данные конкретного списка: для Top 25 — опубликованные уязвимости и их оценки, для списка KEV — классы, представленные в каталоге известных эксплуатируемых уязвимостей. Она не показывает наличие дефекта в вашем продукте, вероятность его эксплуатации или частоту атак. Используйте списки как один из сигналов для приоритетов, а не как прогноз.

CISA в серии оповещений Secure by Design разбирала, как устранять на уровне классов межсайтовый скриптинг, внедрение команд ОС и обход каталогов, а совместно с ФБР выпускала предупреждение об уязвимостях переполнения буфера. В ASVS есть требование о защите от внедрения команд ОС.

Практический вывод: в объёме теста стоит явно написать, как каждый из этих классов будет проверяться для реального стека. Если продукт вызывает системные утилиты для конвертации загруженных файлов — проверяем внедрение команд и обход путей. Если интерфейс выводит пользовательский HTML — межсайтовый скриптинг и политику CSP. Если в стеке есть код на C или C++ — вопросы безопасности памяти, о которых CISA пишет в материалах о дорожных картах перехода на языки, безопасные по памяти.

Веб и API: сессии, браузерные политики и защита по умолчанию

HTTP как протокол не хранит состояние: каждый запрос сам по себе независим. Состояние сессии строится поверх него — через cookie, токены и серверные хранилища сессий. Это обычная рабочая схема, и сам протокол ей не мешает.

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

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

Content Security Policy определяет, откуда странице разрешено загружать скрипты и другие ресурсы, и помогает обнаруживать и смягчать межсайтовый скриптинг и внедрение данных. CORS управляет тем, позволит ли браузер скрипту с другого источника прочитать ответ. Это не механизм авторизации на сервере: запрос всё равно может дойти до API, и сервер обязан сам проверять, кто и что запрашивает. Cross-Origin Resource Policy позволяет владельцу ресурса запретить браузеру отдавать его содержимое страницам других источников при запросах в режиме no-cors; саму отправку запроса она не останавливает. Permissions Policy ограничивает доступ кода страницы к функциям браузера вроде камеры или геолокации.

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

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

От планирования до повторной проверки

NIST SP 800-115 — техническое руководство по тестированию и оценке информационной безопасности, опубликованное в 2008 году и заменившее SP 800-42. Оно описывает фазы оценки как планирование, выполнение и работы после выполнения; к последним относятся анализ результатов, отчётность и выработка мер по устранению. Сканирование уязвимостей, тестирование на проникновение, оценку и экспертизу безопасности руководство рассматривает как разные виды деятельности.

Это различие пригодится при закупке. Автоматическое сканирование даёт широту и повторяемость; ручной пентест добавляет глубину, понимание бизнес-логики и умение связывать мелкие проблемы в реальный путь атаки. Документу много лет, поэтому его подход к планированию стоит сочетать с актуальными веб-методиками вроде OWASP.

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

1. Планирование и разрешениеОбъём по изменённым путям продукта, письменное разрешение уполномоченных владельцев, правила работ, условия остановки и критерии релиза — всё до старта.
2. Выполнение тестированияРучная и автоматизированная проверка по согласованной методике на стенде, близком к боевому; о критичном сообщают сразу, а не в финальном отчёте.
3. Анализ и отчётВоспроизводимые доказательства с минимумом чувствительных данных, первопричина, применимый класс CWE и, для подходящих веб-контролей, ссылка на требование ASVS с версией.
4. Исправление и повторная проверкаКоманда устраняет первопричины; исполнитель перепроверяет исправления в сопоставимых условиях и фиксирует, что именно проверено повторно.
5. Решение о релизеОтветственный руководитель подписывает запуск, перечень принятых рисков с датами устранения и план следующей проверки.

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

Критерии готовности к релизу: блокеры, исключения и владелец риска

Критерии готовности нужно определить до начала тестирования, а не после получения отчёта. Ответьте заранее на три вопроса: какие уровни критичности блокируют релиз; какие проблемы можно выпустить с датированным планом устранения и компенсирующими мерами; кто подписывает решение.

CISA подчёркивает, что ответственность за безопасность продукта должна лежать на уровне высшего руководства поставщика. Практически это означает, что организация заранее назначает владельца решения на подходящем уровне, а существенный остаточный риск фиксируется и принимается уполномоченным руководителем, а не остаётся задачей, которая тихо висит в бэклоге. NIST Cybersecurity Framework 2.0 не предписывает пентест, но помогает встроить его результаты в общий процесс управления рисками — рядом с управлением, обнаружением и реагированием.

Каким должен быть отчёт

Полезный отчёт для каждой находки указывает уровень критичности, затронутый актив, воспроизводимые шаги и доказательства, первопричину с привязкой к CWE, когда подходящая категория существует, конкретные рекомендации и, для применимого веб-контроля, требование ASVS с версией либо иной технический критерий. Доказательства должны быть минимальными и обезличенными: скриншота с замаскированными реквизитами может быть достаточно, если он сохраняет контекст и воспроизводимость; полная выгрузка для этого не нужна и создаёт дополнительный риск. Заранее договоритесь, кто получает доступ к отчёту и сколько его хранят.

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

Повторная проверка и её границы

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

Компромиссы сроков и что делать после запуска

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

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

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

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

Когда объём, глубина и критерии готовности определены, выбор подрядчика упрощается: все предложения можно сравнить по одним требованиям. CISA в руководстве Secure by Demand предлагает заказчикам ПО задавать поставщикам конкретные и проверяемые вопросы; та же дисциплина работает и при закупке тестирования безопасности.

Попросите каждого кандидата ответить по существу. Какие разделы WSTG будут покрыты и как фиксируются исключения? Будут ли применимые веб-находки и пройденные проверки ссылаться на требования ASVS с версией, будут ли подходящие слабости размечены CWE и какие критерии используются для остального объёма? Как оформляются разрешение, правила работ, условия остановки и экстренные контакты? Как хранятся и удаляются данные теста и найденная чувствительная информация? Входит ли повторная проверка и в какие сроки после исправлений? Каково соотношение ручной работы и автоматического сканирования? Можно ли увидеть обезличенный пример отчёта, чтобы оценить качество доказательств и рекомендаций?

Квалификацию команды и рекомендации стоит проверять самостоятельно, а не по маркетинговым материалам. Тревожные сигналы распознать несложно: предложение без обсуждения объёма, вывод сканера под видом пентеста, обещание признать продукт «свободным от уязвимостей», размытые ответы о том, кто разрешил тестирование каждой системы.

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

Вывод: решение о релизе, которое можно объяснить

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

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