Как работают программы поиска уязвимостей и кто предоставляет white-label решения

Срез источников на 12 мая 2026.
Фокус: Bug Bounty / Vulnerability Disclosure Program (VDP), процессы запуска, примеры крупных компаний, коробочные и white-label / private-label решения.

Короткий вывод

Bug bounty: управляемый процесс приема, проверки, исправления и раскрытия уязвимостей. Компания заранее определяет область проверки, правила тестирования, safe harbor, таблицу выплат, SLA, владельцев активов и канал коммуникации. Исследователи отправляют PoC, triage-команда воспроизводит и оценивает риск, инженерные команды исправляют, затем идут ретест, выплата и иногда публичное раскрытие.

Главное различие:

White-label на рынке делится на уровни: брендированная страница, форма приема отчетов на сайте клиента, private-label операционное ведение и полный white-label портал. У лидеров рынка чаще встречаются private-программы, настроенная область проверки, брендированные страницы и встроенные формы отправки отчетов. Обработка, аккаунты исследователей и выплаты остаются на платформе. BugVault заявляет полный white-label. HackerOne и Bugcrowd подтверждают форму приема отчетов на сайте клиента. HyperCrackers и IntegSec работают как сервисные операторы для white-label ведения.

1. Как в целом работают bug bounty программы

Базовая механика

Типовой цикл выглядит так:

1. Компания публикует правила программы или открывает их для приглашенных участников.
2. В правилах указаны цели проверки, исключения, ограничения, safe harbor, требования к отчету, таблица выплат, SLA и порядок раскрытия.
3. Исследователь проверяет разрешенные цели и отправляет отчет: описание, шаги воспроизведения, PoC, реальный ущерб, затронутый актив и доказательства.
4. Triage проверяет новизну, воспроизводимость, попадание в область проверки и реальный риск.
5. Критичность оценивают по CVSS, внутренней классификации платформы и бизнес-контексту. Bugcrowd использует Vulnerability Rating Taxonomy (VRT). Многие программы опираются на CVSS.
6. Дубликаты закрывают как duplicate, слабые находки помечают как not applicable или informative, валидные отчеты передают владельцам систем.
7. Команда продукта или AppSec исправляет проблему, исследователь или triage-команда проводит ретест.
8. После подтверждения компания платит bounty, начисляет баллы репутации и при необходимости согласует публичное раскрытие.

Эта логика близка к Coordinated Vulnerability Disclosure. NIST SP 800-216 объясняет, как выстроить прием, координацию, публикацию и обработку отчетов об уязвимостях. ISO/IEC 29147 задает стандартную модель раскрытия уязвимостей для поставщиков продуктов и сервисов. См. NIST SP 800-216 и ISO/IEC 29147:2018.

Роли

Что делает платформа

Коммерческие платформы превращают "почту security@" в операционную систему:

• форма приема отчета с обязательными полями;
• каталог целей в области проверки;
• статусы отчетов;
• чат между компанией, triage и исследователем;
• поиск дубликатов;
• процесс оценки критичности;
• кошелек для выплат;
• репутация исследователей;
• приглашения в закрытые программы;
• интеграции с Jira/GitHub/GitLab/Slack/SIEM;
• отчетность по SLA, времени triage, времени исправления, выплатам и критичности.

В HackerOne triage и validation занимают центральное место в bug bounty и VDP: triage превращает поток заявок в проверенные задачи для инженеров. Источник: HackerOne triage overview. В документации HackerOne отдельно описаны статусы отчетов: validated, pending review, remediated и duplicate: HackerOne report states.

VDP и bug bounty

VDP дает процесс приема и координации уязвимостей. Bug bounty добавляет денежный стимул и активнее привлекает исследователей. На практике зрелая последовательность такая:

1. Сначала VDP: научиться принимать отчеты и исправлять.
2. Потом private bounty: пригласить небольшую группу проверенных исследователей.
3. Потом public bounty: расширить доступ, когда команда справляется с объемом и спорами.

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

Экономика

Затраты состоят из нескольких частей:

• годовая или месячная стоимость платформы либо внешнего ведения;
• бюджет выплат;
• внутреннее время triage, разработки, юристов и владельца программы;
• выплаты налогов/KYC/комиссий;
• стоимость исправлений;
• коммуникации, раскрытие, CVE или advisory, если применимо.

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

Основные риски

2. Что нужно, чтобы запустить собственную bug bounty программу

Минимум перед запуском

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

Рекомендуемый запуск по этапам

В документации HackerOne для Response/VDP описана похожая поэтапная модель: настройка программы, закрытый контролируемый запуск и публичный запуск. Перед публичным запуском программа проходит закрытый этап и показывает стабильную скорость ответов. Источник: HackerOne Response Program Setup.

