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

Начнём с явно условной истории, которая показывает правдоподобную ошибку при закупке. Небольшая B2B-платформа для выставления счетов готовится к сделке с крупным клиентом, и тот просит результаты независимого тестирования на проникновение. Руководитель разработки рассылает запрос трём компаниям и получает три аккуратных предложения. Во всех — «ручное тестирование по OWASP Top 10», этапы «разведка — тестирование — отчёт», похожие сроки и красивый пример отчёта. Выбирают того, кто ответил быстрее. Отчёт приходит вовремя, в нём несколько находок средней критичности, все исправлены, клиент доволен.

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

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

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

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

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

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

Начинать с охвата: что именно вы покупаете

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

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

Роли, арендаторы и бизнес-логика

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

Стенд или продуктив

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

Отправная точка атакующего

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

Отдельный случай — разведка внешней поверхности атаки. Найденные в процессе домены и адреса нельзя сразу атаковать: сначала нужно подтвердить, что они принадлежат вам и входят в разрешённый охват. Подрядчик, готовый «заодно проверить всё, что найдём», демонстрирует не усердие, а отсутствие дисциплины.

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

Методология: процесс, а не список стандартов

Во многих предложениях перечисляют OWASP и NIST. Вопрос не в том, назван ли стандарт, а в том, отражён ли он в плане, в ходе работ и в отчёте.

Процедура и измеримое покрытие

OWASP Web Security Testing Guide описывает, как тестировать веб-приложения; в этой статье используется WSTG 4.2. Надёжный подрядчик назовёт версию WSTG и категории тестов, которые войдут в план, и объяснит, какие категории к вашему продукту неприменимы и почему.

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

OWASP Top 10 в редакции 2025 года остаётся документом для повышения осведомлённости о наиболее критичных рисках веб-приложений. Это полезная нижняя планка, но формулировка «протестировано по OWASP Top 10» описывает минимум, а не полноту проверки.

Техники и их ограничения

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

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

Техническая глубина: что проверить на интервью

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

Сессии, междоменная политика и заголовки

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

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

Учётные данные и доступ подрядчика

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

Отчёт как продукт, который остаётся у вас

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

Класс слабости и подтверждённая причина

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

Приоритизация с учётом атакующего

Метка «высокая» без объяснения мало что даёт. Сильный отчёт обосновывает критичность через достижимость, необходимые права атакующего, последствия и контекст эксплуатации. В перечне MITRE CWE Top 25 за 2025 год, помимо основного рейтинга, опубликовано ранжирование слабостей, стоящих за уязвимостями из каталога CISA Known Exploited Vulnerabilities, — один из возможных источников такого контекста. Как строить приоритизацию на подобных данных, подробно разобрано в материале про риск-ориентированную приоритизацию уязвимостей.

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

Доказательства и их гигиена

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

Повторная проверка исправления и связанных путей

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

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

Эта логика совпадает с подходом CISA Secure by Design. Агентство призывает закладывать безопасность на этапе проектирования, чтобы существенно сократить число эксплуатируемых дефектов, а его серия предупреждений Secure by Design разбирала устранение целых классов — межсайтового скриптинга, внедрения команд ОС, обхода каталогов. Подрядчик, чьи рекомендации звучат как «экранируйте этот параметр», а не как «уберите причину класса», даёт организации меньше. О том, как доказывать, что исправления действительно работают, — в статье про валидацию устранения после пентеста.

Независимость, данные и разрешения

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

Независимость

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

Обращение с данными

Задайте одни и те же вопросы каждому: где хранятся учётные данные и артефакты тестирования, кто к ним имеет доступ, каким каналом передаётся отчёт, когда и как всё это уничтожается и чем подтверждается уничтожение. Если подрядчик не может ответить конкретно, это тоже ответ.

Разрешения всех уполномоченных сторон

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

Компромиссы между подходами подрядчиков

Ни один формат не лучше остальных во всех случаях; важно понимать, чем вы платите за выбранный.

