Современное состояние и будущее развитие системы CVE

Что такое CVE и зачем она нужна миру

CVE (Common Vulnerabilities and Exposures) – это общепринятая система идентификаторов публично раскрытых уязвимостей. Проще говоря, CVE присваивает каждой уязвимости уникальный код вида CVE-год-номер, сопровождая его кратким описанием. Зачем это нужно? До появления CVE (система запущена в 1999 году) разные производители и исследователи в области безопасности вели собственные базы уязвимостей со своими названиями. Это приводило к путанице: трудно было понять, идет ли речь об одной и той же проблеме, если разные источники называют ее по-разному. CVE решил эту проблему, став единой базой для уязвимостей. Теперь, когда специалисты по защите видят, например, идентификатор CVE-2021-44228 (известную уязвимость Log4Shell), они однозначно понимают, о какой проблеме идет речь, независимо от источника информации. Эта стандартизация значительно упростила обмен информацией об уязвимостях между организациями, инструментами и базами данных, а также повысила совместимость разных средств защиты.

Почему CVE важна?

Она обеспечивает единый реестр уязвимостей, которым пользуются во всем мире: от разработчиков программного обеспечения и служб реагирования на инциденты до сканеров уязвимостей и систем управления патчами. Без CVE каждая компания или государство могли бы вести свои классификаторы, что затруднило бы глобальное сотрудничество в области кибербезопасности. Сейчас же, если обнаружена новая проблема, достаточно присвоить ей номер CVE – и все заинтересованные стороны смогут ее отслеживать через свои инструменты. На базу записей CVE подвязываются другие базы, например, рейтинги критичности CVSS и базы данных наподобие NVD (National Vulnerability Database), которые обогащают CVE-записи дополнительными данными (оценками риска, информацией о затронутых продуктах, способах устранения и пр.).

Связь CVE с MITRE, CISA и DoD.

Системой CVE с момента ее основания управляет некоммерческая организация MITRE Corporation – она выступает координатором программы и так называемым “Root CNA” (о CNA расскажем ниже). MITRE ведет список CVE-записей, поддерживает веб-сайт CVE.org и координирует работу сообщества. MITRE выполняет роль Секретариата программы CVE, предоставляя административную и логистическую поддержку Совету CVE, рабочим группам и другим элементам программы. Это включает в себя управление инфраструктурой программы и координацию с более чем 400 организациями CNA (CVE Numbering Authorities) по всему миру, уполномоченными назначать идентификаторы CVE. Однако MITRE не делает это в одиночку – проект финансируется правительством США. Исторически спонсором выступало Агентство по кибербезопасности и инфраструктурной безопасности (CISA, подразделение Министерства внутренней безопасности США) и ранее – структуры Министерства обороны США (DoD). Проще говоря, американское правительство выделяет средства, а MITRE на эти средства оперирует программой CVE. Финансирование шло по контрактной основе: государство заключает с MITRE контракт на поддержку CVE. Например, в 2024 году стартовал очередной годовой контракт на поддержание системы CVE, и это несколько десятков миллионов долларов. MITRE - уважаемая всем миром организация, которая насчитывает более 9 000 сотрудников, многие из которых задействованы в различных аспектах кибербезопасности, включая CVE, CWE и ATT&CK.

Как уязвимости попадают в базу CVE?

Процесс можно упростить до следующих шагов:

• Исследование и обнаружение. Уязвимости находят исследователи безопасности – специалисты компаний, независимые эксперты, участники bug bounty-программ или команды анализа уязвимостей. Когда находится новая брешь, важно должным образом сообщить о ней разработчику уязвимого продукта (ответственное раскрытие) и присвоить идентификатор.
• Обращение к CNA. За присвоение CVE-номера отвечает уполномоченная организация – CNA (CVE Numbering Authority). Обычно исследователь или компания-производитель сообщают об уязвимости в соответствующую CNA. Если уязвимость найдена в продукте конкретного производителя, часто сам производитель (если он является CNA) выдаст номер CVE. В иных случаях исследователь может обратиться к MITRE или в координационный центр (например, CERT), чтобы те выступили CNA и присвоили номер.
• Выделение CVE-ID. CNA проверяет информацию об уязвимости на соответствие критериям CVE (например, что это действительно новая проблема, а не дубликат уже известной). Затем из резервного пула выделяется уникальный идентификатор CVE и резервируется за данной уязвимостью. Создается запись с номером, описанием проблемы и ссылками на источники (например, советы безопасности производителя, отчеты исследователей).
• Публикация. Информация становится публичной – CVE-запись появляется на официальном сайте CVE List. Первичное содержание записи может быть кратким. Параллельно Национальный институт стандартов и технологий (NIST) через свою Национальную базу уязвимостей (NVD) получает эту запись и дополняет ее техническими деталями: присваивает идентификатор уязвимого продукта (CPE), рассчитывает базовый балл CVSS, указывает тип уязвимости по CWE и т.д. После этой “обогащенной” обработки запись становится доступна через NVD – эту базу многие используют для автоматизированного выгрузки информации. Таким образом, MITRE/CVE обеспечивает идентификатор и описание, а NIST/NVD – детализацию и аналитику по уязвимости.
• Использование. Как только CVE опубликован, производители софта могут ссылаться на него в бюллетенях безопасности, сканеры и SIEM – включать в свои базы для обнаружения, а аналитики – использовать при расследовании инцидентов. Уязвимость получает “жизнь” в экосистеме безопасности под своим номером CVE.

Важно отметить, что CVE каталогизирует только публично раскрытые уязвимости. Если проблема не разглашается или не соответствует определению (например, ошибки конфигурации не всегда получают CVE), то она может не попасть в список. Тем не менее, с ростом сферы ИБ CVE-база разрослась до огромных масштабов – в 2024 году общее число записей CVE превысило 270 тысяч, причём только за один этот год было присвоено свыше 40 тысяч новых идентификаторов. Это свидетельствует и о возросшей активности исследователей, и об увеличении числа программных продуктов, и о том, что CVE стал поистине глобальным реестром уязвимостей.