Документы, которые нужны

1. Правила программы.
2. Таблица области проверки.
3. Таблица исключений из области проверки.
4. Правила тестирования.
5. Safe harbor и юридическое разрешение.
6. Требования к качеству отчета.
7. Матрица выплат.
8. SLA по первому ответу, triage, выплате и исправлению.
9. Политика раскрытия.
10. Правила допуска исследователей и санкционные ограничения.
11. Правила работы с персональными данными и вложениями.
12. Внутренний порядок действий для критичных отчетов.

В правилах bounty-программ Microsoft отдельно указаны требования к отчету: контекст, описание ошибки, PoC и видео. Там же описан единый подход к выплате, когда заявка подходит сразу под несколько программ, и отказ от части потенциальных DMCA-претензий для действий в разрешенной области. Источник: Microsoft Bounty Guidelines.

Порядок действий для критичных находок

Для P1/P0 нужен отдельный путь:

Когда public bounty рано

Публичную bounty лучше отложить при таких признаках:

• владельцы активов еще назначаются;
• очередь security-исправлений уже перегружена;
• бюджет на неожиданные критичные находки еще согласуется;
• safe harbor еще проходит юридическое согласование;
• продукт обрабатывает PII, а тестовая среда и тестовые аккаунты еще готовятся;
• команда срывает SLA по ответам исследователям;
• область проверки расплывчатая или состоит из сторонних активов.

3. Как выглядят программы крупных компаний

Что видно из примеров

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

• cloud отдельно от пользовательских продуктов;
• устройства отдельно от web и мобильных приложений;
• AI safety отдельно от классической AppSec-безопасности;
• open source отдельно от SaaS;
• безопасность автомобилей и продуктов отдельно от проблем web-аккаунтов.

У зрелых программ есть отдельные инструменты для исследователей: тестовые аккаунты, SSRF-валидаторы, отладочные инструменты, порталы для отчетов, PGP, графики раскрытия, события для исследователей и закрытые программы для отобранных участников.

4. Коробочные решения и провайдеры для запуска bug bounty

Ниже сравнительная таблица по рынку. White-label здесь означает возможность запустить форму приема отчетов или портал под своим брендом, доменом или внутри своего сайта. Private-label/customizable означает глубокую настройку программы на платформе провайдера.

Источники по провайдерам

• HackerOne: платформа Bug Bounty, закрытые и публичные программы, встроенная форма отправки отчета.
• Bugcrowd: bug bounty с внешним ведением, прием сообщений об уязвимостях, встроенная форма отправки отчета.
• Intigriti: платформа Intigriti, документация по закрытым программам.
• YesWeHack: страница продукта Bug Bounty Program.
• Synack: модель Synack, платформа Synack.
• Cobalt: Cobalt, документация по внутренним pentest-процессам.
• HackenProof: сервисы, процесс bug bounty, пример программы с SLA.
• Immunefi: Immunefi bug bounty information, Hackers page.
• Code4rena: документация Code4rena, соревнования.
• Patchstack: mVDP getting started, Bug Bounty Guidelines 2026, VDP platform announcement.
• BugBase: программы BugBase, создание bug bounty программы, закрытая bounty-программа.
• Federacy: цены, справка по bug bounty с внешним ведением, профиль TechCrunch.
• SafeHats: документация SafeHats, документация для крупных компаний.
• Hackrate: CSO Online on HackGATE.
• Yogosha: CVD/CRA guide.
• BugVault: BugVault.
• HyperCrackers: bug bounty сервисы.
• IntegSec: управление bug bounty и triage-сервисы.

5. Какие решения предлагают white-label или максимально кастомизируемый private-label подход

Классификация по степени white-label

Детали по подтвержденному white-label и встроенной форме

BugVault

BugVault позиционирует продукт как платформу bug bounty под брендом клиента и заявляет такие возможности:

• полная настройка бренда;
• логотип, цвета, домен;
• отдельное развертывание;
• закрытые пулы исследователей;
• безопасность уровня крупной компании;
• AI triage.

Вывод: это самое прямое найденное публичное заявление про полный white-label. Риск: по сравнению с HackerOne, Bugcrowd, Intigriti и YesWeHack у BugVault меньше публичных независимых доказательств зрелости и крупных клиентских референсов. Перед выбором нужна проверка: SOC 2/ISO, хранение данных, отчеты о pentest, клиентские референсы, SLA, юридическое лицо, выплаты и KYC, качество исследователей, порядок споров.

Источник: BugVault.

HackerOne

У HackerOne white-label-уровень сводится к встроенной форме отправки отчетов:

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

