CVE: как распознать, систематизировать и нейтрализовать уязвимость

ИБ часто трудно определить, какие уязвимости устранять в первую очередь. Без чёткой оценки риска и систематизации непонятно, какие дыры закрывать в первую очередь. CVE помогает структурировать информацию и выстроить процесс управления угрозами с акцентом на реально критичные проблемы.

Почему без CVE — как без карты на минном поле

Сегодня сложно представить работу ИБ-специалиста или системного администратора без упоминания CVE — но так было не всегда. Ещё пару десятилетий назад каждая уязвимость называлась по-разному, хранилась в закрытых базах, нередко дублировалась. Информационные отчёты от разных вендоров не совпадали даже в формулировках — разобраться в происходящем было непросто.

Именно поэтому появился единый стандарт — CVE. Он стал универсальным языком, с помощью которого можно зафиксировать уязвимость, быстро сопоставить её с нужным патчем, эксплойтом, атакой или регуляторным требованием.

Без систематизации таких данных анализ ИБ-инцидентов, тестирование на проникновение или управление уязвимостями не работают. CVE — это инструмент ориентации в ландшафте угроз, основа процессов оценки, реагирования и отчётности.

История и природа CVE

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

Как появилась идея единого списка уязвимостей

До конца 1990-х каждая компания и исследователь описывали уязвимости по-своему. Одни давали имена, другие — внутренние коды, третьи — просто писали об ошибках в продукте.

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

Рост числа записей: от сотен к десяткам тысяч

Первая версия CVE содержала чуть больше 300 записей. Уже к 2010 году реестр насчитывал около 45 000 уязвимостей. Сейчас в год регистрируется более 25 000 новых CVE — в среднем по 70 штук каждый день.

Рост связан не только с увеличением количества угроз. Улучшилось качество поиска: баг-баунти-программы, автоматические сканеры, анализ кода на стадии CI/CD. Всё это наполняет CVE новыми записями быстрее, чем когда-либо. Без такого стандарта следить за безопасностью стало бы просто невозможно.

Программа баг-баунти — привлечение независимых экспертов в области информационной безопасности («белых хакеров», исследователей), которые проверяют ПО на наличие уязвимостей, получая денежное вознаграждение за каждый выявленный дефект.

Что такое запись CVE

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

Формат: CVE‑год‑номер

Каждая запись в CVE имеет уникальный идентификатор. Он начинается с префикса CVE, за которым следует год регистрации и порядковый номер. Например, CVE-2021-44228 — это уязвимость Log4Shell, ставшая причиной массовых атак в 2021 году.

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

Обязательные поля: ID, описание, ссылки, CVSS‑оценка Помимо самого идентификатора, в каждой записи указываются:

• краткое описание уязвимости
• список источников, где она была обнаружена и подтверждена
• ссылки на патчи, эксплойты, бюллетени вендоров
• оценка критичности по шкале CVSS

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

Как назначаются идентификаторы

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

Кто назначает: CNA — распределённая система доверия

Чтобы уязвимость получила CVE‑код, её должен зарегистрировать один из участников глобальной системы CNA — CVE Numbering Authorities. Это доверенные организации, которые уполномочены присваивать идентификаторы от имени всей экосистемы. В числе CNA:

• разработчики ПО (например, Adobe, Oracle, Microsoft)
• команды по реагированию (CERT/CC, JPCERT)
• баг-баунти‑платформы
• независимые лаборатории

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

• Увеличение объёма обработки: в 2024 году поток новых CVE вырос на 32 %, NVD внедряет машинное обучение для ускорения обработки данных NIST.
• Регулярные технические обновления API: NVD регулярно уточняет параметры API, чтобы интеграции с системами безопасности (SIEM, сканеры уязвимостей и др.) оставались актуальными.
• Публикация CVSS-оценок: теперь оценки становятся частью CVE-записей, это упрощает приоритизацию и автоматизацию обновлений

Kaspersky и Yandex — признаны государственными партнёрами MITRE как CNA. Это означает, что они могут присваивать CVE-коды обнаруженным уязвимостям, которые касаются их продуктов или исследований

Процесс регистрации: от инцидента к базе

Сценарий почти всегда одинаков: уязвимость обнаружена — информация передаётся в CNA — запись проверяется, уточняется — CVE‑идентификатор присваивается.