Вот пример записи CVE-2024-6473 об уязвимости в Yandex Browser, которую выявил Dr.Web.

Роль CNA: кто выдает CVE и как работает процесс

Чтобы справиться с лавинообразным ростом уязвимостей, система CVE изначально задумывалась как децентрализованная, федеративная модель. Ключевую роль в ней играют CNA (CVE Numbering Authorities) – уполномоченные организации, которым делегировано право присваивать CVE-идентификаторы. В начале CVE единственным таким органом была сама MITRE, но уже много лет как сформирована широкая сеть CNA по всему миру.

Кто может быть CNA? Как правило, это организации, напрямую связанные с кибербезопасностью или разработкой ПО, которые способны компетентно обрабатывать сообщения об уязвимостях. Основные категории CNA:

• Производители ПО и оборудования. Крупные вендоры сами выдают CVE для уязвимостей в своих продуктах. Например, Microsoft присваивает CVE всем уязвимостям, которые обнаруживаются в Windows, Office и др. продуктах Microsoft (и выпускает ежемесячные бюллетени Patch Tuesday с этими CVE). Google – CNA для своих проектов (Android, Chrome, облачные сервисы и т.д.), Red Hat – для своего ПО с открытым исходным кодом (Linux-дистрибутивы, JBoss и пр.), Huawei – для оборудования и софта Huawei, Oracle – для БД Oracle, Java и др., Cisco – для сетевого оборудования Cisco, и так далее. Почти каждый крупный производитель софта или железа сегодня является CNA, чтобы оперативно обрабатывать уязвимости в собственной продукции.
• Производители продуктов по информационной безопасности. Некоторые специализированные компании ИБ тоже выступают CNA. К примеру, Rapid7 (создатели Metasploit) – CNA для уязвимостей, которые они исследуют, Tenable (Nessus) и Qualys также имеют статус CNA. Они могут присваивать CVE-ID уязвимостям, обнаруженным их исследовательскими отделами до публичного раскрытия. В России CNA это Касперский и Яндекс.
• Национальные/региональные координаторы (CERT/CSIRT). Организации, которые координируют раскрытие уязвимостей в масштабах страны или отрасли. CERT/CC (координационный центр CERT при Университете Карнеги–Меллон, США) – один из первых CNA, он помогает независимым исследователям присваивать CVE их находкам, особенно если затронуто несколько производителей. JPCERT/CC – японский аналог, выступает CNA для японских компаний и исследований. В Европе действует ряд национальных CERT, являющихся CNA. Например, германский CERT-Bund, китайские организации также подключены к программе CNA (в том числе китайские технологические гиганты).
• Другие. В программу вовлечены и различные фонды и сообщества с узкой специализацией. Скажем, ICS-CERT (в США, сейчас внутри CISA) – CNA для уязвимостей систем промышленной автоматизации и SCADA. В 2023 году самой CISA был присвоен статус Top-Level Root CNA для промышленности и медицинских устройств – то есть CISA курирует выдачу CVE в этих сферах, координируя производителей. Также в роли CNA могут выступать крупные проекты с открытым исходным кодом через выделенных координаторов.

Как работают CNA?

MITRE, как управляющая организация, распределяет пул CVE-номеров между CNA. Каждая CNA получает диапазон идентификаторов (например, блок номеров для определенного года) и резервирует их по мере необходимости. Когда поступает отчет об уязвимости, CNA проводит первичную оценку – попадает ли проблема под критерии CVE (общественная значимость, новизна, реальная эксплуатация и т.д.). Если да, и у уязвимости еще нет номера, CNA присваивает следующий доступный CVE-ID из своего пула. После этого CNA обязана оформить запись – придумать стандартизованное описание (англоязычное), указать затронутые продукты, автора находки, ссылки на патчи или отчеты. Готовая запись направляется в центральную систему CVE для публикации. Многие CNA публикуют CVE одновременно со своими официальными советами по безопасности. Например, Microsoft во вторник обновлений выпускает сразу несколько десятков CVE с подробностями, Red Hat при релизе патчей по Linux выкладывает CVE-описания в своей базе знаний, и т.д.

Важно, что все CNA должны следовать единым правилам (CNA Rules), которые контролируются советом CVE Board. Если какая-то CNA нарушает политику (например, систематически задерживает публикацию или неверно оформляет записи), MITRE и верхнеуровневые координаторы могут вмешаться, вплоть до приостановки её полномочий. Но в целом модель доверительная: сообщество CNA построено на сотрудничестве. По состоянию на 2024 год в программе CVE участвует более 450 организаций из свыше 40 стран в качестве CNA – это впечатляющая глобальная сеть.

Примеры ведущих CNA:

• Microsoft (США) – уязвимости Windows, Azure, etc.
• Google (США) – уязвимости Android, Chrome, открытые библиотеки.
• Red Hat (США) – Linux, Kubernetes, Middleware.
• Oracle (США) – СУБД Oracle, корпоративное ПО.
• Cisco (США) – сетевые устройства, ПО Cisco.
• IBM (США) – программное обеспечение IBM, облачные сервисы.
• Intel, AMD (США) – аппаратные уязвимости в процессорах, микрокоде.
• CERT/CC (США) – координация разнообразных уязвимостей, мультивендор.
• JPCERT/CC (Япония) – национальный координатор, различные продукты.
• Huawei (Китай) – сетевое и телеком оборудование Huawei.
• Alibaba (Китай) – облачные сервисы, софт Alibaba.
• SAP (Германия) – бизнес-приложения SAP.
• Siemens (Германия) – промышленные системы и SCADA.
• ICS-CERT/CISA (США) – промышленное оборудование и медицинские приборы (через участников программы).

