АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Common Vulnerabilities and Exposures

Common Vulnerabilities and Exposures (CVE, с англ. — «Общие уязвимости и экспозиции», первоначально — Common Vulnerability Enumeration англ. Common Vulnerability Enumeration)[1] — система, предоставляющая метод для унифицированного справочного обозначения известных публичных информационно-безопасностных уязвимостей и экспозиций. Система поддерживается федеральным Исследовательским и инженерно-разработческим институтом по вопросам инженерии и развития систем безопасности на родине (Homeland Security Systems Engineering and Development Institute FFRDC), управляемым корпорацией The MITRE Corporation и финансируемым Национальным подразделением кибербезопасности Министерства внутренней безопасности США (National Cyber Security Division, US Department of Homeland Security)[2]. Система была официально запущена для широкой публики в сентябре 1999 года[3].

Протокол автоматизации контента безопасности использует CVE, а идентификаторы CVE публикуются в системе MITRE и лежат в основе Национальной базы данных уязвимостей США (National Vulnerability Database, NVD)[4].

В 2025 году был зафиксирован рекордный рост числа публикуемых уязвимостей (более 48 тысяч за год), в результате чего общее количество записей в базе превысило 300 тысяч[5].

Идентификаторы CVE

Согласно документации корпорации MITRE, идентификаторы CVE (также называемые «имена CVE», «номера CVE», «CVE-ID», «CVE») — это уникальные, общие идентификаторы для публично известных уязвимостей в программных пакетах, находящихся в публичном доступе. Ранее идентификаторы CVE имели статус «кандидата» (CAN-) и могли быть затем утверждены в реестр CVE, однако эта практика была прекращена в 2005 году[6][7], и в настоящее время все идентификаторы присваиваются как CVE. Присвоение номера CVE не гарантирует, что он станет официальной записью CVE (например, номер может быть ошибочно присвоен проблеме, не являющейся уязвимостью, или дублировать существующую запись). Если запись не соответствует критериям, MITRE или орган присвоения номеров CVE (CVE Numbering Authority, CNA) может пометить её как REJECTED.

Назначением CVE занимаются органы присвоения номеров CVE (CNA)[8]. Хотя некоторые поставщики действовали в качестве CNA и ранее, само название и статус были официально введены только 1 февраля 2005 года[9]. Благодаря переходу к федеративной модели число CNA превысило 400, а к 2026 году составило более 500 организаций[10]. Основные типы назначений CVE:

  1. Корпорация MITRE выступает главным редактором и основным CNA;
  2. Различные CNA назначают номера для своих продуктов (например, Microsoft, Oracle, HP, Red Hat);
  3. Третья сторона-координатор, такая как CERT Coordination Center, может назначать номера для продуктов, не охваченных другими CNA;
  4. В одном случае роль CNA была предоставлена отдельному исследователю[11].

При расследовании уязвимости или потенциальной уязвимости рекомендуется получать номер CVE на ранних этапах. Иногда номера CVE могут не появиться в базах MITRE или NVD сразу (в течение дней, недель, месяцев или даже лет) из-за эмбарго (номер CVE присвоен, но проблема пока не раскрыта), либо если MITRE не успела исследовать и задокументировать запись. Преимущество раннего присвоения CVE состоит в том, что все последующие коммуникации могут ссылаться на единый идентификатор.
Информацию о получении идентификаторов CVE для проектов с открытым исходным кодом публикуют Red Hat Inc.[12] и GitHub[13].

CVEs присваиваются только публично выпущенному ПО, включая «беты» и иные ранние версии, если они широко используются. Коммерческое ПО классифицируется как публично выпущенное, но индивидуальные, не распространяемые программы исторически не получали номер CVE. В течение первых двух десятилетий программы сервисы (например, веб-почтовый провайдер) не получали CVE за найденные уязвимости, если уязвимость не затрагивала отдельный публично доступный программный продукт. Отдельные CNA, включая MITRE, присваивали CVE сервисным уязвимостям по крайней мере с 2000 года[14]. Согласно «Правилам функционирования CNA» (версия 4.1.0 от мая 2025 года), тип технологии (включая облачные сервисы и SaaS) больше не может быть единственным основанием для отказа в присвоении CVE[15][16].

Формат данных и поля CVE

