Координированное раскрытие уязвимостей: гайд

47-й репорт на HackerOne стал переломным. IDOR в API финтеха - доступ к транзакциям других пользователей через подмену идентификатора в запросе. Первую версию написал за 15 минут: URL, параметр, скриншот. Ответ триажа - Informative, «недостаточно данных для воспроизведения». Переписал с нуля: CVSS-вектор, пошаговый PoC на Python, оценка бизнес-импакта с расчётом затронутых записей. Через неделю - Critical, $5000 bounty. Тот же баг, тот же endpoint. Разница - в процессе координированного раскрытия уязвимостей и качестве отчёта.

Responsible disclosure, full disclosure и CVD программа​

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

Full disclosure - публикация всех деталей уязвимости без предварительного уведомления вендора. Подход из 90-х: нашёл - выложил. Между публикацией и патчем проходят дни или недели, и всё это время уязвимость открыта для всех желающих. С точки зрения MITRE ATT&CK, public disclosure напрямую питает тактику Resource Development: атакующие подбирают уязвимости из открытых источников (Vulnerabilities, T1588.006) и используют их для Exploit Public-Facing Application (T1190, Initial Access).

Responsible disclosure - исследователь отправляет отчёт вендору и ждёт исправления. Идея правильная, но без фиксированного дедлайна вендор может тянуть месяцами. У исследователя нет рычага давления, а уязвимость остаётся открытой. Я видел кейсы, когда ожидание растягивалось на полгода - и это ещё оптимистичный сценарий.

Координированное раскрытие уязвимостей (CVD) - эволюция responsible disclosure с жёстким таймлайном и обязательствами обеих сторон. Исследователь даёт вендору фиксированный срок на исправление, по истечении которого имеет право опубликовать детали. Согласно рекомендациям FIRST (Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure v1.1), обе стороны заранее согласовывают дедлайн, формат коммуникации и условия раскрытия. Процесс закреплён в ISO/IEC 29147 (раскрытие) и ISO/IEC 30111 (обработка уязвимостей вендором).

Ключевое отличие: дедлайн в CVD - не просьба, а контракт. Google Project Zero использует 90-дневный дедлайн с момента уведомления вендора, ZDI (Zero Day Initiative) даёт 120 дней с момента получения ответа. Вендор молчит - таймер всё равно тикает.

Как репортить уязвимости: процесс раскрытия багов по шагам​

Первый контакт с вендором​

Первый шаг - найти security-контакт. По рекомендациям FIRST, вендоры должны публиковать адрес security@company.com и страницу /security или файл /.well-known/[URL='https://www.rfc-editor.org/rfc/rfc9116']security.txt[/URL]. На практике далеко не все это делают (особенно за пределами топ-100 компаний).

Если контакта нет, проверяйте:

• Vulnerability Disclosure Policy (VDP) на сайте компании
• Bug bounty программу на платформах (HackerOne, Bugcrowd, Intigriti, BI.ZONE Bug Bounty)
• Файл SECURITY.md в GitHub-репозитории
• При отсутствии политики безопасности можно создать issue с запросом контактного лица, но без деталей уязвимости - issue публичный

Первое сообщение должно содержать тип уязвимости (без полного PoC), затронутый продукт с версией, предварительную оценку severity, предложение по каналу безопасной коммуникации (PGP, Signal) и ваш дедлайн раскрытия. Не отправляйте полный эксплойт в первом письме - сначала убедитесь, что адресат правильный. Однажды я отправил детальный PoC на общий info@ - письмо переслали в маркетинг. Хорошо, что без боевой нагрузки.

Таймлайн и дедлайн раскрытия​

Стандартный таймлайн CVD программы:


Технический директор Ledger Шарль Гийме в открытом письме (сентябрь 2025) назвал 90 дней «распространённым базовым сроком, который может меняться в зависимости от серьёзности проблемы и сложности исправления». Глава безопасности Trezor Ян Комарек добавил, что 90-дневный срок - обязательство не только для исследователя, но и для производителя: если компания не устранит проблему в согласованный срок, исследователь имеет право опубликовать технические детали.

Для уязвимостей с активной эксплуатацией (in-the-wild) Microsoft рекомендует, чтобы исследователь и вендор «работали вместе как можно ближе для раннего публичного раскрытия с целью защиты клиентов». Дедлайн при in-the-wild сжимается до дней. Тут не до церемоний.

Что делать, если вендор молчит? Согласно рекомендациям CERT/CC: при отсутствии ответа вы имеете право раскрыть информацию по истечении заявленного дедлайна. Перед этим сделайте минимум три попытки контакта по разным каналам и задокументируйте каждую с точными датами. Лог переписки - ваша страховка.

Написание отчёта об уязвимости: от шаблона до bounty​

Типичные причины отклонения, которые можно предотвратить: отсутствие PoC (голое утверждение «нашёл XSS»), выход за scope программы (не читали policy), попытка эскалации severity без обоснования (заявляете Critical, а по CVSS получается Medium).

PoC: что включать и чего избегать​

PoC - доказательство, а не боевой эксплойт. Демонстрируйте импакт с минимальным воздействием:
Включайте: скриншоты с замазанными PII, HTTP-запросы из Burp Suite (Copy as curl), минимальный скрипт воспроизведения, видео для сложных многошаговых сценариев.

