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

Координированное раскрытие уязвимостей (англ. coordinated vulnerability disclosure)[1] — это модель раскрытия уязвимостей в области компьютерной безопасности, при которой информация о выявленной уязвимости или проблеме становится публичной только после того, как соответствующие ответственные лица получили достаточно времени для устранения (установки патча или иных мер по исправлению) обнаруженного изъяна. Такая координация отличает модель CVD от подхода «полного раскрытия уязвимостей».

Термин «координированное раскрытие» (CVD) вытеснил ранее использовавшийся термин «ответственное раскрытие» (англ. responsible disclosure)[2]. Процесс регламентируется международными стандартами ISO/IEC 29147 и ISO/IEC 30111[3][4].

Описание

Разработчикам аппаратного и программного обеспечения часто требуются время и ресурсы для исправления собственных ошибок. Как правило, подобные уязвимости находят этические хакеры[1]. Многие специалисты по безопасности и исследователи считают своим социальным долгом информировать общественность о подобных недостатках. Сокрытие проблем приводит к иллюзии безопасности. Во избежание этого заинтересованные стороны договариваются и координируют «разумный» срок для устранения проблемы. В зависимости от потенциального эффекта уязвимости, предполагаемого времени на разработку исправления или временного обходного решения, а также других факторов этот период может составлять от нескольких дней до нескольких месяцев.

Современные политики координированного раскрытия уязвимостей часто включают принцип «безопасной гавани» (англ. safe harbor), защищающий добросовестных исследователей, действующих в рамках опубликованной политики, от судебного преследования[2].

Жизненный цикл и участники

Исторически важную роль в процессе координации играл Координационный центр CERT (CERT/CC). С 1988 года он выступал в качестве доверенного посредника между исследователями безопасности и производителями, помогая координировать процесс раскрытия уязвимостей[5].

Жизненный цикл координированного раскрытия уязвимостей включает следующие основные этапы:[3]

  • Обнаружение (англ. Detection): исследователь безопасности обнаруживает потенциальную уязвимость.
  • Уведомление (англ. Reporting): обнаружившая сторона конфиденциально сообщает об уязвимости поставщику продукта.
  • Оценка и подтверждение (англ. Triage and Validation): поставщик подтверждает получение отчёта, проверяет наличие уязвимости и определяет степень её критичности.
  • Координация и исправление (англ. Coordination and Remediation): стороны договариваются о сроках исправления и раскрытия, а разработчики создают исправление (патч).
  • Раскрытие (англ. Disclosure): после выпуска обновления безопасности информация об уязвимости становится публичной.

В процессе координированного раскрытия уязвимостей взаимодействуют несколько ключевых участников:[6]

  • Исследователи безопасности (англ. Security Researchers): обнаруживают уязвимости, ответственно уведомляют разработчиков и соблюдают установленные сроки до публичного разглашения.
  • Разработчики и поставщики (англ. Vendors / Developers): принимают отчёты, анализируют уязвимости, разрабатывают исправления и информируют пользователей.
  • Координаторы (англ. Coordinators): выступают в роли третьей стороны, помогая в коммуникации, техническом анализе и управлении процессом.
  • Конечные пользователи (англ. End-Users): устанавливают выпущенные обновления безопасности и применяют меры защиты.

Связь с Bug Bounty и Full Disclosure

Координированное раскрытие уязвимостей не всегда устраивает исследователей по информационной безопасности, ожидающих финансового вознаграждения за доклады об уязвимостях. В то же время сообщение об уязвимостях с расчетом на вознаграждение некоторыми рассматривается как шантаж[7][8]. Некоторые организации запускают так называемые программы поощрения обнаружения ошибок, чтобы вознаградить сообщения об уязвимостях через официальные каналы. К числу таких организаций относятся Facebook, Google, Barracuda Networks и другие[9].

Координированное раскрытие уязвимостей является фундаментом для легальных платформ Bug Bounty (таких как HackerOne и Bugcrowd)[10][11]. Эти платформы выступают посредниками между исследователями безопасности и организациями, обеспечивая структурированный и безопасный процесс сообщения об уязвимостях и их последующего раскрытия.

Принципиальное различие существует между координированным раскрытием и подходом полного раскрытия (англ. Full Disclosure). При полном раскрытии информация об уязвимости публикуется немедленно после обнаружения, без предварительного уведомления разработчика и предоставления ему времени на исправление. В то время как сторонники полного раскрытия стремятся максимально быстро проинформировать общественность, этот подход создаёт риск массовых атак до выхода патча. Программы Bug Bounty несовместимы с полным раскрытием и построены исключительно на принципах координированного раскрытия, при котором публикация деталей до исправления уязвимости запрещена[12].

