На проверке Responsible disclosure уязвимостей: от Bugtraq до правил публикации в 2026 году

По данным Mandiant M-Trends 2025, в 38% подтверждённых инцидентов 2024 года начальный доступ получен через эксплуатацию уязвимостей - первый вектор атак, обогнавший фишинг и компрометацию через подрядчиков. IBM X-Force Threat Intelligence Index 2025 фиксирует среднее время от публикации CVE до реального устранения в организациях - 29 месяцев. Двадцать девять. Между этими двумя числами живёт вся боль дисклоузинга: исследователь нашёл баг, vendor тянет с патчем, а каждый день задержки - открытое окно для атакующих. Те собирают информацию через открытые технические базы (T1596, Search Open Technical Databases) и сканируют конкретные цели на наличие этих уязвимостей (T1595.002, Vulnerability Scanning). Как опубликовать находку так, чтобы защитить пользователей, а не вооружить злоумышленников?

История дисклоузинга уязвимостей: от Bugtraq до coordinated disclosure​

Bugtraq появился в ноябре 1993 года - мейлинг-лист для обсуждения уязвимостей в Unix-системах. Идея была радикально простой: если vendor молчит - публикуем баг открыто, и рыночное давление заставит выпустить патч. На протяжении 1990-х и 2000-х Bugtraq и его наследник Full Disclosure mailing list (запущенный в начале 2000-х Джоном Картрайтом, впоследствии архивированный на seclists.org) сформировали целую культуру. Независимый исследователь воспринимался не как угроза, а как союзник безопасности.

Проблема - в крайностях. Полная публикация exploit-кода до выхода патча давала атакующим готовый инструмент. Vendor'ы в ответ начали угрожать судебными исками - и исследователи замолкали. Ни один из полюсов не работал.

К середине 2000-х индустрия пришла к промежуточной модели - coordinated vulnerability disclosure (CVD). Исследователь уведомляет vendor'а приватно, даёт фиксированный дедлайн, после выхода патча или истечения дедлайна публикует advisory. Google Project Zero в 2014 году ввёл жёсткое правило 90 дней, ставшее ориентиром для индустрии: через три месяца детали уязвимости раскрываются вне зависимости от готовности патча.

Bugtraq возрождение: что осталось от мейлинг-листов​

Bugtraq фактически умер задолго до формального закрытия - рассылка резко снизила активность к середине 2010-х, а сервис прекратил существование в начале 2020-х. Seclists.org по-прежнему хостит полный архив Full Disclosure, но формат мейлинг-листа уступил место bug bounty платформам и GitHub Security Advisories. Само слово «Bugtraq» стало нарицательным - обозначает не конкретную площадку, а саму идею: исследователь имеет право на публикацию, если vendor игнорирует отчёт. Этот принцип - фундамент всех современных disclosure policy.

Full disclosure vs responsible disclosure: три модели публикации уязвимостей​

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

Private disclosure. Исследователь передаёт информацию vendor'у и не публикует ничего самостоятельно. Решение о раскрытии - целиком на стороне vendor'а. Большинство bug bounty программ работают именно так. Ограничение очевидно: если vendor решит замолчать уязвимость, пользователи никогда не узнают об угрозе. Я видел случаи, когда баг тихо фиксили без CVE, без advisory, без единого слова - как будто его и не было.

Full disclosure. Полные детали уязвимости (включая exploit code) публикуются сразу после обнаружения, часто до выхода патча. OWASP Cheat Sheet прямо называет подход «крайне противоречивым и воспринимаемым многими как безответственный». В контексте MITRE ATT&CK такая публикация даёт атакующим готовый материал для Resource Development - они собирают информацию об уязвимостях для последующей эксплуатации (T1588.006 - Vulnerabilities) и получают готовый инструмент для Exploit Public-Facing Application (T1190, Initial Access). Применяется как крайняя мера - когда vendor месяцами игнорирует отчёты или когда exploit уже в дикой природе.

Coordinated vulnerability disclosure. Де-факто стандарт в 2026 году. Приватное уведомление vendor'а → согласование дедлайна (обычно 90 дней, до 120 для сложных случаев) → выход патча → публикация advisory. ISO/IEC 29147 (Vulnerability disclosure) и ISO/IEC 30111 (Vulnerability handling processes) формализуют этот процесс на уровне международных стандартов - на них ссылаются vendor'ы в своих disclosure policy.

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

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Два правила, которые спасают репутацию. Первое: редактируйте персональные данные перед отправкой. Если в PoC засветились чужие сессии или credentials - замажьте их. Второе: сохраняйте доказательства. OWASP Cheat Sheet предупреждает: «Некоторые организации могут попытаться заявить, что уязвимости не существовало». Скриншоты с таймстемпами, сохранённые HTTP-ответы, видеозапись - ваша страховка.

Тон первого письма - нейтральный. Дедлайн формулируется как факт, а не как угроза: «В соответствии со стандартной практикой coordinated disclosure планирую опубликовать advisory по истечении 90 дней или после выхода патча - в зависимости от того, что наступит раньше.»

CVE публикация и присвоение номера​

