Блог CodeScoring

Что такое CVE и CWE и зачем они нужны в композиционном анализе

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

Что такое CVE

Common Vulnerabilities and Exposures (CVE) – это программа учета публично раскрытых уязвимостей. Ее задача – дать каждой известной уязвимости единый идентификатор, чтобы исследователи, вендоры и пользователи говорили об одной и той же проблеме.
CVE была запущена MITRE в 1999 году как совместная инициатива сообщества и участников индустрии безопасности. Сейчас это программа с распределенной моделью работы: в ней есть управляющие группы и авторизованные организации, включая CNA (CVE Numbering Authority). CNA отвечает за присвоение CVE ID и публикацию записей в своей области ответственности. В этой роли могут выступать вендоры, фонды открытого кода, исследовательские центры или координаторы раскрытия уязвимостей.
Отдельная запись CVE – это карточка конкретной уязвимости. В ней обычно имеются следующие поля:
  • CVE ID – уникальный идентификатор записи с указанием года и номера, например CVE-2021-44228;
  • Description – краткое описание проблемы, обычно с указанием затронутого продукта и версии, в которой уязвимость исправлена;
  • References – ссылки на бюллетени безопасности, отчеты исследователей, публикации вендоров и другие материалы об уязвимости;
  • Assigning CNA – организация, которая присвоила CVE ID и опубликовала запись;
  • Date Record Created – дата создания записи;
  • Affected products / versions – затронутые продукты и версии, если эти сведения заполнены в записи;
  • Problem type – тип проблемы, часто с привязкой к CWE;
  • Metrics – метрики и оценки, например CVSS, если они предоставлены источником.
Поле
Пример заполнения
CVE ID
CVE-2021-44228
Description
JNDI-функции в Apache Log4j2 позволяют выполнить произвольный код, если атакующий контролирует сообщения лога или их параметры
References
Страница безопасности Apache Log4j, рассылка oss-security, бюллетени Cisco, Debian, Microsoft, Oracle и другие материалы
Assigning CNA
Apache Software Foundation (assignerShortName: apache)
Affected products / versions
Apache Log4j2 2.0-beta9 - 2.15.0, кроме исправленных релизов 2.12.2, 2.12.3 и 2.3.1
Problem type
CWE-502, CWE-400, CWE-20 в CVE Record; в NVD дополнительно указана связь с CWE-917
Важно не смешивать CVE и NVD. CVE отвечает за идентификаторы и базовые записи об уязвимостях. NVD (National Vulnerability Database), которую ведет NIST, обогащает эти записи дополнительными данными: оценками CVSS, сведениями о затронутых продуктах и платформах, связями с CWE и другой информацией для приоритизации.

Что такое CWE

Common Weakness Enumeration (CWE) – это классификатор типовых слабых мест в программном и аппаратном обеспечении. Если CVE описывает отдельную уязвимость, то CWE описывает вид ошибки, из-за которой такие уязвимости могут появляться.
Например, конкретная уязвимость может быть связана с чтением данных за пределами допустимой области памяти или небезопасной обработкой входных данных. CVE фиксирует сам случай, а CWE помогает назвать и классифицировать его причину.
Запись CWE содержит набор полей, которые описывают не конкретный инцидент, а сам тип дефекта. Основные из них:
  • Weakness ID – уникальный идентификатор типа дефекта, например CWE-125;
  • Name – краткое название дефекта, например Out-of-bounds Read;
  • Abstraction – уровень абстракции: от широкого класса проблем до более конкретной разновидности ошибки;
  • Structure – структура дефекта: отдельная ошибка, составной дефект из нескольких условий или цепочка ошибок, где одна проблема приводит к другой;
  • Description – краткое описание;
  • Extended Description – расширенное описание с дополнительным контекстом;
  • Relationships – связи с другими записями CWE, например родительские, дочерние или смежные категории;
  • Common Consequences – возможные последствия;
  • Potential Mitigations – рекомендации по предотвращению или снижению риска;
  • Observed Examples – примеры реальных уязвимостей, связанных с этим типом дефекта.
