CVSS, EPSS, SSVC и Exploitability Index: честное сравнение четырёх публичных систем оценки уязвимостей

В мире уязвимостей давно не хватает общего языка. Одни системы измеряют «тяжесть» проблемы, другие пытаются угадать вероятность эксплуатации, третьи сразу предлагают действие. В итоге для одной и той же уязвимости мы получаем разные сигналы, а команды ИБ спорят что чинить первым делом.

Масштабное исследование «Conflicting Scores, Confusing Signals», впервые провело детальное сравнение четырёх наиболее влиятельных публичных подходов к оценке уязвимостей. Исследователи проанализировали 600 реальных CVE из четырёх циклов Microsoft Patch Tuesday, чтобы понять, как эти системы работают на практике и где они помогают, а где — подводят.

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

Четыре героя нашего сравнения

CVSS: математика тяжести последствий

CVSS фокусируется на внутренних характеристиках уязвимостей, кульминацией которых является балл тяжести. Система пытается стандартизировать разговор об уязвимостях через набор метрик и формулу, которая на выходе даёт число от 0 до 10 и словесную категорию от «Низкая» до «Критическая».

Четвёртая версия дополняет базовые характеристики угрозовыми и средовыми факторами. Базовые метрики включают эксплуатируемость (вектор атаки, сложность атаки, требуемые привилегии, взаимодействие с пользователем) и влияние (конфиденциальность, целостность, доступность). Временные метрики учитывают зрелость эксплойт-кода, уровень исправления и уверенность в отчёте.

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

EPSS: предиктивная аналитика на службе безопасности

EPSS создаёт балл от 0 до 1, представляющий вероятность того, что уязвимость будет эксплуатирована в следующие 30 дней. Система строится на данных и машинном обучении, используя информацию из источников вроде MITRE CVE, данные о CVE (например, дни с момента публикации), и наблюдения за эксплуатацией в дикой природе от вендоров безопасности.

EPSS гордится тем, что является открытым и управляемым данными усилием, которое стремится оценить вероятность того, что программная уязвимость будет эксплуатирована в дикой природе. Модель обновляется ежедневно, предоставляя живой индикатор, чувствительный к информационному шуму, публикациям proof-of-concept и поведенческим паттернам злоумышленников.

Достоинство EPSS — именно попытка дать динамический сигнал «будет горячо или нет». EPSS фокусируется на двух основных метриках — эффективности и покрытии. Эффективность изучает, насколько хорошо организации используют ресурсы для решения процента исправленных уязвимостей. Недостатки — зависимость от качества публичных данных, перекосы по семействам продуктов и то, что «вероятность завтра» не равна «важности для бизнеса» здесь и сейчас.

SSVC: от баллов к решениям

Университет Карнеги-Меллон совместно с CISA создал систему SSVC в 2019 году для предоставления киберсообществу методологии анализа уязвимостей, которая учитывает статус эксплуатации уязвимости, влияние на безопасность и распространённость затронутого продукта в единой системе.

SSVC — это не число, а процесс: структурированное дерево решений, которое по ответам на несколько вопросов выводит один из приоритетов. CISA использует свою модель дерева решений SSVC для приоритизации соответствующих уязвимостей по четырём возможным решениям: Track (отслеживать), Track* (отслеживать особо), Attend (уделить внимание) и Act (действовать).

Дерево решений SSVC учитывает эксплуатацию (нет доказательств, есть PoC, активная эксплуатация), автоматизируемость (медленная/быстрая), техническое воздействие (частичное/полное) и влияние на миссию и благополучие. Метод появился как реакция на вечный спор вокруг «баллов» и пытается прямо связать анализ уязвимости с рекомендацией к действию.

Плюс SSVC — ясность ответа «что делать», гибкость под роль и отрасль. SSVC — это не просто лучшая модель приоритизации, это лучшая модель коммуникации. Минус — существенная доля качественных суждений. Разные организации, имея разные контексты, могут честно прийти к разным действиям для одной и той же CVE.

Exploitability Index: прагматизм экосистемы Microsoft

Microsoft Exploitability Index помогает клиентам приоритизировать развёртывание обновлений безопасности, предоставляя информацию о вероятности эксплуатации уязвимости, устранённой в обновлении безопасности Microsoft. Индекс сопровождает ежемесячные бюллетени и оценивает вероятность появления рабочей эксплуатации в течение 30 дней после выхода обновления.

Exploitability Index использует одно из четырёх значений для информирования клиентов о вероятности эксплуатации уязвимости: эксплуатируется (известны случаи эксплуатации), вероятная эксплуатация (можно создать стабильный эксплойт), маловероятная эксплуатация (сложности при создании эксплойта), функциональная эксплуатация маловероятна.

