Как читать CVE и оценивать его риск

CVE-2021-44228 — полезное предупреждение против восприятия CVE как окончательного вердикта. Запись идентифицирует Log4Shell; ваша версия, путь выполнения кода, доступность и роль актива определяют необходимую работу.

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

Именно поэтому число CVSS получает красный значок: информационным панелям нужен механизм сортировки. Но оно не должно принимать решение за вас.

Итак, вы пройдёте это расследование по порядку: идентификация и состояние, применимость, CVSS, сигналы угрозы и устранение.

В этой статье

• Какие сведения предоставляет CVE
• Начните с ID, но не придавайте ему чрезмерного значения
• Проверьте состояние записи, прежде чем ей доверять
• Убедитесь, что ваш продукт и версия затронуты
• Читайте оценку CVSS как сигнал серьёзности, а не как вердикт
• Расшифруйте строку вектора вместо того, чтобы доверять заголовочному числу
• Почему ваш поставщик, NVD и сканер могут расходиться во мнениях
• Превратите серьёзность в решение о приоритизации
• Используйте ссылки, чтобы проверить следующее действие
• Чек-лист чтения CVE

Какие сведения предоставляет CVE

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

CVSS сообщает о серьёзности с помощью определённых метрик. В руководстве National Vulnerability Database по CVSS граница сформулирована прямо: «CVSS не является мерой риска».

И поместите это предложение над информационной панелью, потому что она не видит ценность или доступность вашего актива.

Но отрасль продолжает сводить эти системы к одному словарю. Такое упрощение превращает метку серьёзности в плохую очередь исправлений. CVE идентифицирует конкретную уязвимость. CWE описывает лежащий в её основе тип слабости: например, SQL-инъекция — это категория CWE, тогда как отдельные уязвимости SQL-инъекций в конкретных продуктах получают отдельные записи CVE. CVSS описывает потенциальную серьёзность. NVD повторно публикует опубликованные CVE с анализом и данными о применимости. EPSS оценивает вероятность эксплуатации как вероятность от 0% до 100%. Включение в KEV сигнализирует об активной эксплуатации.

Но эти системы отвечают на разные вопросы. Ваше расследование связывает полученные ответы.

Начните с ID, но не придавайте ему чрезмерного значения

Возьмём CVE-2021-44228 — идентификатор, связанный с Log4Shell.

Но не воспринимайте год как дату обнаружения: записи CVE не гарантируют такую трактовку. Год обозначает момент резервирования ID или публикации уязвимости, а обнаружение могло произойти раньше.

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

CVE-YEAR-SEQUENCE

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

CVE-2026-1234
CVE-2026-1234567

Оба варианта соответствуют формату.

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

И поскольку сканеры часто показывают ID и оценку вместе, они могут выглядеть как полностью подтверждённое обнаружение. Воспринимайте оповещение сканера как утверждение. Проверьте обнаруженный пакет и установленную версию. Проверьте путь доказательств. Проверьте состояние записи и рекомендацию поставщика. Если сканер не может показать, почему он сопоставил запись с активом, отправьте обнаружение на проверку, а не воспринимайте оценку как доказательство.

Проверьте состояние записи, прежде чем ей доверять

CVE Program описывает шесть этапов процесса:

1. Обнаружение
2. Сообщение
3. Запрос
4. Резервирование
5. Отправка
6. Публикация

Обычно вы увидите одно из следующих состояний записи: Reserved, Published или Rejected.

Запись Reserved означает, что ID назначен, пока координируется работа по раскрытию информации. Подробности могут отсутствовать или быть неполными. Следите за соответствующими сообщениями поставщика и повторно проверьте запись.

Запись Published означает, что минимальная общедоступная запись доступна; при этом всё ещё может потребоваться проверка поставщиком. Ищите описание, затронутые продукты и версии, а также ссылки на рекомендацию или технический отчёт.

Запись Rejected больше не должна использоваться как действительная запись об уязвимости. Она остаётся видимой для обеспечения прослеживаемости, поэтому её присутствие в базе данных не делает её пригодной для действий.

На диаграмме показаны поля; позже вы расшифруете вектор.

Убедитесь, что ваш продукт и версия затронуты

Теперь сравните запись с вашим инвентарём.

Для CVE-2021-44228 соответствующим компонентом является Apache Log4j. Одного этого факта недостаточно, чтобы установить одинаковую степень воздействия для каждого развёртывания. Сравните запись с вашим инвентарём:

1. Определите уязвимый компонент. Это сам Log4j, включённая библиотека, продукт, в который он встроен, или другой пакет с похожим названием?
2. Сопоставьте версию. Сравните установленную версию с затронутым диапазоном.
3. Найдите исправление или смягчающую меру. Рекомендация поставщика является источником авторитетной информации о специфичной для продукта области воздействия, исправленных выпусках и мерах смягчения.
4. Проверьте путь приложения. Загружает ли приложение библиотеку на уязвимом пути?
5. Проверьте доступность. Может ли злоумышленник получить доступ к этому пути через сеть, аутентифицированный интерфейс или только локально?

