Responsible disclosure уязвимостей в 2026

В 2015 году Google Project Zero опубликовал exploit-код для уязвимости Windows за два дня до запланированного патча. Microsoft в ответном блоге назвала это "gotcha" и обвинила конкурента в том, что он поставил принцип выше безопасности пользователей. Через три года Intel полгода скрывал Spectre и Meltdown от правительства США, зато приватно уведомил Huawei и Alibaba. По данным IBM X-Force Threat Intelligence Index 2025 (показатель взят не из IBM X-Force, а из академического исследования), среднее время от публикации CVE до фактического устранения уязвимости в организациях - 29 месяцев. Двадцать девять. Между "исследователь нашёл баг" и "vendor выкатил патч" живёт вся боль responsible disclosure уязвимостей. И конфликт Microsoft с исследовательской группой Nightmare Eclipse в 2026 году снова поднял вопрос: кто на самом деле защищает пользователей, когда механизм координированного раскрытия ломается?

Конфликт вендора и исследователя: анатомия типовой войны​

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

Google vs Microsoft: 90 дней без продления​

Баг нашла внутренняя команда Google, которая ищет уязвимости не только в своих продуктах. Google уведомила Microsoft и запустила стандартный 90-дневный таймер. Microsoft попросила продлить дедлайн - отказ. Попросила хотя бы сдвинуть публикацию до ближайшего Patch Tuesday (второй вторник месяца - день, когда Microsoft предпочитает выпускать патчи) - снова отказ. Через 90 дней детали вместе с exploit-кодом ушли в паблик. За два дня до выхода патча.

По данным Santa Clara University Ethics Center, Microsoft раскритиковала решение Google и подтвердила приверженность модели Coordinated Vulnerability Disclosure (CVD) - исследователь обязан работать с разработчиком до выпуска патча, без жёстких дедлайнов. Google и сторонники фиксированных сроков возразили: жёсткий дедлайн не даёт вендорам заметать уязвимости под ковёр и балансирует право публики знать с возможностью разработчика исправить проблему. Через несколько дней Google опубликовал данные ещё о трёх уязвимостях Microsoft. Такой вот "привет".

Intel, Spectre и Meltdown: приватное раскрытие, вышедшее из-под контроля​

Другой полюс - Intel. Компания узнала о Spectre и Meltdown в июне 2017 года, но не сообщила ни правительству США, ни публике. Вместо этого приватно уведомила избранных вендоров - Huawei, Google, Alibaba, Lenovo - и работала над патчем за закрытыми дверьми. В январе 2018-го информация вышла публично. Позднее несколько сенаторов указали: компании с тесными связями с иностранными правительствами знали об уязвимости раньше американских федералов. Это создавало угрозу национальной безопасности - и Intel, мягко говоря, не выглядела героем.

Паттерн, который не меняется​

Оба кейса - и ситуация с Nightmare Eclipse, которая вернула дискуссию в острую фазу - показывают один паттерн: vendor воспринимает публикацию уязвимости как PR-удар, а не как защиту пользователей. Реакция предсказуема: попытка задержать раскрытие, юридическое давление на исследователя, минимизация серьёзности бага. Согласно VIPRE Security, "некоторые компании реагируют оборонительно - пытаются подавить информацию через юридические угрозы или преуменьшая серьёзность проблемы". Удивлён? Я - нет.

Для атакующих каждый день задержки патча - подарок. В терминах MITRE ATT&CK злоумышленники сканируют цели на наличие известных уязвимостей (Vulnerability Scanning, T1595.002, Reconnaissance), собирают данные из открытых технических баз (Search Open Technical Databases, T1596, Reconnaissance) и используют найденное для подготовки инструментов (Vulnerabilities, T1588.006, Resource Development). Результат - Exploit Public-Facing Application (T1190, Initial Access). По данным Mandiant M-Trends 2025, эксплуатация уязвимостей стала первым вектором атак в 2024 году - 38% подтверждённых инцидентов. Не фишинг, не инсайдеры - уязвимости, о которых вендор "работает над исправлением".

Full disclosure vs coordinated disclosure: три модели раскрытия уязвимостей​

Согласно OWASP Vulnerability Disclosure Cheat Sheet - базовому документу по этике раскрытия - существуют три модели. Выбор между ними определяет не только безопасность пользователей, но и юридические риски для исследователя.