Этот список далеко не полный, но дает понять, что CNA – это и ИТ-гиганты, и спецорганизации, и национальные CERT. Такой охват обеспечивает покрытие практически всех сфер – от веб-приложений до встроенных систем. Если где-то появляется новая уязвимость, с большой вероятностью найдется CNA, готовая ей присвоить CVE. Роль MITRE здесь больше координаторская: поддерживать платформу CVE.org, обучать новых CNA, разрешать спорные случаи (например, когда несколько сторон одновременно заявляют разные уязвимости с пересекающимися эффектами) и развивать саму систему (формат записей, правила и пр.).

Процесс через CNA глазами практики: допустим, исследователь нашел критическую уязвимость в базе данных Oracle. Он сообщает об этом Oracle через программу Bug Bounty или напрямую в отдел безопасности. Oracle подтверждает проблему, разрабатывает исправление и к моменту выпуска патча оформляет CVE-запись через свою CNA. Запись CVE-2025-XXXXX появляется на сайте cve.org одновременно с Oracle Security Bulletin. Если же исследователь обнаружил проблему в продукте, у которого нет своей CNA, он может обратиться в “CNA последней инстанции” – это по сути MITRE или назначенные координационные CNA. Например, независимые эксперты нередко идут через CERT/CC. В итоге CVE все равно будет выдан, просто другим путем.

Таким образом, механизм CNA обеспечивает масштабирование системы CVE. Одному центру (MITRE) было бы не под силу своевременно обрабатывать десятки тысяч заявок в год. Распределенная сеть CNA решает эту задачу, хотя и создает новые вызовы – контроль качества данных, консистентность описаний, дублирования. Тем не менее, сообщество справляется: рост числа CNA позволил сократить среднее время присвоения CVE и охватить больше уязвимостей, чем когда-либо.

Идентификаторы уязвимостей в продуктах ИБ (Tenable, Qualys, Rapid7, NGFW, IPS и др.)

Помимо CVE, в индустрии существует множество альтернативных систем идентификации уязвимостей, созданных разработчиками средств защиты или независимыми базами. Техническим специалистам часто приходится сталкиваться с номерами уязвимостей от конкретных вендоров. Важно понимать, что эти системы как правило привязаны к CVE, но не заменяют его. Рассмотрим несколько примеров:

• Сканеры уязвимостей (VA scanners). Популярные продукты для сканирования – Tenable Nessus, QualysGuard, Rapid7 InsightVM (Nexpose) – имеют собственные базы данных уязвимостей и присваивают им внутренние идентификаторы. Например, у Tenable есть понятие Plugin ID: каждый плагин Nessus (проверка на конкретную уязвимость или конфигурационную проблему) имеет числовой идентификатор. У Qualys для каждой уязвимости заводится QID (Qualys ID) – уникальный номер в базе Qualys. У Rapid7 аналогично существуют идентификаторы в базе Nexpose. Эти коды используются внутри отчётов конкретного продукта. Однако они всегда сопровождаются ссылкой на CVE (если соответствующая уязвимость имеет CVE). Так, отчет Qualys по хосту может показывать: QID 110182 – TCP/IP SACK Panic (CVE-2019-11477). QID нужен для внутренней работы платформы Qualys, а CVE – чтобы вы, как клиент, могли сопоставить эту уязвимость с информацией из внешних источников. Аналогично, Tenable в описании плагина укажет связанные CVE.

Почему сканеры не обходятся просто CVE? Дело в том, что один проверочный плагин может покрывать сразу несколько CVE (например, если патч от производителя закрывает десяток разных багов, сканер может одной проверкой определить, установлен патч или нет – соответственно, закрыт весь набор CVE). В таких случаях внутренний ID облегчает агрегирование результатов. Но для прозрачности и сопоставимости все ключевые данные привязаны к CVE. Использовать QID или plugin ID вне контекста конкретного сканера бессмысленно – другой системе они неизвестны. CVE идентификаторы же понимают все.

• Базы уязвимостей в системах обнаружения атак. Продукты класса IDS/IPS (системы обнаружения и предотвращения вторжений) и NGFW (Next-Gen Firewall с функциями IDS) тоже оперируют своими номерами сигнатур или уязвимостей. Например, у сетевых экранов Palo Alto Networks есть база уязвимостей Threat Vault, где каждой сигнатуре соответствует Threat ID. Система IDS Snort использует SID (Snort ID) для правил обнаружения. Эти идентификаторы применяются для логирования и управления правилами. Когда срабатывает IPS, администратор видит, например, “Blocked exploit attempt for MS17-010 (SID 41720, CVE-2017-0144)”. SID – специфичен для Snort правила, но сопровождающий CVE-2017-0144 указывает, что правило ловит эксплоит для конкретной CVE (известная уязвимость SMB, “EternalBlue”). Практически все серьезные вендоры NGFW/IPS включают CVE в описание сигнатур. В отчетах от таких систем можно встретить поля “CVE” наряду с “Signature ID”. Можно ли вместо CVE использовать ID сигнатур? Нет, потому что у разных производителей они разные. Но зная CVE, вы легко найдете, есть ли под нее сигнатура в вашей IPS, или какой Threat ID у Palo Alto ей соответствует, и т.д. Таким образом, CVE служит связующим звеном между базами знаний сканеров и систем обнаружения угроз.
• Проприетарные базы данных уязвимостей. Существуют коммерческие агрегированные базы, не ограниченные только публичными CVE. Например, база VulnDB (ранее от Risk Based Security, теперь Flashpoint) содержит сведения о десятках тысяч уязвимостей, которым по разным причинам не присвоены CVE. Она использует свои идентификаторы (так называемые IDs RBS или VulnDB). Аналогично, старая база OSVDB (Open Sourced Vulnerability DB, ныне не функционирует) имела собственные номера. Но эти решения ориентированы на специалистов-аналитиков и, как правило, сопровождаются мэппингом на CVE там, где он есть. То есть если в VulnDB запись соответствует известной CVE, она будет содержать этот номер. Дополнительная ценность подобных баз – раскрывать информацию, не вошедшую в CVE, но из-за их закрытого статуса они не получили широкого распространения вне круга клиентов.
• Идентификаторы в отчетах производителей. Некоторые крупные вендоры используют собственные системы обозначений уязвимостей в бюллетенях. Например, у Microsoft нумеруются бюллетени безопасности MSXX-YYY (сейчас ушли от этого формата), Oracle присваивает своим advisories номера типа Oracle Critical Patch Update ID, IBM в рамках X-Force обмена также имеет internal IDs. Однако все они включают CVE для каждой конкретной уязвимости. Фактически, индустрия уже давно пришла к тому, что CVE – обязательная часть любого отчета или советника по безопасности. Если вдруг CVE отсутствует, это воспринимается как аномалия. Так бывает либо в очень узких случаях, либо когда уязвимость еще не получила CVE и упоминается временно по описательному названию.