Не включайте: реальные данные других пользователей (замените на [REDACTED]), деструктивные операции (DELETE, массовый dump), действия за пределами scope. Один исследователь потерял аккаунт на платформе за mass scraping «для подтверждения импакта» - scope violation, бан, репорт аннулирован. Жадность в PoC - прямая дорога к бану.

Многосторонняя координация: когда затронуты несколько вендоров​

Отдельная уязвимость иногда затрагивает десятки вендоров. Heartbleed (OpenSSL - тысячи зависимых продуктов), Spectre и Meltdown (процессорные архитектуры, координация заняла 7 месяцев). Согласно FIRST Guidelines v1.1, в таких случаях нужен координатор - CERT/CC, CISA или аналогичная организация.

Ключевые правила из FIRST:

• Минимизируйте круг посвящённых. Каждый дополнительный участник увеличивает риск утечки до выхода патча
• Используйте координатора. Он берёт на себя коммуникацию с downstream-вендорами и согласование единой даты раскрытия
• Все вендоры выпускают патчи одновременно. Иначе атакующие реверсят первый патч и эксплуатируют остальных

Для hardware-уязвимостей координация особенно болезненна: исправления могут требовать действий на нескольких уровнях (firmware, OS, application), а распространение патчей зависит от третьих сторон. Рядовому исследователю тут важно знать одно: если вы нашли уязвимость в библиотеке или компоненте, которые используют несколько вендоров - не пытайтесь координировать самостоятельно. Обратитесь в CERT/CC или CISA. Для этого они и существуют, а вы себе нервы сбережёте.

Bug bounty карьера и vulnerability disclosure policy​

Выбор платформы и программы​

Стратегия входа в bug bounty карьеру зависит от этапа:


Ключевой метрик - signal: соотношение принятых репортов к общему числу подач. Signal выше 80% открывает двери в приватные программы. Signal ниже 50% - половина ваших репортов это шум для триаж-команды, и платформа это запомнит.

Санкционные ограничения и KYC для российских исследователей​

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

Альтернативы:

• Российские платформы: BI.ZONE Bug Bounty, Positive Technologies Bug Bounty (Standoff 365) - выплаты в рублях без санкционных рисков
• Прямые VDP вендоров: некоторые компании принимают репорты напрямую через security@, минуя платформы
• CVE без bounty: если финансовая сторона заблокирована, CVE-идентификатор и благодарность в advisory - это репутационный капитал, который конвертируется в приглашения и позиции в ИБ-командах. Звучит утешительно, но на деле работает: пара десятков CVE в профиле открывают двери, которые не открывает никакой диплом

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

CISA рекомендации по раскрытию уязвимостей и стандарты VDP​

CISA ведёт собственную CVD-программу и публикует руководства для организаций. Ключевые элементы vulnerability disclosure policy по CISA:

• Scope: какие системы и продукты покрыты программой
• Safe harbor: юридическая защита для исследователей, действующих в рамках policy. Согласно FIRST, правовое давление на исследователей «часто создаёт сдерживающий эффект на нужные security-исследования»
• SLA по ответам: обязательство ответить в течение фиксированного срока
• Процесс CVE: организация может стать CNA (CVE Numbering Authority) и самостоятельно присваивать идентификаторы

В Европе NIS2 Directive обязал страны ЕС иметь национальную CVD-политику к октябрю 2024, а Cyber Resilience Act (CRA) вводит дополнительные требования к вендорам. Для security researcher это означает: если у компании есть опубликованная VDP - используйте её, это ваша юридическая защита. Если VDP нет - зафиксируйте попытки связаться, выдерживайте разумный дедлайн и документируйте каждый шаг. В спорных ситуациях ваш лог коммуникации - единственное доказательство добросовестности.

За несколько лет активного участия в Bug Bounty я пришёл к выводу, который разделяют далеко не все: техническое мастерство в поиске уязвимостей - это процентов 30 успеха. Остальные 70 - умение описать находку так, чтобы у триажера не осталось ни одного вопроса. Знаю исследователей с десятками CVE, которые зарабатывают меньше тех, кто находит пять багов в год, но каждый bug bounty репорт оформляет на уровне vendor advisory. Координированное раскрытие уязвимостей как процесс работает только при одном условии - вендор играет по тем же правилам. Я видел случаи, когда компания получала репорт, тихо патчила баг и отказывалась платить, заявляя «мы знали об этом». Без timestamp первого письма и подтверждения получения доказать первенство невозможно. Гийме из Ledger прав: с распространением AI порог входа в поиск уязвимостей падает. Но AI пока не умеет вести переговоры о severity с упрямой security-командой, не умеет выбирать момент для раскрытия, не умеет строить доверие с триаж-командой через серию качественных репортов. Это человеческие навыки, и именно они отделяют career bounty hunter от разового охотника за наградами. Навык поиска нарабатывается на практике - если хотите перейти от теории к реальным задачам, на HackerLab.pro есть таски от web до crypto разных уровней сложности, где можно набить руку перед первым серьёзным репортом.