Критерии выбора подрядчика по анализу защищённости веб-приложений

Лицензии ФСТЭК и ФСБ

Реестр лицензий ФСТЭК России опубликован на сайте fstec.ru — проверить конкретную компанию можно по названию или ИНН за несколько минут, без обращения к самой компании за подтверждением. Для аудита государственных информационных систем и объектов критической информационной инфраструктуры (187-ФЗ) обязательна лицензия на ТЗКИ по приказам ФСТЭК №17 и №239: пентест такого контура прямо требует лицензии ФСТЭК на ТЗКИ.

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

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

Прямо спросите подрядчика, какая доля проверки выполняется вручную специалистом, а какая — автоматическими инструментами без участия человека. Попросите пример отчёта по завершённому проекту (обезличенный, без данных реального клиента): в нём должны быть конкретные Proof of Concept для каждой критической находки — то есть воспроизводимая последовательность действий, а не только список названий уязвимостей с общей рекомендацией «обновить версию компонента». Инструменты SAST и DAST полезны, но покрывают лишь то, что описано в их правилах, — глубина ручного тестирования принципиально отличается от автоматизированного сканирования.

Отраслевой опыт подрядчика

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

SLA и метрики качества

Срок выполнения по этапам

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

Формат и включённость ретеста

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

Число итераций коммуникации

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

Порядок эскалации критических находок

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

Прозрачность и публичная экспертиза

Публичные CVE и записи в BDU

Наличие опубликованных уязвимостей в международном реестре CVE или в российской базе данных угроз ФСТЭК (BDU) с указанием команды-автора — проверяемое доказательство того, что специалисты компании находят реальные, ранее неизвестные уязвимости, а не только применяют готовые чек-листы к типовым проверкам.

Disclosure Policy

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

Обезличенные кейсы и участие в Bug Bounty

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

Договор и юридические детали

Помимо технических критериев, стоит проверить несколько юридических пунктов до подписания.

NDA в обе стороны

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

Ответственность сторон

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

Право на результаты

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

Как проверить команду, а не только компанию на бумаге

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

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

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

Не все критерии, описанные выше, одинаково важны для каждой компании. Если приложение обрабатывает платёжные данные и подпадает под требования PCI DSS, лицензия ФСТЭК и формальная методология важнее, чем узкая отраслевая специализация подрядчика — регулятор в первую очередь проверяет наличие процесса, а не то, кто именно его выполнял. Если приложение — часть стартапа на ранней стадии без обязательных регуляторных требований, отраслевой опыт и прозрачность через публичные CVE могут быть важнее лицензии, которая в этом случае не является юридически обязательной.

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

Чек-лист перед подписанием договора

1. Лицензия ФСТЭК проверена самостоятельно в официальном реестре на fstec.ru, а не принята со слов подрядчика.
2. Получен обезличенный пример отчёта с Proof of Concept и CVSS-оценкой хотя бы по одной находке.
3. Согласован конкретный scope — какие модули, роли пользователей и API входят в проверку, а какие явно исключены.
4. Уточнён формат и включённость ретеста после устранения найденных уязвимостей.
5. Запрошен хотя бы один обезличенный кейс из смежной или той же отрасли, что и ваш бизнес.
6. В договоре прописаны конкретные сроки по каждому этапу проекта, а не только общий срок «проект под ключ».
7. Согласован порядок экстренного уведомления, если в процессе работы будет найдена критическая уязвимость, требующая немедленных действий.

Как сравнивать несколько предложений между собой

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

Крупный интегратор или boutique-команда

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

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

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