Можно ли обойтись без CVE, используя альтернативные базы? Для отдельной организации – теоретически да, но это крайне неудобно и чревато пробелами. Представьте, что компания решила ориентироваться только на базу уязвимостей, скажем, своего сканера Qualys. Во-первых, она ограничится теми уязвимостями, которые эта платформа отслеживает (а она, хоть и покрывает многое, всё равно подмножество всех CVE). Во-вторых, при обмене информацией с партнерами или при чтении новостей безопасности ей все равно придется переводить внутренние коды (QID) в общепринятые CVE – иначе ее просто не поймут. Универсальность CVE в том и состоит, что любой инструмент может “говорить” на языке CVE. Поэтому даже коммерческие базы, появлявшиеся как конкуренты (BID от SecurityFocus, OSVDB и др.), в конечном счете не вытеснили CVE, а либо были заброшены, либо стали вспомогательными.

Пример наглядности CVE: В выпусках предупреждений от государственных CERT (например, сигналы об уязвимостях от CISA, CERT-EU, ГосСОПКА в РФ, BDU у ФСТЭК и т.д.) всегда приводятся CVE. Это позволяет специалистам оперативно найти подробности по каждой уязвимости в независимых источниках. Если бы использовались проприетарные номера, пользователям пришлось бы каждый раз самим выяснять соответствие. Поэтому CVE остается основой, а все прочие идентификаторы существуют “надстройками” для внутренних нужд конкретных сервисов.

Таким образом, альтернативные ID в экосистеме безопасности хотя и существуют в большом количестве, играют вспомогательную роль. Они либо ссылаются на CVE, либо покрывают области, где CVE по каким-то причинам недоступен. Но заменить собою CVE они не в состоянии – наоборот, их ценность проявляется только в связке с системой CVE.

Национальная база данных уязвимостей (NVD): расширение и развитие CVE

Одним из ключевых элементов, обеспечивающих практическую полезность и высокую ценность системы CVE (Common Vulnerabilities and Exposures), является Национальная база данных уязвимостей США (NVD, National Vulnerability Database). NVD создана и поддерживается Национальным институтом стандартов и технологий (NIST) США и выступает важнейшим дополнением к базовой информации, предоставляемой CVE.

Что такое NVD и как она связана с CVE?

NVD была официально запущена в 2005 году для дополнения и расширения данных, предоставляемых базой CVE, поддерживаемой MITRE. Если CVE содержит базовую информацию — уникальный идентификатор уязвимости и краткое описание, то NVD существенно расширяет эти данные, предоставляя более глубокий технический анализ и дополнительные метаданные.

Таким образом, каждая запись CVE, поступая в NVD, обогащается:

• Оценками критичности уязвимости по шкале CVSS (Common Vulnerability Scoring System).
• Классификацией типов уязвимостей по стандарту CWE (Common Weakness Enumeration).
• Информацией о затронутых продуктах и версиях в формате CPE (Common Platform Enumeration).
• Ссылками на исправления, патчи, рекомендации и технические отчёты.

Эта дополнительная аналитика делает NVD одним из наиболее востребованных ресурсов в сфере информационной безопасности.

Практическое значение NVD

Специалисты и системы информационной безопасности активно используют базу NVD в следующих сценариях:

• Управление уязвимостями (Vulnerability Management): большинство сканеров уязвимостей (Tenable Nessus, Qualys, Rapid7) интегрируются с NVD, используя её оценки CVSS и информацию о продуктах (CPE, Common Platform Enumeration) для автоматического определения уровня риска и приоритизации задач по исправлению уязвимостей.
• Системы мониторинга и реагирования (SIEM, SOAR, IRP): аналитики используют данные NVD для корреляции событий безопасности и расследования инцидентов. Благодаря чётко структурированной информации по уязвимостям, процесс реагирования становится более быстрым и точным.
• Threat Intelligence (TI): платформы обмена данными об угрозах (например, MISP, ThreatConnect) активно используют данные NVD для обогащения информации о киберугрозах, повышения точности анализа и прогнозирования возможных атак.
• Compliance и аудит: компании и государственные организации опираются на NVD в рамках выполнения требований регуляторов и международных стандартов по информационной безопасности, таких как PCI DSS, ISO 27001, а также локальных нормативов.

Таким образом, NVD существенно расширяет полезность CVE, превращая базовый реестр уязвимостей в мощный аналитический инструмент.

Как связаны различные организации с CVE

Как связаны организации с CVE:

• Правительство США: выделяет бюджет на базу CVE и NVD через агентство CISA.
• CISA: управляет бюджетом и отвечает за госзаказ на обеспечение CVE.
• MITRE: отвечает за координацию и функционирование программы CVE, сотрудничает с CNA, присваивает CVE-ID.
• CNA: уполномоченные организации (вендоры, CERT, исследовательские центры), присваивающие идентификаторы CVE.
• NVD (NIST): берет данные CVE от MITRE и CNA, дополняет их детальной информацией для использования в инструментах ИБ.

Кризис 2024–2025 годов: испытание для системы CVE