Private disclosure. Исследователь передаёт отчёт вендору. Решение о публикации - целиком на стороне вендора. Большинство bug bounty программ работают по этой модели. Ограничение очевидно: если вендор решит замолчать уязвимость, пользователи никогда не узнают об угрозе. OWASP отмечает: "Исторически это приводило к тому, что исследователи теряли терпение из-за игнорирования и сокрытия уязвимостей компаниями, переходя к полному раскрытию". Знакомая история, правда?

Full disclosure уязвимостей. Полные детали - иногда с exploit-кодом - публикуются сразу после обнаружения, часто до выхода патча. OWASP характеризует подход как "крайне противоречивый и воспринимаемый многими как безответственный". Публикация PoC до патча вооружает атакующих. Но сторонники аргументируют: общественное давление - единственный надёжный способ заставить вендора шевелиться. По данным Bugcrowd, "некоторые эксперты считают, что публичная проверка - самый надёжный способ повысить осведомлённость о безопасности".

Coordinated vulnerability disclosure (CVD). Де-факто стандарт 2026 года. Приватное уведомление вендора -> согласование grace period (обычно 90 дней, до 120 для сложных случаев) -> выход патча -> публикация advisory. Google Project Zero в 2014 году установил жёсткое правило 90 дней, ставшее ориентиром для индустрии: по истечении срока детали раскрываются вне зависимости от готовности патча. ISO/IEC 29147 (Vulnerability disclosure) и ISO/IEC 30111 (Vulnerability handling processes) формализуют процесс на уровне международных стандартов.

Юридическая защита исследователя: CFAA, safe harbor и bug bounty этика​

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

CFAA и аналоги: законы, написанные не для исследователей​

Согласно VIPRE Security, "антихакерские законы, такие как Computer Fraud and Abuse Act (CFAA) в США, не были написаны с учётом этичных исследователей. Эти законы создают юридические риски даже при добросовестных намерениях". В России ситуация аналогичная - статья 272 УК РФ ("Неправомерный доступ к компьютерной информации") не содержит явных исключений для security research. Грань между "исследованием" и "неправомерным доступом" определяется не намерениями, а интерпретацией суда. То есть по букве закона вы и злоумышленник - одно и то же. В ЕС Computer Misuse Act и его аналоги работают схожим образом.

Safe harbor: что защищает и что нет​

Bug bounty программы предоставляют safe harbor - обязательство компании не преследовать исследователя юридически при соблюдении scope и правил. OWASP Vulnerability Disclosure Cheat Sheet предупреждает: "Выход за рамки scope может квалифицироваться как уголовное преступление даже при наличии bug bounty программы". Scope программы нужно читать внимательнее трудового договора. Серьёзно - внимательнее.

Красные флаги в vulnerability disclosure policy​

На что смотреть в правилах программы до того, как вы отправите первый отчёт:

• Отсутствие явного safe harbor clause - без него ваша юридическая защита равна нулю
• NDA, запрещающий любое раскрытие даже после выхода патча - вендор получает право молчания навсегда
• Отсутствие обязательств по срокам ответа - vendor может тянуть бесконечно
• Формулировка "мы оставляем за собой право преследовать" без чёткого определения нарушения
• Scope, исключающий критически важные компоненты (API, авторизация, платёжный flow) - то есть самое интересное вам трогать нельзя

Три нюанса для начинающих багхантеров​

Налоги. Выплаты по bug bounty - доход. OWASP: "Обеспечение отчётности по этому доходу и уплата соответствующего налога - ваша ответственность". Для российских исследователей дополнительная головная боль - санкционные ограничения на получение выплат с зарубежных платформ. KYC-процедуры HackerOne и Bugcrowd могут блокировать переводы на российские счета. Это не теория - коллеги с этим сталкиваются регулярно.

Рабочий контракт. Уязвимость, найденная в ходе рабочих обязанностей или на оборудовании работодателя, может принадлежать работодателю. Перед участием в bug bounty - перечитайте трудовой договор.

Вымогательство. Формулировка "заплатите, иначе опубликую" - уголовное преступление независимо от критичности бага и страны юрисдикции. Без вариантов. Даже если баг критический, даже если вендор ведёт себя по-свински.

