CVSS, EPSS и KEV: как приоритизировать уязвимости правильно
Почему старый подход к уязвимостям больше не работает
Каждый год исследователи публикуют десятки тысяч новых CVE. В 2023 году их число превысило 28 000 — и эта цифра продолжает расти. Для команды безопасности из пяти-десяти человек закрыть каждую из них физически невозможно. Именно здесь начинается настоящая проблема: большинство организаций по-прежнему используют единственный инструмент оценки — CVSS-балл, — и именно это решение раз за разом приводит к неверной расстановке приоритетов.
Если вы только знакомитесь с темой, рекомендуем начать с нашего материала «Управление уязвимостями: что это и как устроен процесс» — там подробно разобраны базовые понятия и этапы VM-программы. В этой статье мы идём дальше: разбираем инструменты, которые позволяют принимать по-настоящему обоснованные решения о приоритетах.
Логика «чиним сначала всё с оценкой 9.0 и выше» звучит разумно до тех пор, пока вы не обнаруживаете, что злоумышленники активно эксплуатируют уязвимость с оценкой 6.5, о которой сканер написал «medium» и которая осталась в конце очереди. Именно такой сценарий разворачивался во время атак через Log4Shell, ProxyLogon и десятки других резонансных инцидентов.
Современный риск-ориентированный подход к управлению уязвимостями (risk-based vulnerability management) строится на трёх взаимодополняющих системах: CVSS, EPSS и CISA KEV. Каждая из них отвечает на свой вопрос — и только вместе они дают достаточно полную картину для принятия обоснованных решений о патчинге.
Ключевая мысль: По данным исследования Kenna Security (Cisco), менее 5% опубликованных уязвимостей когда-либо эксплуатируются в реальных атаках. Задача специалиста — точно определить, какие именно входят в эти 5%.
CVSS: универсальная шкала с серьёзными ограничениями
Common Vulnerability Scoring System — это стандартизированная методология оценки тяжести уязвимостей, разработанная организацией FIRST. Система существует с 2005 года, а актуальная версия CVSS 4.0 вышла в ноябре 2023 года. Балл рассчитывается по формуле, учитывающей множество технических параметров: вектор атаки, сложность эксплуатации, необходимые привилегии, влияние на конфиденциальность, целостность и доступность. Итоговое число от 0 до 10 — это то, что видит аналитик в отчёте сканера.
Проблема не в том, что CVSS плохо устроен. Проблема в том, как его используют. Балл CVSS описывает теоретическую серьёзность уязвимости в идеальных условиях — но ничего не говорит о том, есть ли в природе рабочий эксплойт, используют ли его прямо сейчас злоумышленники, и насколько уязвима именно ваша инфраструктура.
Как устроена система оценки CVSS
CVSS состоит из нескольких групп метрик. Base Score — фундаментальная часть, описывающая характеристики самой уязвимости: вектор атаки (сетевой, соседний, локальный или физический), требования к аутентификации и привилегиям, необходимость взаимодействия с пользователем. Temporal Score добавляет информацию об актуальности на текущий момент: наличие эксплойта, уровень уверенности в существовании уязвимости, доступность патча. Environmental Score позволяет организации адаптировать оценку под собственную инфраструктуру — но на практике эта возможность используется редко, потому что требует значительных усилий.
CVSS 4.0 добавил новую группу метрик — Supplemental, которая включает такие параметры, как «безопасность» (safety) для критической инфраструктуры и «автоматизируемость» (automatable) — то есть возможность массовой автоматической эксплуатации. Это шаг в правильном направлении, но большинство инструментов рынка пока работают с CVSS 3.1.
Главная проблема CVSS в реальной практике
Когда организация сортирует уязвимости только по Base Score, она сталкивается с двумя взаимоисключающими проблемами одновременно. С одной стороны — alert fatigue: сотни уязвимостей с оценками 7.0+ буквально парализуют команду, у которой нет ресурсов разобраться со всеми за разумное время. С другой — ложное чувство безопасности: уязвимости с умеренными баллами, но с активно применяемыми эксплойтами откладываются на потом и именно через них происходят реальные взломы.
Факт: Исследование Tenable показало, что среди всех уязвимостей с CVSS ≥ 9.0 только около 7% имели задокументированную активную эксплуатацию в дикой природе (in the wild) в течение первого года после публикации.
Именно этот разрыв между «теоретически опасно» и «реально эксплуатируется» и стал движущей силой для создания альтернативных метрик приоритизации.
EPSS: вероятность эксплуатации как новый ориентир
Exploit Prediction Scoring System — это принципиально иная метрика, разработанная организацией FIRST совместно с независимыми исследователями. В отличие от CVSS, который описывает свойства уязвимости, EPSS отвечает на конкретный прогностический вопрос: какова вероятность того, что данная уязвимость будет эксплуатироваться в реальных атаках в течение следующих 30 дней?
Оценка EPSS представляет собой число от 0 до 1 (или от 0% до 100%), которое обновляется ежедневно. Модель анализирует огромный массив данных: информацию об эксплойтах из баз Exploit-DB и GitHub, активность в Shodan, данные от коммерческих threat intelligence-провайдеров, обсуждения в открытых источниках и многое другое. Третья версия модели (EPSS v3), запущенная в 2023 году, включает более 1 400 признаков и демонстрирует значительно лучшие показатели точности по сравнению с предыдущими итерациями.
Чем EPSS отличается от CVSS принципиально
CVSS статичен: балл присваивается при публикации CVE и меняется редко. EPSS динамичен: он пересчитывается каждые сутки по мере поступления новых данных об активности в интернете. Уязвимость, которая сегодня имеет EPSS 0.3%, через неделю может оказаться на уровне 12%, если исследователь опубликовал рабочий PoC-эксплойт. Именно эта реактивность делает EPSS ценным операционным инструментом.
Важно также понимать распределение значений EPSS. Абсолютное большинство CVE имеют крайне низкий балл: по данным FIRST, около 87% всех уязвимостей с назначенным EPSS имеют оценку ниже 0.1% (то есть менее одного шанса из тысячи на эксплуатацию в ближайший месяц). Значения выше 10% уже сигнализируют о серьёзном риске и требуют пристального внимания. Значения выше 50% встречаются редко, но означают практически гарантированную активную эксплуатацию.
Как читать и применять EPSS-оценку
Получить актуальные значения EPSS можно через API FIRST (api.first.org/epss) или через большинство современных платформ управления уязвимостями — Tenable.io, Qualys VMDR, Rapid7 InsightVM, а также через открытый инструмент осPatch. Данные доступны бесплатно, что делает EPSS доступным даже для небольших команд без крупных бюджетов на security-инструменты.
Практическое правило: если уязвимость имеет EPSS выше 10% и затрагивает интернет-экспонированный актив — это приоритет первого уровня вне зависимости от CVSS-балла. Если CVSS равен 9.5, но EPSS составляет 0.02% и эксплойт теоретически сложен в реализации — эта уязвимость вполне может подождать следующего планового патч-цикла.
Пример из практики: Исследование авторов EPSS показало, что фокус на 3% уязвимостей с наивысшим EPSS позволяет перехватить ~80% всех фактически эксплуатируемых CVE — при этом объём работ сокращается в 30–40 раз по сравнению с подходом «закрываем всё с CVSS ≥ 7.0».
CISA KEV: каталог уязвимостей, которые уже атакуют
Known Exploited Vulnerabilities Catalog — это публичный реестр, который ведёт Агентство по кибербезопасности и защите инфраструктуры США (CISA). В отличие от CVSS и EPSS, KEV не занимается прогнозированием или оценкой тяжести. Каталог содержит только те уязвимости, для которых существуют задокументированные свидетельства активной эксплуатации в реальных атаках. Это бинарный факт: либо уязвимость есть в KEV — либо нет.
Каталог был запущен в ноябре 2021 года и с тех пор пополняется регулярно — в среднем несколько записей в неделю. По состоянию на начало 2025 года в реестре насчитывается более 1 200 записей. Для каждой уязвимости указываются: идентификатор CVE, затронутый вендор и продукт, краткое описание, обязательный срок устранения для федеральных агентств США и ссылка на рекомендуемые меры.
Что такое KEV и почему он важен за пределами госсектора
Формально CISA KEV создавался как инструмент регуляторного соответствия для американских федеральных гражданских агентств (FCEB). Директива BOD 22-01 обязывает их устранять уязвимости из каталога в установленные сроки — как правило, от двух недель до нескольких месяцев в зависимости от серьёзности. Однако мировое security-сообщество быстро осознало ценность KEV как универсального сигнала тревоги.
Почему это работает для любой организации? Потому что злоумышленники — будь то финансово мотивированные группы ransomware или APT-группировки, связанные с государствами, — не разбирают, атакуют ли они американское правительство или российский финтех. Они эксплуатируют то, что работает. Попадание уязвимости в KEV означает, что кто-то уже активно использует её прямо сейчас. Это не прогноз — это свершившийся факт.
Важно понимать: Попасть в KEV непросто — CISA проверяет каждую запись и требует достоверных доказательств активной эксплуатации. Именно поэтому каталог остаётся достаточно компактным и каждая запись в нём имеет реальный вес.
Как KEV используется в реальных программах патчинга
Самый простой и эффективный способ использования KEV — интеграция проверки по каталогу в процесс сортировки уязвимостей. Любая CVE, обнаруженная в вашей инфраструктуре и одновременно присутствующая в KEV, автоматически получает наивысший приоритет и уходит в патчинг без дополнительных обсуждений. Этот принцип называется «KEV как абсолютный триггер» — и он позволяет убрать дискуссии о приоритетах там, где факты уже сказали всё за вас.
Данные KEV доступны через JSON-фид (cisa.gov/known-exploited-vulnerabilities-catalog) и легко интегрируются в SOAR-платформы, SIEM-системы и сканеры уязвимостей. Такие инструменты, как Nucleus Security, Brinqa и Vulcan Cyber, нативно поддерживают KEV-тегирование и позволяют строить дашборды с учётом этого сигнала.
CVSS vs EPSS: в чём разница и что выбрать
Сравнение CVSS и EPSS — это не соревнование, в котором нужно выбрать победителя. Это разговор о двух инструментах с разными функциями, которые отвечают на принципиально разные вопросы. CVSS спрашивает: насколько плоха эта уязвимость в теории? EPSS спрашивает: насколько вероятно, что её будут использовать прямо сейчас? Оба вопроса важны — но для разных целей.
Рассмотрим конкретный пример. Пусть у вас есть три уязвимости:
Уязвимость A: CVSS 9.8 / EPSS 0.04% / не в KEV. Теоретически катастрофична, но эксплойт невероятно сложен и публично недоступен.
Уязвимость B: CVSS 6.5 / EPSS 38% / в KEV. Умеренная по тяжести, но активно эксплуатируется прямо сейчас через публичный PoC-эксплойт.
Уязвимость C: CVSS 8.1 / EPSS 1.2% / не в KEV. Серьёзная, но эксплуатация требует специфических условий, которые редко встречаются в реальных сетях.
Если вы используете только CVSS, порядок приоритетов будет: A → C → B. Если вы используете CVSS вместе с EPSS и KEV, правильный порядок выглядит иначе: B → C → A. Уязвимость B требует немедленного устранения, потому что она уже эксплуатируется. Уязвимость A может подождать до следующего патч-окна.
Вывод: CVSS незаменим для понимания природы уязвимости и классификации по техническим критериям. EPSS незаменим для операционного принятия решений. KEV — это абсолютный сигнал «действовать немедленно». Только совместное применение всех трёх даёт обоснованный приоритет.
Важно также не путать EPSS с Temporal Score CVSS. Temporal Score пытается решить похожую задачу, добавляя информацию о наличии эксплойта — но делает это значительно менее точно и не обновляется ежедневно. EPSS принципиально лучше справляется с прогнозом реальной эксплуатации именно потому, что опирается на агрегированные данные о реальной активности угроз в интернете.
Risk-based vulnerability management: три метрики вместе
Risk-based vulnerability management (RBVM) — это подход к управлению уязвимостями, который ставит во главу угла не полноту покрытия (закрыть всё), а точность фокуса (закрыть самое опасное первым). Концептуально это кажется очевидным, но на практике требует серьёзной перестройки как процессов, так и инструментария.
RBVM работает с четырьмя ключевыми переменными: тяжестью уязвимости (CVSS), вероятностью эксплуатации (EPSS), фактом активных атак (KEV) и критичностью конкретного актива в вашей инфраструктуре (business context). Последний параметр часто оказывается самым недооцененным. База данных с персональными данными клиентов и тестовый сервер разработчика могут содержать одинаковую уязвимость с одинаковым CVSS — но последствия их компрометации несопоставимы.
Практическая модель приоритизации уязвимостей
Рабочая модель RBVM строится как матрица фильтров, которые применяются последовательно к каждой обнаруженной уязвимости. Первый фильтр — KEV: если CVE есть в каталоге CISA и актив экспонирован — немедленный патчинг без дискуссий. Второй фильтр — EPSS: если балл выше порогового значения (в большинстве организаций используют порог 10%), уязвимость переходит в приоритетную очередь независимо от CVSS. Третий фильтр — CVSS в связке с контекстом актива: серьёзная уязвимость на критичном интернет-экспонированном активе требует ускоренного закрытия, даже если EPSS умеренный. Четвёртый фильтр — всё остальное планируется в рамках регулярного патч-цикла.
Такая модель позволяет ежемесячно сокращать объём «неотложных» уязвимостей с нескольких тысяч до нескольких десятков — и при этом не терять ни одного реально опасного вектора атаки. Это не упрощение задачи, а её точная калибровка.
Роль контекста актива (Asset Criticality)
Зрелые RBVM-программы добавляют к трём базовым метрикам четвёртое измерение — классификацию активов по бизнес-значимости. Актив может быть помечен как «критичный» по нескольким критериям: он обрабатывает персональные или финансовые данные, он экспонирован в интернет, он является точкой единственного входа для ключевого бизнес-процесса, или его компрометация может привести к нарушению регуляторных требований (PCI DSS, GDPR, 152-ФЗ). Уязвимость с CVSS 7.5 и EPSS 3% на критичном активе вполне может обогнать в очереди уязвимость с CVSS 9.0 и EPSS 0.1% на изолированном внутреннем инструменте.
Инструменты и платформы для риск-ориентированного подхода
Рынок RBVM-инструментов сформировался достаточно зрелым. Среди коммерческих решений выделяются: Tenable One с интегрированным Asset Exposure Score, Qualys VMDR с TruRisk-оценкой, сочетающей CVSS, EPSS и KEV, Rapid7 InsightVM с Real Risk Score. Для организаций с ограниченным бюджетом существуют более доступные варианты: открытый OpenVAS в связке с ручной проверкой по KEV и EPSS API, а также платформы типа Vulners, агрегирующие данные из множества источников.
Независимо от выбранного инструмента ключевой элемент зрелой RBVM-программы — это SLA (Service Level Agreement) на устранение уязвимостей, привязанный не к CVSS-категории, а к риск-категории. Типичный набор: KEV на экспонированных активах — 24–72 часа; высокий EPSS — до 7 дней; критичный CVSS на критичных активах — до 14 дней; все остальные — следующий плановый патч-цикл (как правило, ежемесячно или ежеквартально).
Зрелость процесса: По оценке Gartner, к 2026 году организации, применяющие risk-based vulnerability management, будут в 3 раза реже сталкиваться с успешными атаками через известные уязвимости по сравнению с теми, кто по-прежнему опирается только на CVSS и ручную сортировку.
Где учиться управлению уязвимостями профессионально
Понимание CVSS, EPSS и KEV — это не абстрактная теория для экзаменов, а конкретный профессиональный навык, который напрямую влияет на защищённость организаций. Аналитики по уязвимостям, инженеры безопасности, пентестеры и специалисты по threat intelligence всё чаще сталкиваются с требованием умения не просто находить уязвимости, но и грамотно расставлять приоритеты — и именно этому посвящены лучшие современные курсы по кибербезопасности.
Если вы хотите системно освоить риск-ориентированный подход к управлению уязвимостями, обратите внимание на следующие направления подготовки: курсы по vulnerability management и risk-based security от таких провайдеров, как SANS Institute (курс SEC460), Offensive Security, а также специализированные треки на платформах Coursera и Pluralsight. Для тех, кто ориентирован на российский рынок, доступны программы от ведущих отечественных учебных центров, агрегированные на ibcourses.
Хорошая программа обучения по управлению уязвимостями должна охватывать: работу с CVE и NVD, интерпретацию метрик CVSS 3.1 и 4.0, применение EPSS в ежедневной практике, интеграцию KEV в процессы патчинга, построение SLA-матриц для разных типов активов и автоматизацию приоритизации через API и SOAR-инструменты.
Совет редакции ibcourses: Ищите курсы, в которых есть практические лабораторные работы с реальными CVE и живыми данными EPSS. Теоретическое знание метрик ничего не стоит без навыка применения их в условиях реальной инфраструктуры с сотнями открытых уязвимостей и ограниченными ресурсами на патчинг.
Управление уязвимостями — одна из немногих областей кибербезопасности, где аналитическое мышление и умение работать с данными ценятся наравне с техническими навыками. Специалист, который умеет превратить список из 2 000 CVE в чёткую очередь из 15 приоритетных задач — это специалист, которого ищет каждая зрелая security-команда. И именно этому стоит учиться целенаправленно.