По состоянию на 2026 год актуальным форматом записи CVE является схема CVE JSON 5.x (в частности, версия 5.1), использующая контейнерную модель. Обязательными элементами записи являются метаданные, включающие уникальный идентификатор уязвимости (cveId), и контейнер от назначающего центра нумерации (cna)[17].

Формат версии 5.1 официально интегрировал поддержку метрик CVSS v4.0 в виде отдельного объекта[18].

Описание

Это стандартизированное текстовое описание проблемы. Одной из распространённых записей является:

RESERVED Эта запись зарезервирована организацией или частным лицом, которое будет использовать её при объявлении о новой угрозе безопасности. Когда данные будут опубликованы, детали по этой записи будут предоставлены.

Это означает, что номер записи зарезервирован MITRE или CNA. Поэтому, когда CNA запрашивает блок номеров CVE заранее (например, Red Hat запрашивает сразу по 500), номер будет помечен как зарезервированный, даже если он ещё некоторое время не был назначен CNA какому-либо инциденту. До присвоения конкретному инциденту запись будет числиться как " RESERVED ".

Дата создания записи

Это дата, когда была создана запись. Для номеров, присвоенных напрямую MITRE, — дата создания MITRE; для номеров от CNA — также дата занесения MITRE, а не самой CNA. При выделении блока номеров CNA (например, Red Hat запрашивает блок в 500 CVE), датой будет момент выделения блока CNA.

Устаревшие поля

Следующие поля ранее использовались в CVE, но сейчас не применяются:

  • Phase: стадия прохождения CVE (CAN, CVE).
  • Votes: голосование участников совета за принятие/отклонение CAN в CVE.
  • Comments: комментарии.
  • Proposed: дата выдвижения на рассмотрение.

Изменения синтаксиса

Для поддержки CVE-идентификаторов свыше формата CVE-ГОД-9999 (проблема «CVE10k»[19]) синтаксис CVE был изменён в 2014 году и вступил в силу 13 января 2015 года[20].

Новый синтаксис CVE-ID: переменная длина и включает в себя

CVE-префикс + год + произвольное количество цифр

Переменная часть начинается с четырёх цифр и расширяется только при необходимости в пределах календарного года: например, CVE-YYYY-NNNN, затем — CVE-YYYY-NNNNN, CVE-YYYY-NNNNNN и так далее. Новая схема совместима с предыдущими CVE-ID (не менее 4 цифр).

Данный формат полностью готов к обработке более 100 000 уязвимостей в год[21]. Для автоматизации массового резервирования идентификаторов CNA используют программный интерфейс CVE Services API (версии 2.1)[22][23], который строго валидирует синтаксис и соответствие записей схеме CVE JSON 5.x[17].

Разделение и объединение CVE

CVE стремится выделять по одной записи на каждый инцидент, однако во многих случаях это привело бы к огромному количеству номеров (например, при множественных уязвимостях кросс-сайтового скриптинга в приложении PHP и несовершённом использовании функции htmlspecialchars() либо небезопасном создании файлов в /tmp)[24].

Для решения этой ситуации действуют правила абстракции, описывающие критерии разделения и объединения случаев как отдельных CVE. Согласно актуальным операционным правилам CNA, основным критерием для разделения уязвимостей является принцип «независимой исправляемости» (Independently Fixable) — если проблемы можно исправить независимо друг от друга, им присваиваются разные идентификаторы CVE[25]. Также при разделении могут учитываться тип уязвимости (например, buffer overflow против stack overflow), затронутые версии ПО (если одна уязвимость затрагивает 1.3.4–2.5.4, другая — 1.3.4–2.5.8, их разделяют) и источники обнаружения (например, если Алиса сообщает об одной проблеме, а Боб — о другой, уязвимости разделяются на отдельные CVE)[24].

Пример: Алиса сообщает об уязвимости создания файла в /tmp в ExampleSoft до версии 1.2.3; дополнительно обнаружено несколько подобных уязвимостей. В ряде случаев это могут быть два источника — и тогда записи разделяют, а если остальные найдены внутренней командой ExampleSoft — возможно сливают в одну запись. Обратно — если Боб нашёл 145 XSS-уязвимостей в ExamplePlugin для ExampleFrameWork (независимо от версий), их допустимо объединить[24].

Поиск по CVE