Стандартизация и правовое регулирование

Основными международными стандартами в области координированного раскрытия являются ISO/IEC 29147:2018, определяющий методы раскрытия уязвимостей, и ISO/IEC 30111:2019, предоставляющий рекомендации для поставщиков по их обработке и устранению[3].[4]

В США регулирование для федеральных органов власти опирается на рекомендации Национального института стандартов и технологий (NIST) и директивы Агентства по кибербезопасности и защите инфраструктуры (CISA). Специальная публикация NIST SP 800-216 предлагает структуру для управления раскрытием уязвимостей[13]. Операционная директива CISA BOD 20-01 обязывает федеральные агентства разрабатывать собственные политики раскрытия уязвимостей, а также CISA ведёт Каталог известных эксплуатируемых уязвимостей (KEV)[14].[15]

В Европейском союзе требования к координированному раскрытию закреплены в Законе о киберустойчивости (Cyber Resilience Act, CRA). С сентября 2026 года эти требования становятся обязательными для производителей продуктов с цифровыми элементами на рынке ЕС. Закон обязывает производителей уведомлять Агентство ЕС по кибербезопасности (ENISA) и соответствующую национальную группу реагирования на инциденты компьютерной безопасности (CSIRT) в течение 24 часов с момента выявления активно эксплуатируемой уязвимости[16].

Политики раскрытия

Google Project Zero придерживается 90-дневного срока раскрытия, который отсчитывается с момента уведомления вендора об уязвимости: через 90 дней (или раньше, если производитель выпускает патч ранее) детали становятся общедоступными для сообщества специалистов по информационной безопасности[17]. С 2025 года введено правило раннего публичного уведомления: в течение недели после сообщения вендору раскрывается базовая информация об уязвимости (без технических деталей), при этом общие сроки в 90 дней на исправление и дополнительные 30 дней на установку патча сохраняются[18].

ZDI использует 120-дневный срок раскрытия, который начинается после получения ответа от вендора[19]. Помимо стандартных 120 дней, в политику введены сокращённые сроки (30, 60 и 90 дней) для случаев неполного или ошибочного исправления уязвимостей[19].

Компании Microsoft и GitHub применяют гибкий подход без жёстко фиксированных сроков раскрытия. Их политики ориентированы на сотрудничество с исследователями безопасности для совместного устранения проблемы до её публичного обнародования[20].[21]

Примеры

Избранные уязвимости были устранены по схеме координированного раскрытия:

  • Коллизии MD5, позволившие создавать поддельные сертификаты центров сертификации, срок — 1 неделя[22]
  • Гоночные условия/состояния с подарочными картами Starbucks, позволявшие создать дополнительные кредиты, срок — 10 дней (Егор Хомаков)[23]
  • Обнаружение Дэном Камински массовой уязвимости в виде отравления кеша DNS (DNS cache poisoning), срок — 5 месяцев[24]
  • Студенты MIT нашли уязвимость в системе безопасности метрополитена Массачусетса, дело MBTA против Андерсона, срок — 5 месяцев[25]
  • Специалисты Университета Радбауда (Неймеген) взломали защиту карт MIFARE Classic, срок — 6 месяцев
  • Уязвимость Meltdown, аппаратная уязвимость в процессорах Intel x86 и некоторых чипах на основе ARM, срок — 7 месяцев[26]
  • Уязвимость Spectre, связанная с ошибками в реализации прогнозирования переходов и спекулятивного исполнения в современных процессорах, что позволяло получать доступ к данным в виртуальной памяти других процессов; срок — 7 месяцев[26]
  • Уязвимость ROCA, связанная с небезопасно сгенерированными ключами RSA при помощи библиотеки от Infineon и устройств Yubikey, срок — 8 месяцев[27]
  • Уязвимости HTTP/2 «Continuation Flood» (апрель 2024 года), координация раскрытия которых осуществлялась через CERT/CC с множеством вендоров[28].
  • Критическая уязвимость в Fortinet SSL VPN (февраль 2024 года), устранение которой сопровождалось одновременным выпуском патча и публичным уведомлением[29].