CVE-номер - уникальный идентификатор уязвимости в базе MITRE. Для исследователя наличие CVE в advisory повышает видимость находки и ценность строки в резюме (а для cert_seekers это вообще отдельная валюта).

Процесс получения CVE:

1. Через CNA (CVE Numbering Authority) - если vendor является CNA (Microsoft, Google, Apple, Red Hat и сотни других), он присвоит CVE сам при подтверждении уязвимости. Достаточно упомянуть в отчёте: «Прошу присвоить CVE-идентификатор».
2. Через MITRE напрямую - если vendor не является CNA или молчит. Заполняете форму на cve.mitre.org: описание уязвимости, affected product/version, тип уязвимости (CWE), references.
3. Через GitHub Security Advisories - для open-source. Создаётся draft advisory в репозитории, GitHub как CNA присваивает CVE автоматически. Самый быстрый путь для open-source проектов.

Правильная практика - резервировать CVE параллельно с отправкой отчёта vendor'у (через MITRE или GitHub CNA), а если vendor сам является CNA - дождаться подтверждения уязвимости для присвоения номера. CVE резервируется до публикации и раскрывается одновременно с advisory.

Bug bounty дисклоузинг: площадки и safe harbor​

Bug bounty программы решают две главные боли исследователя: «кому писать» и «не посадят ли». Платформы выступают посредниками и дают юридическую рамку - safe harbor: если вы действуете в рамках scope и правил программы, компания обязуется не преследовать вас юридически.

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

Нюансы, которые часто упускают:

• Налоги. Выплаты по bug bounty - доход. OWASP напоминает: «Обеспечение отчётности по этому доходу и уплата соответствующего налога - ваша ответственность.» Сюрприз для тех, кто думал, что $500 от HackerOne - это просто приятный бонус.
• Рабочий контракт. Уязвимость, найденная в ходе рабочих обязанностей или на оборудовании работодателя, может принадлежать работодателю. Перед участием в программах - перечитайте трудовой договор.
• Вымогательство. Формулировка «заплатите, иначе опубликую» - уголовное преступление независимо от критичности бага. Без вариантов.

Для российского контекста: Standoff Bug Bounty (Positive Technologies) и BI.ZONE Bug Bounty - основные площадки с программами крупных компаний. Safe harbor определяется условиями конкретной программы, единого федерального закона о защите исследователей пока нет.

0-day публикация: этика и красные линии​

Vendor не отвечает 90 дней. Или ответил, но заявил «это не уязвимость». Или выпустил патч, который ничего не фиксит.

Решение о публикации 0-day - самый сложный момент в практике. Рабочий алгоритм:

1. Документируйте все попытки связи. Даты, каналы, содержание ответов или их отсутствие.
2. Привлеките координатора. CERT/CC, национальный CERT или платформа-посредник могут надавить на vendor.
3. Публикуйте advisory без exploit code. Описание уязвимости, impacted versions, mitigation - да. Рабочий exploit - в подавляющем большинстве случаев неоправданно.
4. Оцените масштаб. IBM X-Force отмечает, что 70% инцидентов, обработанных X-Force в 2024 году, затронули критическую инфраструктуру. Уязвимость в IoT-лампочке и уязвимость в промышленном контроллере - разный уровень ответственности при принятии решения о публикации.

По OWASP Cheat Sheet, full disclosure «следует рассматривать только как крайнюю меру, когда все другие методы не сработали или exploit code уже публично доступен». В рамках NIST CSF 2.0 функция Respond (RS.AN-01) предполагает, что организация умеет принимать отчёты об уязвимостях, а Recover (RC.CO-01) включает управление коммуникациями с исследователем. Если организация эти функции не реализует - это её проблема, но не повод выкладывать exploit в паблик.

Распространено мнение, что coordinated disclosure работает гладко и vendor'ы добросовестно патчат за 90 дней. За 29 месяцами средней задержки между CVE и реальным устранением скрывается другая картина: vendor принимает отчёт, благодарит, присваивает CVE - и откладывает патч на следующий квартал. А потом ещё на один. Исследователь оказывается заложником собственной «ответственности»: он знает об угрозе, пользователи под ударом, но дедлайн уже продлён дважды по вежливой просьбе vendor'а. Google Project Zero решил это для себя - но независимый исследователь, не имеющий за спиной корпорации, часто прогибается.

Моя позиция: дедлайн - это дедлайн. Если в первом письме указано «90 дней» - через 90 дней публикуется advisory. Без exploit code, но с полным описанием. Единственное исключение - vendor показал конкретный таймлайн с датой выхода патча в пределах двух-трёх дополнительных недель. Не расплывчатое «мы работаем над этим», а «патч выходит 15 числа в рамках планового релиза». Всё остальное - манипуляция, прикрытая вежливыми email'ами. Навык оформления vulnerability advisory - не теоретическое знание. Это практический скилл, который отделяет рабочий отчёт от бесполезного тикета. На WAPT цикл «нашёл уязвимость → воспроизвёл → оформил advisory» проходят на лабах с ментором, и формат отчёта ровно тот, что ждут и vendor, и экзаменатор на OSCP.