Пошаговый таймлайн координированного раскрытия уязвимостей​

ПЕРЕВОД:
Описание импакта, шаги воспроизведения, чёткий дедлайн, готовность к сотрудничеству. Никаких угроз, никаких требований оплаты. Сухо и по делу.

День 14-30: follow-up​

Если ответа нет - повторное письмо с копией первого. Зафиксируйте дату и канал. OWASP рекомендует не отправлять follow-up чаще, чем раз в 14 дней - дайте команде время разобраться. Если первое письмо ушло на security@ - попробуйте альтернативный канал. Иногда security@ улетает в /dev/null, а через LinkedIn security-лид отвечает за час.

День 60: эскалация​

Vendor по-прежнему молчит - привлекайте координатора. CERT/CC, национальный CERT или платформа-посредник могут надавить через свои каналы. На этом этапе запросите CVE-номер: если vendor - CNA (CVE Numbering Authority), он присвоит CVE сам. Если нет - заполняйте форму на cve.mitre.org. Для open-source проектов - GitHub Security Advisories (GitHub как CNA присваивает CVE автоматически).

День 90: точка принятия решения​

Дедлайн истёк. Три сценария: vendor выпустил патч - публикуете advisory с деталями; vendor работает над патчем и запрашивает дополнительное время - стандартная практика дать 14-30 дополнительных дней для сложных случаев; vendor молчит или отрицает проблему - переход к публикации. Тут уже каждый сам решает, насколько далеко готов зайти.

0-day публикация исследователями: когда full disclosure оправдан​

Решение опубликовать детали уязвимости до выхода патча - самый тяжёлый момент в практике responsible disclosure уязвимостей. OWASP и большинство экспертов сходятся: full disclosure - крайняя мера. Но есть ситуации, когда она оправдана:

• Vendor не реагирует после 90+ дней и множественных попыток контакта через разные каналы
• Уязвимость уже активно эксплуатируется в дикой природе (тут молчать - преступление перед пользователями)
• Vendor выпустил патч, который фактически не устраняет проблему
• Vendor угрожает юридическим преследованием вместо исправления бага

При публикации - advisory без рабочего exploit-кода: описание уязвимости, затронутые версии, mitigation и рекомендации по защите. Рабочий exploit - в подавляющем большинстве случаев неоправданно. IBM X-Force отмечает: 70% инцидентов, обработанных X-Force в 2024 году, затронули критическую инфраструктуру. Уязвимость в IoT-лампочке и уязвимость в промышленном контроллере - разный уровень ответственности при принятии решения. Это нужно держать в голове.

Чек-лист перед публикацией: права исследователей безопасности​

Перед любым публичным раскрытием - пройдите по этому списку:


Если хотя бы один пункт не закрыт - публикация преждевременна. Без исключений.

Конфликт между вендором и исследователем - не вопрос абстрактной этики. Это вопрос баланса сил. Vendor имеет юридический отдел, PR-команду и возможность молчать месяцами. Исследователь имеет отчёт, таймстемпы и статью 272 УК, которая по букве закона не отличает его от злоумышленника. Coordinated disclosure работает ровно до тех пор, пока обе стороны играют добросовестно. Когда vendor тянет время, угрожает судом или тихо фиксит баг без CVE и advisory - "координация" превращается в одностороннюю уступку.

90-дневный дедлайн Project Zero - не произвол. Это единственный механизм, который заставляет систему работать. Без жёсткого дедлайна патчинг уязвимостей вендором будет длиться ровно столько, сколько позволите. 29 месяцев от публикации CVE до устранения - статистика IBM, не чьё-то мнение. Вопрос не в том, "этично ли публиковать детали", а в том, "этично ли молчать, пока 38% инцидентов начинаются через эксплуатацию известных уязвимостей".

Для тех, кто только начинает публиковать находки: главная защита - не safe harbor и не юрист. Главная защита - документация. Каждое письмо, каждый скриншот, каждый таймстемп. Если всё зафиксировано правильно - в случае конфликта вам есть что предъявить. Если хочется отработать полный цикл от разведки до отчёта в контролируемой среде - на HackerLab.pro (https://hackerlab.pro) есть категории web и pentest с задачами разного уровня, где можно набить руку без юридических рисков.