Работу, описанную через OWASP Top 10, удобно объяснять руководству, но сам документ является перечнем для повышения осведомлённости, а не полным планом верификации. Привязка к требованиям ASVS даёт измеримое покрытие, но требует усилий от заказчика: выбрать разделы и уровень, исключить неприменимое, договориться о статусах.

Собственная методология подрядчика может быть сильной, но её трудно сравнить с чужой. Для применимой веб- и API-части попросите каждого претендента сопоставить подход с версионированными категориями WSTG и требованиями ASVS. Для мобильных, облачных, инфраструктурных и других компонентов требуйте явных технических критериев и методов. От собственного процесса никто не отказывается; такая привязка и критерии по компонентам упрощают сравнение.

Разовый тест — снимок на дату. NIST Cybersecurity Framework 2.0 рассматривает кибербезопасность как риск, который нужно понимать и которым нужно управлять, а отдельный пентест — лишь один источник информации для такого управления. Для продуктов с частыми релизами один из вариантов — сочетать периодическую широкую оценку с тестированием конкретных изменений, влияющих на безопасность: новой схемы аутентификации, нового публичного API, смены модели хранения данных. Это не значит, что каждый коммит требует платного пентеста; как отбирать такие изменения и покупать подобные работы, описано в материале про пентест по изменениям.

Наконец, возраст ориентиров. SP 800-115 по-прежнему помогает структурировать планирование и анализ, но датирован 2008 годом. Для содержания проверок разумно опираться на версионированные ASVS 5.0.0 и WSTG, а также на редакции OWASP Top 10 и CWE Top 25 за 2025 год — каждый раз указывая версию, а не слово «последний».

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

Вопросы подрядчикам и тревожные признаки

Вопросы работают, только если всем претендентам уходит одинаковый набор и ответы можно сравнить построчно. Для применимой веб- и API-части попросите назвать версию WSTG и версионированные требования ASVS; для мобильных, облачных, инфраструктурных и других компонентов требуйте явных технических критериев и методов. Спросите, как программные находки при уместности связываются с CWE, какая схема используется там, где CWE не подходит, и какие доказательства поддерживают заявленное объяснение причины. Уточните, как контекст эксплуатации влияет на порядок исправления. Узнайте, какие техники будут использованы и чего они вероятнее всего не найдут на вашем охвате. Уточните, как защищаются, хранятся и уничтожаются учётные данные, тестовые данные и отчёты, какая повторная проверка входит в работы и как фиксируется её результат. И наконец, как итоги будут представлены руководству — в терминах влияния на риски, а не цветной статистики.

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

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

Как принять решение и сохранить его обоснование

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

1. Единый охватВсем претендентам уходит один документ: системы, роли, арендаторы, среды, исключения, отправная точка и ожидаемые доказательства.
2. Сопоставимые ответыКаждый привязывает применимую веб- и API-часть к версионированным WSTG и ASVS, задаёт критерии для остальных компонентов и называет ограничения техник.
3. Проверка доказательствОбезличенный отчёт, техническое интервью и правила обращения с данными оцениваются по одной заранее согласованной таблице.
4. Решение и разрешенияОбоснование фиксируется; каждая уполномоченная сторона разрешает работы в своей зоне, а применимые условия хостинга или провайдера и правила работ соблюдены до старта.
5. Приёмка и ретестНаходки принимаются по доказательствам, исправления перепроверяются в оговорённых условиях, выводы идут в следующую закупку.

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

Удобно также сделать требования ASVS общим языком для тестировщиков и разработчиков. Стандарт публикуется в машиночитаемых форматах, включая CSV и JSON, поэтому одни и те же требования могут превращаться в задачи бэклога, планы тестирования и критерии приёмки. Тогда результаты следующего подрядчика будет проще сравнить с предыдущими при условии, что также зафиксированы охват, статусы и методы, даже если поставщик сменится.

Итог: выбирайте работу, которую можно проверить

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

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