Вывод: подходит для брендированной формы приема. Полный жизненный цикл остается в HackerOne.

Источник: документация HackerOne по встроенной форме.

Bugcrowd

Встроенная форма Bugcrowd работает так:

• позволяет разместить форму на собственном сайте;
• отчеты обрабатываются в Crowdcontrol;
• отчет можно отправить до создания аккаунта Bugcrowd;
• внешний вид можно кастомизировать;
• поля формы заранее заданы, кроме отдельных опций вроде поля Target;
• обработка остается в Bugcrowd.

Вывод: хорошая брендированная форма приема для VDP/BBP. Полный жизненный цикл остается в Bugcrowd.

Источник: документация Bugcrowd по встроенной форме.

HyperCrackers

HyperCrackers заявляет, что может работать через ведущие bug bounty платформы или вести программы напрямую для клиентов, которым нужен white-label под своим брендом. В описании сервиса указаны область проверки, правила тестирования, политика выплат, triage, координация исправлений, проверка, метрики и поддержка раскрытия.

Вывод: это white-label сервисный оператор для операционного слоя.

Источник: bug bounty сервисы HyperCrackers.

IntegSec

IntegSec позиционируется как провайдер сервисов наступательной безопасности с white-label pentest/PTaaS для MSP и отдельно предлагает управление bug bounty программами и разбор отчетов об уязвимостях. В FAQ указано, что команда работает с HackerOne, Bugcrowd, Synack, Intigriti, Wordfence и другими платформами.

Вывод: полезно как внешний слой triage и управления, особенно для MSP. White-label у IntegSec сильнее относится к pentesting, чем к полноценному bug bounty порталу.

Источник: управление bug bounty от IntegSec.

Практическая рекомендация по выбору

Чеклист RFP для выбора white-label/private-label поставщика

При выборе провайдера стоит запросить:

Рекомендуемая целевая модель для собственной программы

Если компания запускает программу с нуля и хочет сохранить контроль над брендом:

1. Запустить VDP на собственном /security или /responsible-disclosure с safe harbor.
2. Использовать встроенную форму отправки отчетов от HackerOne/Bugcrowd или полный white-label портал, если бренд принципиален.
3. Первые 2-3 месяца вести закрытый контролируемый запуск с узкой областью проверки.
4. Подключить внешний triage, если нет внутренней AppSec-команды, способной отвечать в SLA.
5. Установить таблицу выплат для активов, где команда уверена в владельцах и правилах.
6. Открывать публичный запуск после измерения доли валидных отчетов, доли дубликатов, времени triage и очереди исправлений.
7. Через 6 месяцев расширить область проверки и добавить публичные активы, где уже есть владельцы и тестовые аккаунты.

Минимальная структура публичной страницы:

# Security vulnerability disclosure
                      
                      ## Scope
                      | Asset | Type | Eligibility | Notes |
                      
                      ## Out of scope
                      | Category | Reason |
                      
                      ## Rules
                      - No DoS/DDoS.
                      - No social engineering.
                      - No access to other users' data beyond minimal proof.
                      - Stop testing and report immediately if sensitive data is encountered.
                      
                      ## Safe harbor
                      Good-faith research within this policy is authorized.
                      
                      ## Report requirements
                      - Summary
                      - Affected asset
                      - Steps to reproduce
                      - Proof of concept
                      - Impact
                      - Suggested remediation, if known
                      
                      ## Rewards
                      | Severity | Range |
                      
                      ## SLA
                      | Event | Target |
                      
                      ## Disclosure
                      Do not disclose publicly until coordinated with us.

Итог

Рынок делится на четыре группы:

1. Платформы для крупных компаний: HackerOne, Bugcrowd, Intigriti, YesWeHack, Synack. Их сильная зона: зрелые закрытые и публичные программы, внешний triage и встроенная форма приема отчетов.
2. Вертикальные платформы: Immunefi, HackenProof, Cantina, Code4rena, Patchstack. Их сильная зона: Web3 или WordPress/OSS.
3. Платформы для стартапов: BugBase, Federacy, SafeHats, Hackrate, Yogosha. Они могут быть дешевле или сильнее в отдельных регионах; зрелость пула и SLA нужно проверять отдельно.
4. White-label и управляемые операторы: BugVault, HyperCrackers, IntegSec. В этой группе выше шанс получить white-label/private-label; проверка поставщика должна быть строже.

Для большинства компаний прагматичный путь такой: VDP с брендированной формой приема, затем закрытая bounty с внешним ведением, затем публичная bounty. Полный white-label имеет смысл, если бренд, хранение данных, MSP-перепродажа или регуляторные ограничения важнее доступа к максимальному пулу исследователей крупной платформы.