Сильная сторона — приземлённость на реальные патчи и экосистему Microsoft, что делает индекс крайне полезным для компаний на Windows-стеке. Microsoft также партнёрствует с поставщиками защиты через программу Microsoft Active Protections Program (MAPP), работая с ними для валидации прогнозов каждый месяц. Узкое место — ограниченность области применения и несопоставимость с уязвимостями вне экосистемы Microsoft.

Методология большого исследования

Когда разных «линеек» становится много, возникает искушение сложить их в один «средний градус» и успокоиться. Это путь к неверным приоритетам. Исследование провело первое масштабное эмпирическое сравнение четырёх систем оценки уязвимостей на реальном наборе данных из 600 CVE Microsoft Patch Tuesday.

Исследователи выбрали Microsoft Patch Tuesday как идеальную лабораторию для сравнения по нескольким причинам. Во-первых, это регулярное и высокоимпактное событие в управлении уязвимостями. Во-вторых, все четыре системы могут быть применены к одним и тем же CVE, что обеспечивает справедливость сравнения. В-третьих, такой срез напоминает реальную жизнь крупной организации, где приходится ежемесячно переваривать десятки бюллетеней.

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

Ключевые открытия: что показала практика

1. Шокирующая несогласованность между системами

Корреляции между системами невысоки, а метрики согласия категорий в среднем близки к нулю. Если визуализировать оценки одной и той же CVE разными методами, картина окажется пёстрой. Групп «жёсткого согласия» мало, а разброс заметный.

Это означает, что CVE может выглядеть срочной по одной линейке и вполне терпимой по другой. Исследование показало, что системы часто кардинально расходятся в оценках. Например, уязвимость может получить критический балл по CVSS (8.5+), низкий показатель по EPSS (менее 0.1) и попасть в категорию «Track» по SSVC одновременно.

Практический вывод: если у вас есть привычка «усреднять всё по больнице», вы рискуете потерять смысл сигналов. Лучше чётко разделять семантику каждой шкалы и назначить им разные роли в процессе. Каждая система отвечает на свой вопрос, и смешивание ответов приводит к управленческой каше.

2. Проблема переполненных «топов» и размытых приоритетов

При попытке составить общий «топ-N» к патчингу пересечение между системами оказывается минимальным. У CVSS и близких к нему подходов есть системная проблема «ничьи» — десятки CVE получают один и тот же высокий балл и дружно забивают первые места рейтинга.

EPSS, в свою очередь, часто относит в высокий приоритет мало записей, оставляя значительный хвост неопределённости. Согласно рекомендациям Mend.io, следует приоритизировать уязвимости, которые выходят за пределы двух стандартных отклонений выше среднего («высокие выбросы»). Но таких уязвимостей может оказаться слишком мало для практического планирования.

Отсюда рождается перегрузка: половина пула улетает в верхние корзины, а команда ИБ остаётся без надёжного механизма тонкой расстановки очереди. У «топов» нет градиента, а без градиента невозможно распределять ресурсы по волнам, разгружая окна обслуживания.

Исследование показало, что организации часто сталкиваются с ситуацией «всё критическое», когда 40-60% уязвимостей получают высокие оценки по разным системам, но реальных ресурсов на их обработку просто нет.

3. EPSS не всегда «чует воду» раньше других

Интуитивно ожидается, что модель наподобие EPSS будет предсказателем будущего: «чуять воду» раньше всех. Однако статические оценщики тяжести, особенно CVSS, имели тенденцию присваивать более высокие баллы тяжести CVE, позже подтверждённым как эксплуатируемые.

Исследование обнаружило парадоксальный результат: доля уязвимостей, которые получили уверенно высокий вероятностный сигнал EPSS до того, как попали в публичные перечни эксплуатируемых (например, каталоги KEV), оказалась невелика. Более того, традиционные статические оценки тяжести чаще оказывались высокими у тех CVE, которые позже действительно эксплуатировались.

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

4. Тип уязвимости не объясняет разногласий

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

Разный характер уязвимостей (CWE) сам по себе не объясняет разногласий между системами. Систематической «любви» или «неприязни» к конкретным классам слабостей в сравнении не выявлено. Это ещё один аргумент в пользу того, что строить процесс на «классовых» упрощениях опасно.

Например, уязвимости типа «Переполнение буфера» не получают системно более высоких или низких оценок в какой-то конкретной системе по сравнению с «SQL-инъекциями». Важнее контекст, экспозиция и поверхность атаки в вашей инфраструктуре, чем абстрактный тип слабости.

Неожиданные практические находки

Временная динамика EPSS оказалась менее предсказуемой

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

Это создаёт проблемы для планирования патчинга: команды могут отреагировать на временный всплеск EPSS, а к моменту начала работ приоритет уже изменился. Стабильность CVSS в этом смысле оказывается практическим преимуществом для долгосрочного планирования.