Если уязвимость действительно новая, ранее не зарегистрирована, CNA резервирует за ней номер, добавляет описание, ссылки на отчёты, обсуждения, рекомендации. Некоторые CVE могут оставаться в статусе «зарезервировано» до выхода патча или окончания NDA.

Финальные данные часто дополняются сведениями о вендоре, версии продукта, сценариях эксплуатации, оценкой по CVSS. Благодаря этому каждая CVE‑запись становится универсальной точкой отсчёта для всех, кто работает с угрозами — от разработчиков до регуляторов.

В чем важность CVE

Унификация терминов: например, при упоминании CVE‑ID сразу понятно, о чём речь. CVE сделал то, что раньше казалось невозможным: привёл хаос уязвимостей к единому знаменателю.

Теперь, когда в отчёте, письме, релизе или бюллетене упоминается, например, CVE-2022-30190, никто не путается. Это конкретная уязвимость, известная по имени Follina. Её описание можно найти за секунду, сравнить между источниками, найти патчи или эксплойты.

С CVE не нужно расписывать уязвимость словами, укажите код — сразу понятно, с чем вы имеете дело. Это важно при экстренном реагировании: время уходит на действия и не теряется на поиск.

Связь CVE с CVSS и CWE

Идентификатор уязвимости сам по себе не говорит о её опасности. Для этого используют CVSS — шкалу, которая помогает понять, насколько угроза критична, как быстро на нее реагировать.

CVSS — оценка серьезности уязвимости

CVE даёт идентификатор, но не говорит, насколько опасна уязвимость. Эту задачу решает система CVSS — Common Vulnerability Scoring System. Она присваивает каждой уязвимости числовую оценку — от 0.0 (незначительная) до 10.0 (критическая).

На оценку влияют технические метрики:

• насколько сложно использовать уязвимость
• требует ли она авторизации
• можно ли атаковать удалённо
• влияет ли на доступность, целостность или конфиденциальность

Также учитываются факторы влияния: наличие эксплойта, степень вовлечённости пользователя, прочие.

CVSS помогает сортировать угрозы по приоритету. Например, две CVE могут относиться к одному продукту, но одна будет иметь балл 9.8 (критично), а другая — 3.1 (низкий риск). Это даёт компаниям ориентир, что закрывать в первую очередь.

CWE: откуда берутся уязвимости

Если CVE — это точечное описание конкретной уязвимости, то CWE — Common Weakness Enumeration — описывает, к какому классу относится проблема:

• CWE описывает корень проблемы
• CVE фиксирует проявление этой проблемы в конкретном продукте

CWE (Common Weakness Enumeration) — это открытый каталог типовых ошибок в программном коде, которые могут привести к уязвимостям. Это не конкретные дыры в безопасности, а слабые места в архитектуре, логике или реализации. Например:

• CWE-79 — некорректная обработка пользовательского ввода → XSS (межсайтовый скриптинг).
• CWE-89 — прямое подставление данных в SQL-запрос → SQL-инъекции.
• CWE-22 — путь к файлу формируется на основе пользовательского ввода → directory traversal.

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

В каталоге сотни таких классов, отсортированных по тематикам: работа с памятью, обработка ошибок, шифрование, безопасность API, авторизация, другие.

Каждая CVE‑запись в идеале должна указывать связанный CWE-код. Это поможет разработчикам, тестировщикам понять первопричину, выявить похожие уязвимости ещё на стадии кода до публикации.

CVE и SBOM: как формируется безопасность цепочки поставок

Всё чаще CVE используется в составе SBOM (Software Bill of Materials) — перечня компонентов, входящих в программное обеспечение. Это актуально при импортозамещении, встраивании DevSecOps-практик, аттестации ИСПДн и КИИ.

Зная CVE, можно точно определить уязвимые компоненты в сборке, требуют ли они обновлений, как повлияют на конечный риск. Этот подход активнее применяется в требованиях регуляторов, инициативах по прозрачности цепочек поставок, потому что государство, бизнес, заказчики хотят понимать, что входит в состав ПО, какие уязвимости в нём потенциально присутствуют.

Речь о включении CVE в SBOM — Software Bill of Materials. В нём указано, какие библиотеки, пакеты, фреймворки, зависимости использует ПО. Если в SBOM указано, что внутри есть, например, библиотека Log4j, то по CVE можно сразу проверить, есть ли в ней уязвимости, насколько они критичны.