Данные о применимости CPE могут помочь найти потенциально затронутое программное обеспечение. Воспринимайте совпадение в базе данных как зацепку. Докажите наличие уязвимости с помощью установленного продукта и версии. Затем проверьте конфигурацию и доступный путь.

Для Log4Shell проверьте, присутствует ли затронутая версия Log4j, используется ли уязвимый путь поиска приложением и может ли злоумышленник получить доступ к этому приложению. «Пакет существует на диске» и «уязвимый путь удалённо эксплуатируем в этом развёртывании» — разные выводы.

Здесь побеждает скучная работа: инвентаризация, доступность и ответственное лицо важнее ещё одного часа наблюдения за оценкой.

Читайте оценку CVSS как сигнал серьёзности, а не как вердикт

Это руководство отражает рекомендации CVE, NVD и FIRST, доступные на 9 сентября 2026 года. CVSS 4.0 является текущей структурой, но сканеры и рекомендации всё ещё содержат данные CVSS 3.x и устаревшей версии v2.0. Спецификация CVSS 4.0 от FIRST определяет структуру; её руководство пользователя v4.0 объясняет, как её применять.

Для CVSS 3.x и 4.0 используются следующие оценки:

Score	Rating
0.0	Отсутствует
0.1–3.9	Низкая
4.0–6.9	Средняя
7.0–8.9	Высокая
9.0–10.0	Критическая

CVSS v2.0 использует другие обозначения. Низкая серьёзность охватывает диапазон 0.0–3.9, средняя — 4.0–6.9, а высокая — 7.0–10.0; уровней Critical и None нет. Не сравнивайте оценку v2.0, равную 7.0, с оценкой v4.0, равной 7.0, как если бы они обозначали одинаковую серьёзность. Сначала сравните версию, вектор и допущения.

Структура CVSS 4.0 содержит четыре группы метрик:

• Base: внутренние характеристики уязвимости.
• Threat: зависящие от времени факторы, включая зрелость эксплойта.
• Environmental: факторы, специфичные для вашего развёртывания, например меры смягчения и важность системы.
• Supplemental: дополнительный контекст, который не изменяет итоговую оценку.

Номенклатура сообщает, какие группы использовались:

• CVSS-B: только Base
• CVSS-BT: Base плюс Threat
• CVSS-BE: Base плюс Environmental
• CVSS-BTE: Base, Threat и Environmental

NVD и многие поставщики публикуют оценки Base. Поэтому заголовочная оценка часто описывает общую серьёзность при указанных допущениях. Для полной оценки вашего риска требуется больше контекста.

Оценка предназначена быть независимой от конкретного человека и организации, которые её проводят. Оценка 10.0 может описывать систему, которой вы не пользуетесь; оценка 7.5 может описывать внешний периметр вашего бизнеса. Воспринимайте число как сигнал серьёзности, затем проверьте наличие уязвимости и последствия.

Расшифруйте строку вектора вместо того, чтобы доверять заголовочному числу

Откройте вектор, прежде чем принимать оценку.

Ниже приведён пример разбора, а не опубликованная оценка Log4Shell по v4.0:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Читайте пары «метрика/значение» слева направо. Префикс идентифицирует версию CVSS.

Метрики эксплуатируемости

• AV:N (Attack Vector: Network). Атака происходит по сети. Другие значения — Adjacent, Local и Physical.
• AC:L — Attack Complexity: Low. AC описывает сложность эксплуатации и определённые встроенные условия защиты. Меры смягчения, специфичные для вашего развёртывания, относятся к Environmental.
• AT:N — Attack Requirements: None. Уязвимый компонент не имеет дополнительного обязательного предварительного условия в оцениваемом сценарии.
• PR:N — Privileges Required: None. Злоумышленнику не нужны привилегии перед попыткой эксплуатации.
• UI:N — User Interaction: None. Действия пользователя не требуются.

Вместе AV:N, PR:N и UI:N описывают сетевой доступ без предварительных привилегий или действий пользователя. Однако они всё ещё не доказывают, что ваше развёртывание доступно.

Метрики воздействия

Следующие шесть значений описывают воздействие на две системы:

• VC, VI, VA: конфиденциальность, целостность и доступность уязвимой системы.
• SC, SI, SA: конфиденциальность, целостность и доступность последующей системы.

Здесь VC:H/VI:H/VA:H описывает высокое воздействие по всем трём измерениям на уязвимую систему, тогда как SC:N/SI:N/SA:N описывает отсутствие воздействия на последующую систему. Если бы SC, SI или SA изменились на High, вы бы выяснили, какая последующая система может пострадать, и учли бы эту связь при расстановке приоритетов.

CVSS 4.0 удалил метрику Scope и разделил воздействие на уязвимые и последующие системы. Предварительные условия были выделены из Attack Complexity в Attack Requirements, а User Interaction стал более детализированным и получил значения None, Passive и Active.