В 2024 году программа CVE столкнулась с серьезными вызовами, поставившими под вопрос ее устойчивость. Этот период можно назвать кризисом CVE, затронувшим как оперативную работу (ведение базы), так и фундаментальные вопросы финансирования и управления. Разберем хронологию и суть этих событий.

Проблема с обновлениями NVD.

В конце 2023 года стало известно о сокращении финансирования, которое CISA предоставляла на работу Национальной базы уязвимостей (NVD) при NIST. Между CISA и NIST существовало соглашение о поддержке: порядка $3,7 млн ежегодно шло на анализ уязвимостей и поддержку NVD. В 2023-м эти средства были урезаны (в контексте общих бюджетных сокращений). В результате к началу 2024 года у NIST не хватало ресурсов, чтобы своевременно обрабатывать поток входящих CVE. Напомним, что NVD обогащает записи CVE техническими деталями – для этого нужны аналитики, сервера, поддержка. С сокращением бюджета скорость обработки упала.

Уже к весне 2024 специалисты заметили задержки в появлении новых CVE в NVD. Хотя сами идентификаторы CVE продолжали присваиваться CNA и появляться на сайте CVE.org, NVD не успевала публиковать полные записи. Возник бэклог (необработанная очередь) из тысяч уязвимостей, по которым не были проставлены CVSS-баллы, не описаны продукты, не указаны ссылки на эксплойты и т.д. К марту 2024 NIST официально признал проблему: рост числа уязвимостей (на 32% больше CVE в 2024 году, чем годом ранее) в сочетании с недостатком финансирования привел к тому, что обработка новых записей не успевала за их поступлением. По оценкам на то время, если ничего не менять, к началу 2025 года очередь непросмотренных записей могла превысить 30 тысяч.

Приостановка и усилия по преодолению кризиса.

Такая ситуация вызвала беспокойство в сообществе. Многие инструменты безопасности зависят от данных NVD – если там пробелы, это бьет по качеству работы сканеров, систем управления уязвимостями и т.п. Весной 2024 подключились внешние игроки: CISA начала публиковать свои краткие уведомления о ключевых уязвимостях, независимые фирмы (например, VulnCheck) попытались заполнить паузу, предоставляя аналитику по новым CVE из открытых источников. NIST, со своей стороны, привлек подрядчика (Analygence Labs) для помощи с анализом уязвимостей и начал внедрять автоматизацию. Были анонсированы планы использовать машинное обучение и улучшенные процессы, чтобы повысить пропускную способность обработки CVE. К середине 2024-го появлялись оптимистичные новости, что backlog удастся ликвидировать – по крайней мере, NIST заявлял об ускорении работы к концу года.

Однако полностью решить проблему быстро не удалось. Хотя к осени 2024 часть накопленного долга была разобрана, поток новых уязвимостей не снижался, и нагрузка оставалась высокой. Ситуация стала настолько серьезной, что в начале 2025 года были приняты беспрецедентные меры:

• Пометка старых CVE как “отложенных”. В апреле 2025 NIST объявил, что все не обновленные записи CVE, опубликованные до 1 января 2018 года, получают статус Deferred (отложенные) в базе NVD. Это означало, что ресурсы NIST больше не тратятся на обогащение этих устаревших записей. Проще говоря, решено было оставить без обработки уязвимости старше 7 лет, по которым еще не была добавлена подробная информация, чтобы сосредоточиться на актуальных проблемах. На страницах таких CVE в NVD появилось помечание “Deferred”. По состоянию на апрель 2025 под эту категорию попало около 20 000 записей. Эти CVE по-прежнему существуют в списке, их можно использовать – но в NVD к ним может не быть привычных метрик (CVSS, CPE). Если кто-то из пользователей сообщит уточненные данные или запросит пересмотр, NIST рассмотрит по возможности, но приоритет смещен на новые уязвимости. Этот шаг, по сути, признание: ресурс даже такой организации, как NIST, небезграничен, и надо жертвовать менее актуальным ради своевременного обновления критически важных сведений.
• Риски для организаций. Объявление статуса Deferred вызвало дискуссию среди специалистов по безопасности. Многие отметили, что хоть старые уязвимости и кажутся неактуальными, и ими часто пренебрегают в защитных мерах, зато это делает их удобной мишенью для злоумышленников. Появилось мнение, что теперь компаниям придется самостоятельно пересматривать, не осталось ли у них нерешенных проблем из “Deferred”-списка, потому что больше нельзя полагаться, что NVD держит их на контроле. Тем не менее, большинство согласилось, что при экспоненциальном росте числа новых CVE такой фокус на свежих угрозах был неизбежен. Организациям рекомендовали усилить проактивное управление уязвимостями: не дожидаться обновлений NVD по устаревшим системам, а самим мониторить и устранять даже давние известные баги.
• Угрозы сокращений в NIST. Параллельно ходили тревожные новости, что проблемы с бюджетом могут привести к сокращению персонала, занятого на проектах кибербезопасности. Говорилось, например, о риске увольнения сотен сотрудников NIST, работающих над NVD и смежными инициативами, если финансирование не будет увеличено. В целом в США в 2024–2025 наблюдалось напряжение вокруг бюджетов на ИБ: на фоне политических дискуссий за кулисами обсуждались сокращения расходов на кибербезопасность. Упоминался даже некий правительственный план оптимизации (“DOGE initiative”), способный урезать бюджеты CISA и NIST. Хотя на момент середины 2025 года худшие сценарии не реализованы, одна только перспектива массовых сокращений в ключевых кибераналитических подразделениях вызвала серьезные опасения в профессиональном сообществе.

Перспективы развития NVD

В текущих условиях активно обсуждается необходимость поиска новых моделей финансирования и управления базой NVD, чтобы избежать повторения подобных кризисов. Среди обсуждаемых вариантов:

• Расширение международного сотрудничества и возможное привлечение дополнительных государственных и частных источников финансирования.
• Повышение автоматизации процессов обработки и обогащения данных с использованием технологий искусственного интеллекта и машинного обучения.
• Возможное распределение части функций NVD среди глобальных партнёров и CNA для снижения нагрузки на NIST.