Официальным инструментом для поиска в базе данных CVE является «CVE List Keyword Search» на сайте cve.org[26]. Поиск по Национальной базе данных уязвимостей (NVD) осуществляется по адресу nvd.nist.gov[27]. С апреля 2026 года NIST изменил операционную модель NVD и теперь приоритетно анализирует уязвимости, включённые в каталог известных эксплуатируемых уязвимостей (KEV) CISA, а также затрагивающие критически важное программное обеспечение[28].

Применение CVE

Идентификаторы CVE используются для идентификации уязвимостей:

Common Vulnerabilities and Exposures (CVE, Общие уязвимости и экспозиции) — это словарь общих наименований (CVE-идентификаторов) публично известных уязвимостей в области информационной безопасности. Идентификаторы CVE облегчают обмен данными между отдельными базами и инструментами сетевой безопасности, формируя основу для оценки покрытия средств защиты организации. Если отчёт от вашего инструмента содержит идентификатор CVE, вы можете быстро и корректно получить данные об исправлении из одной или нескольких баз данных, совместимых с CVE, для устранения проблемы[29].

Пользователям, которым был присвоен идентификатор CVE по уязвимости, рекомендуется указывать этот идентификатор во всех связанных отчётах, на веб-страницах, в электронных письмах и прочем.

В современных системах кибербезопасности идентификаторы CVE глубоко интегрированы в платформы автоматизации и оркестрации, такие как SIEM (Security Information and Event Management) и SOAR (Security Orchestration, Automation, and Response). Появление новой критической уязвимости с присвоенным CVE-ID может служить триггером для запуска автоматизированных сценариев реагирования. SIEM-системы используют CVE для обогащения данных об инцидентах, а SOAR-платформы способны автоматически инициировать сканирование инфраструктуры, создавать задачи на устранение и применять компенсирующие меры на основе этих идентификаторов[30].

Использование идентификаторов CVE также стало де-факто обязательным элементом для соблюдения нормативных требований в области кибербезопасности. В частности, они необходимы для выполнения требований Агентства по кибербезопасности и защите инфраструктуры США (CISA) к спецификациям программных компонентов (Software Bill of Materials, SBOM)[31], а также для соответствия европейскому Акту о киберустойчивости (Cyber Resilience Act, CRA), который обязывает производителей управлять уязвимостями на протяжении всего жизненного цикла продуктов[32].

Проблемы назначения CVE

Согласно разделу 7 Правил CNA, производитель, получивший уведомление об уязвимости, полностью самостоятельно управляет дальнейшей процедурой[33]. Это может привести к конфликту интересов, например, если вендор решает не исправлять уязвимость, отказавшись от CVE — и MITRE не может изменить это решение. Проект «!CVE» (или «not CVE»), анонсированный в 2023 году, активно функционирует под названием NotCVE как публичный реестр для уязвимостей, отклонённых вендорами[34][35].

Идентификаторы CVE присваивались и для фиктивных либо не имеющих последствий проблем[36]. В ответ ряд open source-проектов сами стали оформлять статус CNA для своих проектов[37].

Для разрешения споров, в том числе при необоснованном отказе вендора (CNA) в присвоении идентификатора, предусмотрен механизм апелляции. В таких случаях обращение направляется к вышестоящим организациям уровня Root или TL-Root, которые выступают арбитрами и принимают окончательное решение[38].

В 2025—2026 годах программа столкнулась с проблемой задержек (backlog) в обогащении данных со стороны Национальной базы данных уязвимостей (NVD). Из-за рекордного роста числа выявляемых уязвимостей возникло существенное отставание в добавлении оценок критичности и описаний, что потребовало изменения приоритетов обработки записей[39].

Уязвимости искусственного интеллекта

Программа CVE активно адаптируется к уязвимостям в системах искусственного интеллекта. Для изучения влияния ИИ на присвоение идентификаторов и выработки соответствующих стандартов была учреждена специальная рабочая группа CVE AI Working Group[40].

В настоящее время в структуре записей CVE отсутствуют специализированные поля метаданных, предназначенные исключительно для описания ИИ-уязвимостей[41]. Для классификации подобных угроз применяются смежные фреймворки, такие как база знаний MITRE ATLAS, описывающая тактики и техники атак на системы машинного обучения, а также список OWASP Top 10 для приложений на базе больших языковых моделей (LLM)[42][43].