Поставщик может опубликовать более одной оценки Base для одной и той же уязвимости, если платформы или режимы развёртывания отличаются. Выберите вектор, соответствующий затронутому продукту или платформе. Иначе вы будете сравнивать чужие допущения со своей системой.

Почему ваш поставщик, NVD и сканер могут расходиться во мнениях

Две оценки для одной CVE не означают автоматически, что одна из сторон допустила ошибку.

Поставщик может обладать специфичными для продукта знаниями о поддерживаемых конфигурациях и путях атаки. База данных обычно публикует метрики Base для опубликованных CVE. Когда сведения, необходимые для оценки, недоступны, она может назначить метрикам значения наихудшего сценария, что способно привести к оценке Base 10.0. Это обеспечивает базе данных полезное покрытие. Но это не измеряет ваше локальное развёртывание.

Систематически сравнивайте записи:

• Версия CVSS
• Тип оценки, например CVSS-B или CVSS-BTE
• Строка вектора
• Организация, выполнившая оценку
• Дата публикации или обновления
• Допущения относительно продукта и развёртывания

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

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

Превратите серьёзность в решение о приоритизации

Используйте проверку применимости, чтобы решить, должно ли обнаружение вообще попасть в вашу очередь. Затем ответьте на три вопроса.

К чему приведёт эксплуатация здесь?

Учитывайте роль актива и обрабатываемые им данные. Затем изучите его доверительные связи и последствия компрометации. Экологические метрики могут выразить часть этого контекста, но CVSS не охватывает все бизнес-вопросы. Регуляторные обязанности, влияние на клиентов, денежные потери, безопасность жизни и ущерб репутации находятся за пределами структуры.

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

Насколько вероятна эксплуатация?

CVSS спрашивает, насколько серьёзными могут быть последствия эксплуатации. EPSS обычно используется как сигнал вероятности эксплуатации и выражается как вероятность от 0% до 100%. Используйте его как сигнал вероятности, а не как дедлайн или гарантию.

Каталог KEV используется как сигнал активной эксплуатации. Рассматривайте наличие CVE в KEV как основание для немедленной проверки независимо от оценки CVSS; действием может быть установка исправления, изоляция или документированная компенсирующая мера контроля.

Какое действие быстрее всего уменьшит воздействие?

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

В рассматриваемом примере, если инвентаризация подтверждает наличие Log4j 2.x внутри интернет-доступного приложения, а уязвимый путь поиска доступен, считайте обнаружение подтверждённым. Если библиотека присутствует только в изолированном недоступном тестовом артефакте, задокументируйте эту границу и выберите другое действие.

Скучная работа — инвентаризация, доступность и ответственное лицо — важнее ещё одного часа наблюдения за оценкой.

Finding	Практическая реакция
Затронуто, доступно из интернета, активно эксплуатируется	Начните экстренное устранение или изолируйте систему
Затронуто и имеет высокое воздействие, но известная эксплуатация отсутствует	Назначьте приоритет на основе доступности, критичности актива и доступных мер смягчения; назначьте ответственное лицо и дату проверки
Не затронуто или находится за пределами уязвимого диапазона версий	Задокументируйте доказательства и закройте обнаружение
Зарезервированная запись	Следите за рекомендацией CNA или поставщика и повторно проверьте запись
Опубликовано, но отсутствуют затронутые версии, ссылки или подробности описания	Проверьте область воздействия с поставщиком и зафиксируйте неопределённость
Отклонённая CVE	Не используйте её как действительную запись об уязвимости

В оценке CVSS нет универсального срока установки исправления. CVE одна и та же. Доступность и последствия — нет.

Используйте ссылки, чтобы проверить следующее действие

Создавайте цепочку доказательств, а не ещё одну оценку:

1. Запись CVE подтверждает идентификатор и состояние записи.
2. Обогащение базы данных предоставляет контекст CVSS, слабости и применимости продукта.
3. Рекомендация поставщика содержит специфичное для продукта воздействие, исправленные версии и меры смягчения.
4. Спецификация или руководство пользователя FIRST помогают проверить вектор.
5. Калькулятор NVD CVSS 4.0 позволяет воспроизвести или проверить оценку.

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

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

Чек-лист чтения CVE

1. Идентификация: зафиксируйте ID CVE, год резервирования ID или публикации уязвимости и состояние записи.
2. Применимость: подтвердите затронутый актив, установленную версию, конфигурацию и доказательства доступности.
3. Авторитетный источник: прочитайте рекомендацию поставщика и определите исправленный выпуск или меру смягчения.
4. Серьёзность: зафиксируйте версию CVSS, оценку, вектор и номенклатуру.
5. Угроза: проверьте сигнал EPSS и статус KEV.
6. Действие: назначьте ответственное лицо, устранение или компенсирующую меру контроля, дату проверки и текущее состояние.

Если вы не можете назвать затронутый актив, доступный путь, авторитетное исправление, ответственное лицо и следующее действие, у вас есть запись CVE, а не решение о риске.