Таким образом, NVD остаётся важным элементом экосистемы CVE и глобальной инфраструктуры информационной безопасности, однако её будущее во многом будет зависеть от способности адаптироваться к новым вызовам и обеспечивать стабильность работы в условиях роста количества уязвимостей.

KEV (Known Exploited Vulnerabilities

Среди тысяч уязвимостей, опубликованных ежегодно в рамках системы CVE, далеко не все эксплуатируются злоумышленниками. Для решения этой проблемы Агентство по кибербезопасности и инфраструктурной безопасности США (CISA) создало специализированный каталог Known Exploited Vulnerabilities (KEV).

Что такое KEV

KEV (Known Exploited Vulnerabilities) — это официальный каталог уязвимостей, которые подтверждённо эксплуатируются в реальных атаках. Каталог поддерживается CISA и регулярно обновляется.

Ключевые характеристики KEV:

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

На 2025 год каталог KEV насчитывает более 1300 уязвимостей и продолжает активно пополняться.

Связь KEV и CVE

Хотя KEV — это самостоятельный каталог, он полностью основан на системе CVE. Каждая запись в KEV ссылается на уникальный идентификатор CVE, например, CVE-2021-34527 (уязвимость PrintNightmare).

Параметр	CVE	KEV
Что описывает	Все публично раскрытые уязвимости	Только подтверждённо эксплуатируемые уязвимости
Управляющая организация	MITRE/CVE Program	CISA (на основе данных о реальной эксплуатации)
Критерии включения	Соответствие техническим требованиям CVE	Факт эксплуатации в реальных атаках

Таким образом, KEV является надстройкой над CVE: он помогает фокусировать внимание на наиболее опасных угрозах, используя стандартизированные идентификаторы CVE для точного сопоставления данных.

Практическая польза KEV для организаций

1. Приоритизация устранения уязвимостей

KEV позволяет организациям быстро выделять среди общего массива CVE те уязвимости, которые требуют немедленных действий. Это существенно повышает эффективность управления уязвимостями.

2. Автоматизация процессов безопасности

KEV интегрирован в популярные системы сканирования уязвимостей (Tenable, Qualys, Rapid7). Это позволяет автоматически проверять наличие уязвимостей из списка KEV в инфраструктуре компании.

3. Обоснование требований к ИТ-подразделениям

На основе KEV можно устанавливать чёткие сроки устранения уязвимостей и аргументированно обосновывать их критичность для бизнеса.

4. Повышение защищённости

Исследования показывают, что использование KEV ускоряет устранение уязвимостей в 3,5 раза по сравнению с традиционным подходом, основанным на общей базе CVE. Например, в государственных учреждениях США 31% уязвимых устройств были защищены от уязвимостей KEV в течение 45 дней.

Угроза остановки CVE в 2025 году.

Если проблемы NVD касались в основном обогащения данных, то весной 2025 под ударом оказалась сама программа CVE в целом. Долгие годы контракт на ведение CVE (между правительством и MITRE) более-менее регулярно продлевался. Однако в апреле 2025 подошел к концу очередной контрактный период, и возникла реальная угроза, что государство не станет дальше финансировать CVE через MITRE. 15 апреля 2025 года CVE Board (управляющий совет программы CVE) получил письмо от MITRE, в котором сообщалось, что по имеющейся информации правительство США не планирует продлевать контракт на управление программой CVE. Фактически, 16 апреля мог стать последним днем, когда MITRE поддерживает CVE, – далее финансирование закончилось бы, и работа остановилась. Для мировой индустрии ИБ это прозвучало шоком: несмотря на все проблемы, CVE воспринимается как “кибер-инфраструктура”, часть повседневной работы тысяч команд безопасности. Резкая потеря этой системы грозила хаосом: от сбоя процессов управления уязвимостями в предприятиях до риска расцвета дезинформации (нет единого источника – сложно отслеживать достоверность данных об эксплойтах). Некоторые эксперты прямо называли возможное закрытие CVE «глупым и опасным» шагом.

Ситуация развивалась стремительно. Вплоть до последней недели апреля не было ясности, будет ли CVE жить. Наконец, в буквально последний момент ведомство CISA объявило, что нашло возможность выделить финансирование и продлить контракт с MITRE еще на 11 месяцев. То есть программа CVE получила временное продление деятельности до марта 2026 года. Эту новость отрасль встретила с облегчением – по крайней мере, “отключения света” удалось избежать. Но в комментариях представители CISA и MITRE признали: дальнейшее финансирование под вопросом, и нужно искать новые пути, чтобы CVE не зависела от прихоти одного бюджетного решения.

Были ли аналогичные кризисы ранее?

Да, программа CVE уже переживала трудности, хотя масштабы тогда были меньше. В 2015–2016 годах возникла проблема задержек с присвоением CVE: из-за ограниченности ресурсов MITRE не успевала обрабатывать все заявки от исследователей. В результате по оценкам независимых экспертов, в 2015 году более 6 тысяч известных уязвимостей так и не получили CVE-идентификаторы вовремя. Это грозило снизить доверие к системе: если значительная часть уязвимостей “выпадает” из CVE, то базы компаний перестают быть полными. Ситуация вызвала резкую критику: исследователи жаловались, что CVE выдается с месячными задержками или вообще отказывается, кроме того, тогда CVE охватывала далеко не все типы проектов (например, было слабое покрытие уязвимостей в открытых библиотеках, IoT и др.). Под давлением сообщества и даже Конгресса США (в 2017 году комитет по энергетике и торговле провел расследование работы CVE) были приняты меры: увеличено финансирование (в 2016 бюджет резко подняли до $4 млн в год с прежних ~$1,2 млн), MITRE начала расширять число CNA, упростила некоторые процессы. К 2018 году система стала более распределенной – CVE Board (включающий представителей индустрии и госструктур) начал активнее управлять стратегией, регулярно пересматривались правила. В итоге кризис 2016 года был во многом преодолен: число присваиваемых CVE ежегодно стабильно росло, а “пропусков” становилось меньше.

Еще один относительно небольшой кризис случился в 2020 году, когда в условиях пандемии и всплеска киберактивности снова стали расти очереди на обработку CVE, но тогда уже была развернута сеть CNA и ситуацию выправили ускоренно. Тем не менее, кризис 2024–2025 выделяется даже на этом фоне: он затронул и финансирование (риски закрытия), и оперативную работу (бэклог в NVD), поставив под сомнение сам принцип, что CVE может полагаться на одного спонсора.

Реакция индустрии и будущие перспективы CVE

Испытания последних лет показали, насколько критична система CVE для кибербезопасности – и одновременно продемонстрировали ее уязвимость организационного характера. Индустрия не осталась в стороне: развернулась активная дискуссия и конкретные действия, чтобы обеспечить устойчивость CVE в будущем. Рассмотрим, какие шаги предпринимаются и в каком направлении может развиваться система.

Создание CVE Foundation

Одной из важнейших инициатив стало объявление о формировании независимого фонда CVE (CVE Foundation). В апреле 2025, на фоне неопределенности с государственным контрактом, несколько влиятельных членов CVE Board (включая ветеранов отрасли) заявили о намерении перевести программу CVE под крыло новой некоммерческой организации. Идея в том, что вместо того, чтобы полностью зависеть от финансирования одного правительства, CVE должна стать глобальным открытым проектом с распределенным финансированием и управлением. CVE Foundation планируется как структура, которая возьмет на себя ответственность за ведение CVE, привлекая средства от разных источников: международных организаций, частных компаний, отраслевых ассоциаций. В заявлении инициаторов прямо говорится, что за 25 лет CVE стала настолько значимой для всего мира, что привязка ее судьбы к одному бюджету США несет риски. Фонд же позволит обеспечить нейтральность и стабильность – даже если какой-то спонсор отпадет, система продолжит работу на средства других участников.

Переход CVE под управление фонда – дело не одномоментное. Хотя контракт с MITRE продлен до 2026, уже началась подготовка к трансформации. Предстоит решить множество вопросов: юридических (передача прав на торговую марку CVE, интеллектуальной собственности на данные), финансовых (как именно собирать деньги: членские взносы, гранты, пожертвования?), организационных (какова будет роль CVE Board, как соотносятся новый фонд и старая структура при MITRE). Но сам факт объявления – это сигнал: индустрия берет будущее CVE в свои руки. К фонду, вероятно, присоединятся крупные технологические компании и службы ИБ, которые заинтересованы в продолжении работы CVE. Можно ожидать, что такие гиганты, как Microsoft, Google, Amazon, международные организации типа FIRST, и даже госструктуры других стран могут выступить спонсорами фонда. Таким образом, финансирование станет более распределенным. Это напоминает модель, как, например, поддерживается разработка важных открытых проектов (Linux Foundation, Apache Foundation и т.п.), где множество участников вкладываются, зная, что получают взамен общую пользу.

Роль CNA и сообщества

В решении проблем большое значение имеет участие самого сообщества CVE – всех CNA и экспертов, причастных к программе. На ежегодных встречах (например, CNA Summit, VulnCon под эгидой FIRST) обсуждаются пути улучшения работы. Один из важных моментов – повышение качества и полноты данных CVE. С одной стороны, рост числа CNA повысил охват уязвимостей, с другой – появилось больше вариативности в описаниях, возможны дубликаты или неполные сведения. Сообщество понимает, что чтобы CVE оставалась ценным ресурсом, нужны единые стандарты качества записей, инструменты автоматической валидации, может быть, даже рейтинг CNA по надежности данных. Некоторые энтузиасты предлагают привнести элементы crowd-sourcing: например, позволять сообществу предлагать улучшения к описаниям CVE, добавлять недостающие подробности (под контролем редакторов CVE). Уже сейчас есть механизм обсуждения в открытом формате черезGitHub для некоторых записей – это направление будет развиваться.

Кроме того, рассматривается более глубокая интеграция с открытыми проектами. Так, Google развивает базу OSV.dev (OSV, Open Source Vulnerabilities) – реестр уязвимостей с открытым исходным кодом, где идентификаторы формируются по схеме GHSA (GitHub Security Advisory) или OSV. Многие из этих уязвимостей также получают CVE через CNA, но OSV позволяет автоматизировать подачу данных от самих авторов open-source. Вероятно, CVE Program и OSV будут теснее сотрудничать, чтобы не дублировать работу, а обмениваться информацией. Возможное будущее – связанная экосистема, где CVE покрывает все публичные уязвимости, независимо от источника, а разные платформы (NVD, OSV, CERT базы) синхронизируются в рамках единого стандартного формата (в 2024 CVE перешла на JSON 5.0, что облегчает обмен данными машинным способом).

Модели устойчивого финансирования.

Помимо фонда CVE, обсуждаются разные варианты, как обезопасить проект от финансовых потрясений. Некоторые идеи:

• Прямое бюджетирование несколькими правительствами. Если один только США не справляется или не хочет полностью финансировать, возможно, подключение союзников. Например, CVE могли бы совместно финансироваться консорциумом из Евросоюза, Японии, Австралии, США – ведь все они заинтересованы. Правда, межгосударственные проекты сложны бюрократически, но прецеденты есть (например, сотрудничество в стандартах безопасности).

• Членские взносы от компаний-пользователей. Крупные корпорации по всему миру, использующие данные CVE/NVD (а это и банки, и производители ПО, и сотовые операторы), могли бы скидываться ежегодно в общую кассу, зная, что инвестиция окупится надежностью базы уязвимостей. Даже если 100 компаний внесут по относительно небольшой сумме, бюджет CVE будет покрыт. Здесь важно организовать это справедливо и прозрачно – вероятно, через тот же фонд.

• Сервисная модель с оплатой. В принципе, все данные CVE открыты, и делать их платными неправильно. Но можно развивать коммерческие сервисы поверх CVE – например, расширенные аналитику, инструменты поиска, API с особыми возможностями – выручку от которых направлять на поддержку основной программы. Это путь, которым идут некоторые открытые проекты, совмещая открытую базу и платные надстройки. Для CVE это менее характерно, но, возможно, NIST или новый фонд рассмотрят вариант предоставления глубокой аналитики за плату заинтересованным клиентам, субсидируя основную функцию.

• Влияние ООН. Агентства ООН (например, ITU и UNODC) рекомендуют странам создавать и развивать национальные CERT/CSIRT, которые, в свою очередь, используют CVE в своей ежедневной работе. Группа правительственных экспертов ООН (UNGGE) и открытая рабочая группа (OEWG) обсуждают проблемы управления уязвимостями и необходимости международной координации, косвенно продвигая важность CVE и аналогичных стандартов. ООН может взять на себя ведение CVE базы или ее финансирование, как важного международного инструмента безопасности.

Пока эти модели в стадии обсуждения. В краткосрочной перспективе ключевую роль сыграет CVE Foundation и продление финансирования CISA. Вероятно, в течение 2025 года станет более понятно, как именно будет структурирована новая схема.

Децентрализованное будущее системы CVE.

Помимо финансовой стороны, кризис заставил задуматься о технологической и организационной устойчивости CVE. Возможные направления эволюции:

• Более распределенное хранение данных. Чтобы CVE List не зависела от одной организации, стоит рассмотреть размещение реплик базы у разных доверенных участников. Например, зеркальные серверы CVE в разных странах, поддерживаемые партнерами. В случае сбоя или атаки (или отключения кого-то от сети) база не пропадет. В современном виде CVE List уже распространяется через скачиваемые архивы, но можно сделать шаг дальше – вплоть до хранения в распределенном реестре (блокчейн или p2p-хранилище) для максимальной отказоустойчивости.

• Автоматизация и ИИ. Объем информации растет, и чтобы не столкнуться снова с человеческим фактором, будут шире применяться алгоритмы. Уже сейчас машинное обучение тестируется для сопоставления описаний уязвимостей с продуктами. В будущем ИИ может помогать черновому составлению CVE-описаний, классификации уязвимостей, выявлению дубликатов. Это снизит нагрузку на экспертов. Конечно, окончательное решение останется за людьми, чтобы избежать ошибок, но рутины станет меньше.

• Усиление роли международных партнеров. Возможно, появятся региональные Root CNA – то есть крупные организации в разных частях света, которые возьмут на себя часть координационных функций, сейчас лежащих на MITRE. Например, теоретически, европейское агентство ENISA могло бы стать европейским хабом CVE, в Азии – JPCERT/CSI, в Латинской Америке – OAS/CERT. Это пока только мысли, но логика федерализации может зайти и так далеко, чтобы убрать “единую точку отказа” в виде американского центра. При этом все они будут следовать единым правилам и синхронизироваться через CVE Board.

• Прозрачность и доверие. Чтобы глобальная община доверяла CVE, нужно избегать ситуации, когда кто-то (будь то правительство или корпорация) может скрыть неудобную уязвимость. Сейчас действуют процедуры эскалации: если, скажем, CNA отказывается присвоить CVE обнаруженной проблеме, исследователь может обратиться к MITRE и совету – и они примут решение. В будущем, возможно, добавят независимый аудит работы CNA и фонда, чтобы исключить злоупотребления (например, опасения, что некоторые вендоры, будучи CNA, могут занижать критичность или задерживать публикацию своих уязвимостей). Полная открытость данных и вовлечение разных сторон должны минимизировать подобные риски.

Заключение

Текущий кризис 2025 года, каким бы неприятным он ни был, послужил своеобразным “стресс-тестом” для системы CVE. Он высветил слабые места (финансовая зависимость, ограниченность человеческих ресурсов на фоне взрывного роста уязвимостей), но также подтвердил жизненную важность CVE – без нее индустрии стало бы существенно сложнее поддерживать безопасность. Реакция сообщества вселяет оптимизм: есть консолидация вокруг идеи сохранить и укрепить CVE. Система за четверть века стала ядром экосистемы кибербезопасности, и, по словам одного эксперта, “мир без CVE был бы куда более хаотичным и опасным”. Поэтому впереди нас ждет трансформация CVE – вероятно, от модели государственно-контрактной к модели общественного блага, поддерживаемого совместно госструктурами, бизнесом и сообществом экспертов. Это будет означать больше сотрудничества на международном уровне, новые источники финансирования и технологическое развитие платформы.

Для технических специалистов (CISO, аналитиков, инженеров ИБ) эти изменения важны в практическом плане. Управление уязвимостями – основа киберзащиты, и CVE остается центром этой деятельности. Следует внимательно следить за обновлениями программы CVE, адаптировать свои процессы: например, учесть, какие CVE помечены Deferred (и проверить, не остались ли у вас такие незакрытые проблемы), обновить инструменты под новые форматы CVE записей, быть готовыми к возможным перебоям и заранее иметь резервные планы (к примеру, локальные копии базы CVE/NVD).

Однако в целом есть основания полагать, что CVE выдержит и этот шторм. Индустрия уже демонстрирует приверженность развитию CVE – ведь все понимают, что в отсутствии единого реестра мы откатимся на десятилетия назад, во времена разрозненных и несовместимых описаний уязвимостей. Можно ожидать, что через пару лет система выйдет на новый уровень более устойчивая, глобальная и современная, сохраняя при этом свою ключевую миссию: идентифицировать, определять и каталогизировать уязвимости, помогая миру эффективно на них
реагировать.

Денис Батранков, директор по развитию продуктов, группа компаний “Гарда”, ведущий канала Топ Кибербезопасности