Поле
Заполнение
Weakness ID
CWE-125
Name
Out-of-bounds Read - чтение за пределами допустимой области памяти
Abstraction
Base, то есть базовый тип дефекта
Description
Программа читает данные за пределами выделенной области памяти
Common Consequences
Чтение памяти, раскрытие чувствительных данных, обход защитных механизмов, сбой или отказ в обслуживании
Potential Mitigations
Проверка входных данных, контроль длины, размера буфера и смещений; выбор языка или механизмов с безопасной работой с памятью
Observed Examples
Подборка реальных CVE; среди них Heartbleed (CVE-2014-0160)

Пример: Heartbleed

Хороший пример связи CVE и CWE – Heartbleed (CVE-2014-0160), уязвимость в OpenSSL, раскрытая в 2014 году. Она позволяла удаленному атакующему читать данные из памяти процесса через специально сформированные TLS Heartbeat-пакеты. В памяти могли оказаться чувствительные данные, включая пароли и приватные ключи.
В старых материалах Heartbleed часто связывали с CWE-119 – некорректным ограничением операций в пределах буфера памяти. Но это слишком широкая категория. В актуальной карточке NVD для CVE-2014-0160 используется CWE-125 – чтение за пределами допустимой области памяти. В этой связке CVE указывает на конкретную уязвимость в OpenSSL, а CWE объясняет тип дефекта.

Что применяется в России

Для российских организаций важно учитывать не только CVE и NVD, но и БДУ ФСТЭК – Банк данных угроз безопасности информации. Это российский государственный источник, содержащий сведения об угрозах, применимых к российской практике регулирования, оценки защищенности и работы с отечественными продуктами.
В БДУ уязвимости получают собственные идентификаторы вида BDU:2026-07272. В карточке уязвимости могут указываться связанные идентификаторы из других систем, например CVE, а также затронутое ПО, версии, тип угрозы (УБИ), оценки CVSS, уровень опасности, наличие эксплойта, способ эксплуатации и способ устранения. Поэтому БДУ стоит воспринимать не как зеркало CVE, а как отдельный источник: он сопоставляет данные из сторонних баз, дополняет их экспертизой в оценке угроз и использует собственную идентификацию и классификацию.
При внедрении SCA стоит смотреть не только на международные источники, но и на то, как инструмент работает с БДУ ФСТЭК и сопоставляет такие данные с другими базами. Одна и та же уязвимость может встречаться в нескольких источниках под разными идентификаторами, а сведения о версиях, критичности или способах устранения могут отличаться. Поэтому для анализа важны нормализация, сопоставление и дедупликация записей из разных баз.

Как CVE и CWE используются в SCA

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

Как это выглядит в CodeScoring

В CodeScoring.SCA список обнаруженных уязвимостей доступен в разделе SCA -> Уязвимости. Для каждой записи отображаются идентификатор уязвимости, затронутая зависимость и версия, тип связи зависимости, окружение, проект, статус триажа, оценки CVSS, данные SSVC и EPSS, связанные CWE, наличие эксплойта, достижимость, импакт, исправленная версия и дата обнаружения.
На странице отдельной уязвимости CodeScoring показывает единую дедуплицированную запись, даже если данные пришли из нескольких источников, например CVE.org, GHSA, Kaspersky, БДУ ФСТЭК или NVD. При этом можно посмотреть исходные данные каждого источника отдельно, сравнить оценки и увидеть связанные зависимости, контейнерные образы и алерты политик.
CWE в CodeScoring используется для классификации типа дефекта. По CWE можно фильтровать список уязвимостей и настраивать условия политик. При этом CWE – только один из критериев: политики CodeScoring могут настраиваться по более чем 70 критериям.