Несмотря на отсутствие отдельных метаданных, уязвимостям в ИИ-системах уже присваиваются стандартные идентификаторы CVE. В частности, официально регистрируются такие специфические векторы атак, как внедрение инструкций (промпт-инъекции)[40][44]. Примерами служат уязвимости в приложениях и инструментах разработки, использующих ИИ, такие как CVE-2025-32711 (уязвимость внедрения команд в M365 Copilot) или CVE-2025-54135 (промпт-инъекция в редакторе Cursor).

Финансирование и управление

В апреле 2025 года была создана некоммерческая организация CVE Foundation, целью которой является долгосрочная диверсификация источников финансирования и снижение зависимости программы от правительства США[45][46].

Кризис финансирования программы был успешно разрешён в 2026 году: Агентство по кибербезопасности и защите инфраструктуры США (CISA) перевело финансирование в защищённую статью бюджета, полностью обеспечив её работу[47].

Операционное управление программой по-прежнему осуществляет корпорация MITRE[47].

Примечания

  1. ↑ CVE — Towards a Common Enumeration of Vulnerabilities (18 апреля 2025). Дата обращения: 27 апреля 2026. Архивировано 18 апреля 2025 года.
  2. ↑ CVE — Common Vulnerabilities and Exposures. Mitre Corporation (3 июля 2007). — «CVE финансируется подразделением National Cyber Security Division Министерства внутренней безопасности США.» Дата обращения: 27 апреля 2026. Архивировано 19 декабря 2020 года.
  3. ↑ CVE - History, cve.mitre.org. Архивировано 8 января 2020. Дата обращения: 27 апреля 2026.
  4. ↑ CVE - Common Vulnerabilities and Exposures (CVE). cve.mitre.org. Дата обращения: 27 апреля 2026. Архивировано 7 апреля 2013 года.
  5. ↑ 2025 Wrapped: The Year Vulnerabilities Broke Every Record. MazeHQ. Дата обращения: 27 апреля 2026.
  6. ↑ CVE - Frequently Asked Questions. cve.mitre.org. Дата обращения: 27 апреля 2026. Архивировано 10 апреля 2018 года.
  7. ↑ Kouns, Jake Reviewing(4) CVE. OSVDB: Everything is Vulnerable (13 августа 2009). Дата обращения: 27 апреля 2026. Архивировано 1 сентября 2021 года.
  8. ↑ CVE - CVE Numbering Authorities. MITRE Corporation (1 февраля 2015). Дата обращения: 27 апреля 2026.
  9. ↑ CVE - CVE Blog "Our CVE Story: Ancient History of the CVE Program – Did the Microsoft Security Response Center have Precognition?" (guest author). cve.mitre.org. Дата обращения: 27 апреля 2026.
  10. ↑ 400 CNAs? Yay! jericho.blog (12 августа 2024). Дата обращения: 27 апреля 2026.
  11. ↑ CVE - CVE Blog "My CVE Story: How I Became the CVE Program's First Vulnerability Researcher CNA" (guest author) (15 марта 2021). Дата обращения: 27 апреля 2026. Архивировано 15 марта 2021 года.
  12. ↑ CVE OpenSource Request HOWTO. Red Hat Inc. (14 ноября 2016). — «Способы подачи заявки зависят от требований.» Дата обращения: 27 апреля 2026.
  13. ↑ About GitHub Security Advisories. GitHub. — «GitHub Security Advisories строится на основе списка CVE». Дата обращения: 27 апреля 2026. Архивировано 23 декабря 2021 года.
  14. ↑ CVE - CVE-2000-0081 (4 декабря 2021). Дата обращения: 27 апреля 2026. Архивировано 4 декабря 2021 года.
  15. ↑ CNA Rules changes. GitHub. Дата обращения: 27 апреля 2026.
  16. ↑ CNA Rules v4.1.0 in Effect. cve.org (20 мая 2025). Дата обращения: 27 апреля 2026.
  17. ↑ 1 2 CVE Record Format Schema Documentation. cveproject.github.io. Дата обращения: 27 апреля 2026.
  18. ↑ CVE Record Format Schema Releases. GitHub. Дата обращения: 27 апреля 2026.
  19. ↑ Christey, Steven M. CVE - The CVE-10K Problem. cve.mitre.org. MITRE Corporation (12 января 2007). Дата обращения: 27 апреля 2026.
  20. ↑ CVE - CVE ID Syntax Change. cve.mitre.org (13 сентября 2016). Дата обращения: 27 апреля 2026.
  21. ↑ CVE volumes may plausibly reach 100,000 this year. Computer Weekly. Дата обращения: 27 апреля 2026.
  22. ↑ CVE Services FAQs. cveproject.github.io. Дата обращения: 27 апреля 2026.
  23. ↑ CVE Services Transition. cveproject.github.io. Дата обращения: 27 апреля 2026.
  24. ↑ 1 2 3 CVE Abstraction Content Decisions: Rationale and Application (Archived). Mitre Corporation (15 июня 2005). Дата обращения: 27 апреля 2026. Архивировано 20 августа 2023 года.
  25. ↑ What is a CVE? Snyk Learn. Дата обращения: 27 апреля 2026.
  26. ↑ Search Tips. cve.org. Дата обращения: 27 апреля 2026.
  27. ↑ National Vulnerability Database. nvd.nist.gov. Дата обращения: 27 апреля 2026.
  28. ↑ NIST Updates NVD Operations to Address Record CVE Growth. nist.gov (апрель 2026). Дата обращения: 27 апреля 2026.
  29. ↑ CVE - About CVE. cve.mitre.org. Дата обращения: 27 апреля 2026.
  30. ↑ Учет уязвимостей CVE: как это работает и почему это важно. Дата обращения: 27 апреля 2026.
  31. ↑ 2025 Minimum Elements for a Software Bill of Materials (SBOM). CISA.gov (август 2025). Дата обращения: 27 апреля 2026.
  32. ↑ EU Cyber Resilience Act (CRA) Requirements Guide. Armorcode. Дата обращения: 27 апреля 2026.
  33. ↑ CVE Numbering Authority Rules - Assignment Rules 13–15. MITRE Corporation (1 февраля 2020). Дата обращения: 27 апреля 2026. Архивировано 7 декабря 2023 года.
  34. ↑ Edge, Jake Supplementing CVEs with !CVEs. lwn.net (5 декабря 2023). Дата обращения: 27 апреля 2026. Архивировано 21 февраля 2024 года.
  35. ↑ About NotCVE. NotCVE (6 сентября 2024). Дата обращения: 27 апреля 2026.
  36. ↑ Edge, Jake The bogus CVE problem. lwn.net (13 сентября 2023). Дата обращения: 27 апреля 2026.
  37. ↑ A turning point for CVE numbers. LWN.net (14 февраля 2024). Дата обращения: 27 апреля 2026. Архивировано 22 февраля 2024 года.
  38. ↑ CVE Record Dispute Policy. cve.org. Дата обращения: 27 апреля 2026.
  39. ↑ NIST объявил об изменениях в обработке NVD из-за резкого увеличения числа сообщений о CVE. Хабр. Дата обращения: 27 апреля 2026.
  40. ↑ 1 2 CVE описывают промпт-атаки на GenAI-модели. Хабр. Дата обращения: 27 апреля 2026.
  41. ↑ Need for AI vulnerability classification. oulurepo.oulu.fi. Дата обращения: 27 апреля 2026.
  42. ↑ MITRE ATLAS — обширная база знаний о тактиках и техниках злоумышленников. Хабр. Дата обращения: 27 апреля 2026.
  43. ↑ OWASP Top 10 для LLM 2025. trydeepteam.com. Дата обращения: 27 апреля 2026.
  44. ↑ CVE-2025-2320 Detail. nvd.nist.gov. Дата обращения: 27 апреля 2026.
  45. ↑ The CVE Foundation Launches to Ensure Long-Term Viability, Stability, and Independence of the CVE Program. The CVE Foundation (16 апреля 2025). Дата обращения: 27 апреля 2026.
  46. ↑ CVE Foundation seeks diversified funding sources after program’s near-death experience. CyberScoop. Дата обращения: 27 апреля 2026.
  47. ↑ 1 2 CVE Program funding secured, easing fears of repeat crisis. CSO Online. Дата обращения: 27 апреля 2026.

Ссылки

Категории