SSVC работает лучше в крупных организациях

Исследование показало, что SSVC особенно эффективен в крупных организациях с устоявшимися процессами и чёткой иерархией принятия решений. Очень малое число уязвимостей когда-либо достигнет решения «Act» — где-то в районе 0,06% согласно исследованиям Патрика Гаррити.

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

Microsoft Exploitability Index показал высокую точность для своей экосистемы

Несмотря на ограниченную область применения, Exploitability Index продемонстрировал впечатляющую точность предсказаний в рамках экосистемы Microsoft. Уязвимости, помеченные как «эксплуатируется», действительно чаще других попадали в реальные атаки в течение месяца.

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

Практические стратегии: как использовать все четыре системы

Принцип разделения ролей: каждой системе — своя задача

CVSS и ему подобные — о том, насколько сильно ударит успешная атака. EPSS и Exploitability Index — о том, какова ближайшая динамика вокруг эксплуатации. Используя CVSS в сочетании с KEV и EPSS, теперь мы можем рассматривать риск уязвимости через линзу дополняющих количественных источников данных.

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

Тезис «высокий CVSS = чиним прямо сейчас» часто оказывается неверным, если сервис практически недоступен злоумышленнику или закрыт компенсирующими мерами. И наоборот, средний CVSS плюс сильный сигнал вероятной эксплуатации по EPSS/EI и высокой экспозиции в вашей сети — повод поднять приоритет.

Не создавайте «интегральный балл» — создавайте процесс

Попытка сложить CVSS, EPSS и SSVC в один «интегральный» показатель даёт ложную точность. Используйте их параллельно, но не усредняйте: каждому индикатору — свой вес и своя роль. В стратегии исправления рекомендуется приоритизировать уязвимости на основе как их эксплуатируемости, так и их потенциального влияния на кодовую базу.

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

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

Боремся с «бутылочными горлышками» в верхних категориях

У CVSS/SSVC часто получается слишком много записей в «верхних» классах. Чтобы не перегрузить окна обслуживания, введите внутренний дополнительный разбор, который формирует управляемый градиент. Эффективный практический фильтр включает:

• Экспозицию: доступ извне без аутентификации или через массово используемые интерфейсы
• Массовость продукта в вашей среде и возможность автоматизации атаки
• Наличие компенсирующих мер: WAF, изоляция, выключенные функции, жёсткая конфигурация
• Готовность к обновлению: совместимость, обратимые действия, тестовые окна
• Сигналы активности: эксплуатация или PoC, включая внутреннюю телеметрию

Итогом должен стать не один «топ-100», а волны на ближайшие окна: «сегодня», «в течение недели», «в следующий цикл». Так вы превращаете разрозненные сигналы в управляемый план действий.

SSVC как коммуникационный фасад

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

Используйте SSVC как фасад для коммуникаций с ИТ-эксплуатацией и бизнес-подразделениями: «Отслеживаем», «Уделяем внимание», «Вовлекаем руководство», «Действуем немедленно». Но обязательно прикладывайте к узловым развилкам чек-листы доказательности: что послужило основанием считать угрозу автоматизируемой, где и как подтверждается активная эксплуатация, как оценён ущерб для миссии.

Если ваша отрасль требует отдельного учёта влияния на безопасность людей, критические услуги или соблюдение регуляторных требований, расширяйте «миссию и благополучие» в SSVC под себя — это предусмотрено методикой.

Пошаговый пример комплексного подхода

Представим типовой инцидентный месяц. Вы получили пачку из 150 уязвимостей Microsoft и сторонних вендоров. Окно обслуживания — выходные, ресурсы ограничены. Как применить всё изученное?

Этап 1: Грубая сортировка по тяжести

Пробегаемся по CVSS всех входящих CVE. Все записи с высоким/критическим баллом (7.0+) складываем в «корзину А» — получается 60 штук. Средние (4.0-6.9) — в «корзину B» (70 штук). Низкие (менее 4.0) временно откладываем в долгосрочное планирование.

Этап 2: Наложение сигналов вероятности

Для корзин «A» и «B» подтягиваем EPSS и Exploitability Index. В «A» отмечаем те, где EPSS выше 0.1 (что соответствует примерно 90-му процентилю), либо EI говорит «эксплуатируется» или «вероятная эксплуатация». Обнаруживаем интересную картину: из 60 «критических» по CVSS только 8 имеют высокий EPSS, зато в корзине «B» находим 12 уязвимостей с высоким EPSS.

Этап 3: Контекст активов и экспозиция

Накладываем карту активов из CMDB: что доступно извне, где нет компенсирующих мер, где критичная бизнес-функция. Внутри «A» образуются подкатегории:

