CVE, BDU, CVSS: что означают рейтинги

Введение

Когда в новостях или отчётах по безопасности мелькают строки вроде “CVE-2025-xxxx, CVSS 9.8”, это звучит весьма тревожно. Но что именно стоит за этими цифрами и аббревиатурами?

В мире информационной безопасности существует несколько систем классификации уязвимостей:

• CVE — глобальный каталог уязвимостей, где каждой проблеме присваивается уникальный идентификатор.
• BDU — российский аналог, поддерживаемый ФСТЭК.
• CVSS — система оценки критичности уязвимостей по ряду метрик.

Разберёмся, откуда всё это взялось и как правильно читать такие отчёты.

Что такое CVE

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

Например:

• CVE-2025-53770 — это уязвимость в SharePoint Server,
• CVE-2021-44228 (Log4Shell) — знаменитая ошибка в Apache Log4j.

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

Важно понимать:

• CVE — это не оценка опасности, а лишь «бирка», чтобы можно было однозначно сослаться на проблему.
• Подробности обычно публикуются в базах MITRE или NVD (National Vulnerability Database), где к CVE добавляют описание, ссылки на патчи, эксплойты и, в том числе, метрику CVSS.

Таким образом, CVE — это универсальный язык, на котором разговаривает весь мир кибербезопасности.

Что такое BDU

Если CVE — это международный стандарт, то в России существует собственный каталог уязвимостей — Банк данных уязвимостей ФСТЭК (БДУ).

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

Формат идентификатора выглядит так:

• BDU:2024-12345 — год + уникальный номер записи.

В базе ФСТЭК содержатся:

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

Особенность БДУ в том, что туда могут попасть не только международно известные уязвимости (с CVE), но и локальные проблемы, которые важны именно в российском контексте: отечественное ПО, используемое в критической инфраструктуре, госструктурах или на предприятиях.

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

Что такое CVSS

Когда уязвимость получила свой идентификатор (CVE или BDU), логично спросить: насколько она опасна? Для этого используется CVSS — Common Vulnerability Scoring System.

CVSS — это методика оценки критичности уязвимости. Она не описывает уязвимость сама по себе, а переводит её свойства в числовую шкалу от 0.0 до 10.0.

Диапазоны обычно делят так:

• 0.0 — информационная (неопасная) уязвимость,
• 0.1–3.9 — низкая критичность,
• 4.0–6.9 — средняя,
• 7.0–8.9 — высокая,
• 9.0–10.0 — критическая.

CVSS строится на трёх основных метриках:

1. Базовые (Base metrics) — описывают технические характеристики уязвимости, которые не меняются со временем. Например:
   • можно ли эксплуатировать удалённо или нужен локальный доступ,
   • требуется ли аутентификация,
   • уровень влияния на конфиденциальность, целостность и доступность.
2. Временные (Temporal metrics) — отражают текущую ситуацию:
   • есть ли публичный эксплойт,
   • выпущены ли патчи,
   • насколько активно уязвимость используется злоумышленниками.
3. Контекстные (Environmental metrics) — учитывают особенности конкретной инфраструктуры:
   • важность затронутой системы,
   • наличие компенсирующих мер,
   • критичность данных, к которым может получить доступ злоумышленник.

На практике в новостях и отчётах чаще всего встречается именно базовый балл (Base score), который вычисляется автоматически по формуле и выглядит как «CVSS 9.8».

Почему «9.8» не всегда катастрофа

Зачастую, когда читаешь отчёт с формулировкой «CVSS 9.8, критическая уязвимость», возникает ощущение неминуемой угрозы. Но на практике всё немного сложнее.

1. CVSS ≠ реальный риск.

CVSS оценивает технический потенциал уязвимости, а не вероятность её эксплуатации именно в вашей инфраструктуре.
Пример:

• Уязвимость позволяет удалённое выполнение кода (RCE) без аутентификации → CVSS будет очень высоким.
• Но если уязвимое приложение у вас отключено, изолировано или доступно только внутри защищённого сегмента, реальный риск может быть низким.

2. Среда эксплуатации имеет значение.

Уязвимость в доступном из сети Интернет сервисе и уязвимость в тестовой системе внутри лаборатории будут иметь разный вес, даже при одинаковом CVSS.

3. CVSS не учитывает бизнес-факторы.

Цифра 9.8 говорит о том, что «технически можно сильно навредить». Но она ничего не говорит о том, чем именно это грозит бизнесу.
Например:

• уязвимость в сервере обновлений может парализовать работу целого предприятия
• а уязвимость с тем же баллом во изолированном/тестовом сервисе будет практически безболезненной

4. «9.8» — это сигнал, а не приговор.

Высокий балл CVSS — это повод обратить внимание и проверить, затронута ли система, а не паниковать вслепую.

Грамотная практика — оценивать уязвимость по модели «техническая критичность» + «контекст эксплуатации» + «ценность активов».

Заключение

CVE, BDU и CVSS — это три элемента единой экосистемы:

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

Важно помнить:

• CVE и BDU — это «бирки» и справочники. Они помогают понять, о какой именно проблеме идёт речь.
• CVSS — это ориентир по опасности, но он не учитывает контекст вашей инфраструктуры.

Грамотная работа с уязвимостями — это всегда баланс: знать идентификатор, понимать технические детали и оценивать риск для каждого конкретного случая.