Примечания

  1. 1 2 Ding, Aaron Yi. Ethical hacking for boosting IoT vulnerability management // Proceedings of the Eighth International Conference on Telecommunications and Remote Sensing : [англ.] / Aaron Yi Ding, Gianluca Limon De jesus, Marijn Janssen. — Rhodes, Greece : ACM Press, 2019. — P. 49–55. — ISBN 978-1-4503-7669-3. — doi:10.1145/3357767.3357774.
  2. 1 2 CVD: Координированное раскрытие уязвимостей. SecurityLab. Дата обращения: 28 мая 2026.
  3. 1 2 3 BS EN ISO/IEC 29147:2020 Information technology — Security techniques — Vulnerability disclosure. EN-Standard (10 июня 2020). Дата обращения: 28 мая 2026.
  4. 1 2 ISO/IEC 30111:2019 Information technology — Security techniques — Vulnerability handling processes. ITEH Standards (2019). Дата обращения: 28 мая 2026.
  5. The CERT Guide to Coordinated Vulnerability Disclosure. Software Engineering Institute, Carnegie Mellon University. Дата обращения: 28 мая 2026.
  6. FIRST CSIRT Services Framework v2.1.0. FIRST. Дата обращения: 28 мая 2026.
  7. Bug Poaching: A New Extortion Tactic Targeting Enterprises, Security Intelligence (27 мая 2016). Архивировано 23 января 2022 года. Дата обращения: 28 мая 2026.
  8. Extortion or fair trade? The value of bug bounties, InfoWorld (9 сентября 2015). Архивировано 23 января 2022 года. Дата обращения: 28 мая 2026.
  9. Walshe, T.; Simpson, A. C. (2022). “Coordinated Vulnerability Disclosure programme effectiveness: Issues and recommendations”. Computers & Security. 123. DOI:10.1016/j.cose.2022.102936. Дата обращения 2026-05-28.
  10. Crowdsourced Security Glossary. Bugcrowd. Дата обращения: 28 мая 2026.
  11. Coordinated Vulnerability Disclosure. HackerOne Docs. Дата обращения: 28 мая 2026.
  12. Vulnerability Disclosure: What's the Responsible Solution? HackerOne Blog. Дата обращения: 28 мая 2026.
  13. NIST SP 800-216 Final Publication. NIST (май 2023). Дата обращения: 28 мая 2026.
  14. CVD Issue Briefing. NASS (9 марта 2021). Дата обращения: 28 мая 2026.
  15. Known Exploited Vulnerabilities Catalog. CISA. Дата обращения: 28 мая 2026.
  16. CRA Reporting Obligations. European Commission. Дата обращения: 28 мая 2026.
  17. Feedback and data-driven updates to Google's disclosure policy. Project Zero (13 февраля 2015). Дата обращения: 28 мая 2026. Архивировано 15 мая 2021 года.
  18. Google Project Zero to publicly announce vulnerabilities a week after reporting. The Record. Дата обращения: 28 мая 2026.
  19. 1 2 Disclosure Policy. www.zerodayinitiative.com. Дата обращения: 28 мая 2026. Архивировано 25 февраля 2021 года.
  20. Microsoft Slams Public Zero-Day Disclosure, Urges Coordinated Approach. The Hacker News. Дата обращения: 28 мая 2026.
  21. Coordinated Disclosure of Security Vulnerabilities. GitHub Docs. Дата обращения: 28 мая 2026.
  22. MD5 collision attack that shows how to create false CA certificates. Дата обращения: 28 мая 2026. Архивировано 7 мая 2021 года.
  23. Goodin, Dan Researcher who exploits bug in Starbucks gift cards gets rebuke, not love (англ.). Ars Technica (24 мая 2015). Дата обращения: 28 мая 2026. Архивировано 16 мая 2023 года.
  24. Dan Kaminsky discovery of DNS cache poisoning. Дата обращения: 29 апреля 2009. Архивировано 7 июля 2012 года.
  25. MIT students find vulnerability in the Massachusetts subway security. Дата обращения: 28 мая 2026. Архивировано 18 марта 2016 года.
  26. 1 2 Project Zero: Reading privileged memory with a side-channel (3 января 2018). Дата обращения: 28 мая 2026. Архивировано 1 октября 2019 года.
  27. Nemec, Matus; Sys, Marek; Svenda, Petr; Klinec, Dusan; Matyas, Vashek The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli. Дата обращения: 28 мая 2026. Архивировано 12 ноября 2017 года.
  28. В протоколе HTTP/2 выявлена критическая уязвимость, затрагивающая множество проектов. CNews (5 апреля 2024). Дата обращения: 28 мая 2026.
  29. CVE-2024-21762: Fortinet FortiOS SSL VPN Out-of-Bounds Write Vulnerability. Huntress. Дата обращения: 28 мая 2026.

Литература

Категории