• A1 (20 CVE): снаружи доступно И критично для бизнеса
• A2 (25 CVE): внутренние, но на чувствительных системах
• A3 (15 CVE): закрытые компенсирующими мерами или на некритичных системах

В корзине «B» выделяем «B1» — 12 CVE с высоким EPSS на публично доступных сервисах.

Этап 4: SSVC для финального решения

Для «A1», «A2» и «B1» прогоняем дерево SSVC, чтобы зафиксировать действие и уровень эскалации. Получаем:

• Act немедленно (5 CVE): A1 с активной эксплуатацией и полным воздействием
• Attend (18 CVE): A1 и B1 с высоким бизнес-влиянием
• Track* (34 CVE): остальные A1, A2 без активных сигналов

Этап 5: Финальный план по волнам

1. Экстренная волна (в течение 24 часов): 5 CVE из категории «Act»
2. Приоритетная волна (до выходных): 18 CVE из категории «Attend»
3. Плановая волна (в рамках окна обслуживания): 34 CVE из Track*
4. Следующий цикл: оставшиеся A3 и средние по приоритету из корзины B

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

Инструменты и автоматизация процесса

Интеграция с существующими системами

Современные платформы управления уязвимостями начинают поддерживать множественные метрики. Crossfeed рассматривает интеграцию с API EPSS, SSVC и VPR от Nessus для предоставления дополнительных баллов к каждой уязвимости наряду с CVSS. Это позволяет автоматизировать сбор данных из всех четырёх систем.

При внедрении автоматизации важно:

• Настроить регулярное обновление данных (EPSS обновляется ежедневно)
• Создать дашборды, которые показывают все метрики параллельно, а не в агрегации
• Автоматизировать первичную сортировку, но оставить финальные решения за людьми
• Интегрировать с системами управления активами для контекстной информации

Мониторинг эффективности подхода

Для оценки качества вашей гибридной модели ведите метрики:

• Покрытие: какой процент реально эксплуатированных уязвимостей попал в ваши приоритетные волны
• Эффективность: какой процент патчей из приоритетных волн действительно предотвратил инциденты
• Время реакции: от публикации CVE до применения патча в разбивке по волнам
• Ложные срабатывания: сколько «критических» уязвимостей оказались переоценёнными

Спецификации и практические ресурсы

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

• CVSS: спецификация и калькулятор — страница проекта FIRST. Включает детальные руководства по применению базовых, временных и средовых метрик.
• EPSS: описание, FAQ и ежедневные выгрузки данных — официальный сайт. Предоставляет API для автоматической интеграции и исторические данные.
• SSVC: руководство и обучающие материалы — портал CISA. Включает интерактивный калькулятор и примеры настройки под разные отрасли.
• Exploitability Index: страница MSRC и Security Update Guide — описание индекса и руководство по обновлениям.

Будущее систем оценки уязвимостей

Тренды развития

Индустрия движется в сторону более контекстно-зависимых оценок. Появляются новые подходы вроде LEV (Likely Exploited Vulnerabilities) — метрики, введённой NIST в 2025 году, которая оценивает вероятность того, что уязвимость уже была эксплуатирована, на основе исторических баллов EPSS.

Другое направление — системы вроде PXS (Picus Exposure Score), которые пытаются добавить недостающий слой — доказательства того, что действительно эксплуатируемо в уникальной ИТ-среде организации. Эти системы не заменяют существующие метрики, а дополняют их реальными тестами в вашей инфраструктуре.

Вызовы и ограничения

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

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

Итоги: избегаем «войны сигналов»

Главная мысль проста, но критически важна: эти системы про разное. CVSS измеряет потенциальную боль, EPSS и EI — близкую динамику эксплуатации, SSVC — рекомендует действие. Конфликты сигналов появляются тогда, когда мы пытаемся использовать одну шкалу вместо другой или смешать всё в один «усреднённый балл».

Исследование «Conflicting Scores, Confusing Signals» научно подтвердило то, что многие практики подозревали интуитивно: универсального «правильного» балла не существует. Каждая система оценки уязвимостей имеет свои цели, методологии и результаты, которые часто приводят к несогласованным решениям о приоритизации.

Лекарство — роль-ориентированное применение, усиленное вашим контекстом активов и управленческими регламентами. Создавайте процесс, который использует сильные стороны каждой системы:

• CVSS для понимания масштаба потенциального ущерба
• EPSS для оценки динамики угроз в ближайшем будущем
• SSVC для структурирования решений и коммуникаций
• Exploitability Index для Windows-центричных сред и экспертного мнения Microsoft

И да, иногда полезнее вычеркнуть очередной «топ-100», а вместо этого собрать первую волну патчей из «десяти действительно опасных здесь и сейчас». Качество управленческого решения важнее количества обработанных метрик.

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