Поставщики больше не могут «прятать» зависимости. Прозрачность — обязательное условие. Если цепочка поставки непрозрачна, компания может даже не знать, что уязвимость уже внутри её инфраструктуры. Использование CVE в SBOM помогает:

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

Внедрение CVE в SBOM помогает управлять безопасностью на уровне компонентов. Следующий шаг — научиться эффективно применять эти данные в повседневной работе компании и системах защиты.

Мониторинг новых CVE

Национальная база уязвимостей NVD (nvd.nist.gov) публикует обновления ежедневно. Важно настроить автоматические уведомления: подписки, фиды, RSS или интеграцию через API.

Можно использовать инструменты:

• Vulners, Grype, OSV-Scanner, Trivy — для open source и CI/CD
• Tenable, Rapid7, OpenVAS — для инфраструктуры
• интеграции CVE в CMDB, SIEM и XDR-системы.

Управление патчами: автоматизация и приоритеты

Опираясь на CVSS‑оценку из CVE‑записи, можно выстроить очередь обновлений: сначала критические, потом важные, затем остальные. Системы управления обновлениями (WSUS, SCCM, Ansible, Zabbix, SaltStack) работают с CVE как с ключом.

Интеграция с SIEM, CMDB и сканерами

Современные системы безопасности поддерживают автоматическую работу с CVE‑ID. При сканировании они определяют версии компонентов, сравнивают их с базой CVE и выдают список угроз. Это упрощает аудит, реагирование, планирование.

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

БД ФСТЭК, ГОСТы и закон об информации

У ФСТЭК России есть собственная база данных, в которую попадают сведения об уязвимостях, в том числе с указанием CVE‑идентификаторов. Можно отслеживать, какие из уязвимостей признаны значимыми для КИИ, ГИС, ИСПДн и других объектов.

В нормативной документации встречаются ссылки на ГОСТ Р ИСО/МЭК 27002, ГОСТ Р 57580, СТО БР ИББС, а также на N 149-ФЗ. Эти документы формируют юридическую и методическую основу, где CVE становится частью обязательной или рекомендованной практики.

CVE в отчётности и внутреннем контроле

Организации, относящиеся к КИИ, обязаны вести учёт уязвимостей. С помощью CVE‑ID можно унифицировать и упростить процесс. Это удобно для отчётности перед регуляторами или внутреннего аудита.

Итог CVE — это не просто список уязвимостей. Это основа для автоматизации, приоритизации, анализа и безопасности в целом. Если вы ещё не используете CVE в своих процессах — сейчас самое время начать.

Будущее CVE

15 апреля 2025 года завершился контракт между MITRE и US‑CERT. 17 апреля Агентство по кибербезопасности и инфраструктурной безопасности США (CISA) объявило, что финансирование продлено.

Также для стабильной поддержки проекта создан отдельный фонд. Об этом заявили члены правления CVE, объявив о создании некоммерческой организации CVE Foundation. Инфраструктура CVE сохранит непрерывность, а MITRE продолжит координировать работу CNA и публикацию новых записей.

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

Альтернативы без общего стандарта

У CVE есть альтернативы: OSV от Google, Secunia Research, база IBM X‑Force, другие инициативы. Они помогают отслеживать уязвимости, но у каждой — свой формат, свои принципы оценки, свои источники. Без общего стандарта сложно синхронизировать процессы внутри команд, между заказчиками, подрядчиками, на уровне регуляторов.

Главное

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

Связка CVE, CVSS и CWE создаёт полный контекст.
Идентификатор (CVE) указывает на проблему, балл (CVSS) показывает её серьёзность, а класс ошибки (CWE) помогает устранить первопричину. Вместе они позволяют не просто закрывать уязвимости, а строить устойчивую защиту.

С CVE работают все: от DevOps до регуляторов.
Идентификаторы интегрированы в инструменты анализа, отчётности, автоматизации. Они стали универсальным языком, который объединяет безопасность, разработку и аудит.

Российская практика также опирается на CVE.
Бюллетени ФСТЭК, ГОСТы, документы по КИИ и ИСПДн прямо ссылаются на CVE. Это делает базу не только полезной, но и юридически значимой.

CVE нужен каждому, кто отвечает за безопасность.

Не важно, работаете ли вы в ИТ, на стороне бизнеса или у регулятора — без CVE сегодня не обойтись. Пока CVE остаётся центральной точкой в управлении уязвимостями, с ней надо работать.