Приоритизация уязвимостей с EPSS в кибербезопасности

Одна из главных проблем в управлении уязвимостями — огромный объём задач при ограниченных ресурсах. Не все уязвимости одинаково опасны, и не каждая требует срочного устранения. Даже уязвимость с высоким уровнем риска может не представлять реальной угрозы, если вероятность разработки эксплойта для неё крайне мала. Именно здесь на помощь приходит EPSS (Exploit Prediction Scoring System) — метрика, которая становится ключевым фильтром при расстановке приоритетов.

В предыдущей статье я описал решение по приоритизации уязвимостей на базе no-code-платформы Budibase. В этой статье покажу, как я реализовал поддержку EPSS и включил этот показатель в фильтрацию и анализ приоритета для оптимизации устранения уязвимостей.

Реализовав такую приоритизацию у себя, можно значительно повысить эффективность устранения уязвимостей, которые представляют угрозу. Я провел исследование — на рынке РФ во многих решениях по управлению уязвимостями EPSS до сих пор отсутствует.
Хорошие новости в том, что приоритезацию с EPSS можно реализовать и без дорогостоящих решений.

Что такое EPSS и чем он полезен

EPSS (Exploit Prediction Scoring System) — это, простыми словами, вероятность того, что конкретная уязвимость будет эксплуатирована в течение ближайших 30 дней. Значение выражается в процентах.

На момент написания статьи актуальной является 4-я версия модели, выпущенная 17 марта 2025 года. Разработкой занимается организация FIRST.org. Данные обновляются ежедневно, и доступны для скачивания в архиве в формате .csv.

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

Такой подход повышает эффективность, позволяя распределять ресурсы (время и усилия) на действительно критичные уязвимости в первую очередь, а второстепенные — отложить до появления риска или ресурсов.

В качестве примера: уязвимость с CVSS 7.0, но с EPSS 0.01 (то есть вероятность эксплуатации — 1%) представляет меньший риск, чем уязвимость с CVSS 6.5 и EPSS 0.91 (91% вероятность эксплуатации).

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

CVSS vs EPSS

Из изображения выше видно, что при учете EPSS с порогом в >10%:

• усилия затрачиваются в 2.7%, что гораздо меньше в отличие от CVSS 7+

• охват уязвимостей 63.2%, что немного меньше и это тоже хорошо

• эффективность 65.2%, что гораздо превышает эффективность в сравнении с CVSS 7+

Помимо оценки EPSS, существует также показатель процентиля — это доля (или процент) уязвимостей, имеющих такую же или более низкую вероятность эксплуатации.

Например, уязвимость с EPSS = 0.10 (10%) и процентилем 88 означает, что 88% всех других уязвимостей имеют более низкое значение EPSS. Другими словами, такая уязвимость входит в топ-12% наиболее вероятных к эксплуатации и заслуживает повышенного внимания.

Использование EPSS в сочетании с процентилем позволяет более точно оценивать приоритет устранения уязвимостей, особенно при большом объёме данных. Подробно об интерпретации можно прочитать в статье: How to understand and interpret EPSS Scores

Стоит помнить, что EPSS — это прогноз, а не гарантия 100% эксплуатации. Подробнее о принципах работы модели — на официальной странице: https://www.first.org/epss/model

Как я реализовал EPSS в своей системе на Budibase

Для реализации фильтрации по значению EPSS я сначала скачал архив с официального сайта first.org, содержащий актуальные оценки вероятности эксплуатации уязвимостей.
Пример содержимого CSV-файла из архива:

#model_version:v2025.03.14,score_date:2025-08-02T12:55:00Z
cve,epss,percentile
CVE-1999-0001,0.0142,0.79836
CVE-1999-0002,0.14818,0.94265
CVE-1999-0003,0.90339,0.99584
...

Далее я доработал Python-скрипт, который используется для выгрузки уязвимостей из решения VM, добавив в него:

• парсинг значений EPSS и процентиля,

• преобразование их в проценты (умножение на 100),

• округление до целых чисел.

Не все CVE присутствуют в выгрузке EPSS. Поэтому для тех записей, которых нет в выгрузке, я задавал значение 99.

После импорта данных в СУБД я реализовал в Budibase:

• форму фильтрации по EPSS-порогам, например, >10%,

• механизм автоматического обновления дашбордов на основе выбранного значения,

• две кнопки управления:

  1. Просмотр списка уязвимостей во всплывающем окне (modal view),

  2. Выгрузка результата в файл .csv для дальнейшей работы или отчётности.

После этого я обновил SQL-запросы в дашбордах Budibase, добавив условия для фильтрации по значению EPSS и процентилю.
Это позволило управлять отображением уязвимостей в зависимости от выбранных пороговых значений.

Пример блока условия:

... (
 CASE
 WHEN {{epssthr}}::text IS NULL THEN TRUE
 ELSE epssScore >= {{epssthr}}
 END ) AND (
 CASE
 WHEN {{epssrating}}::text IS NULL THEN TRUE
 ELSE epsspercentile >= {{epssrating}}
 END )
 ...

Так выглядит пример SQL-запроса для дашборда, который отображает наиболее уязвимые сервисы:

SELECT
COUNT(hostname) AS total, VulnerableEntity || ' ' || VulnerableEntityVersion AS VulnerableObject
FROM mat_allassets
WHERE osname ILIKE '%windows 20%' AND VulnerableEntity IS NOT NULL AND status = 'new' AND VulnerabilityIssueTime < CURRENT_DATE - {{days}}::interval AND ( 
 CASE
 WHEN {{ sev }}::text IS NULL THEN TRUE
 ELSE severity = {{ sev }}::text
 END )  AND ( 
 CASE
 WHEN {{expltbl}}::bool IS NULL THEN TRUE
 ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text
 END ) AND ( 
 CASE
 WHEN {{expltbl}}::bool IS NULL THEN TRUE
 ELSE metrics ILIKE 'Exploitable: {{expltbl}}%'::text
 END ) AND ( 
 CASE
 WHEN {{netvector}}::bool IS NULL THEN TRUE
 ELSE metrics ILIKE '%HasNetworkAttackVector: {{netvector}}%'::text
 END ) AND ( 
 CASE
 WHEN {{remedy}}::bool IS NULL THEN TRUE
 ELSE metrics ILIKE '%HasFix: {{remedy}}%'::text
 END ) AND ( 
 CASE
 WHEN {{vulntrend}}::bool IS NULL THEN TRUE
 ELSE VulnerIsTrend = '{{vulntrend}}'::text
 END ) AND ( 
 CASE
 WHEN {{hostimport}}::text IS NULL THEN TRUE
 ELSE HostImportance = '{{hostimport}}'::text
 END ) AND (
 CASE
 WHEN {{epssthr}}::text IS NULL THEN TRUE
 ELSE epssScore >= {{epssthr}}
 END ) AND (
 CASE
 WHEN {{epssrating}}::text IS NULL THEN TRUE
 ELSE epsspercentile >= {{epssrating}}
 END )
GROUP BY VulnerableObject--, VulnerableEntityVersion
ORDER BY total DESC
LIMIT 10;

Затем я добавил bindings переменных из UI в SQL запрос. О них я писал в прошлой статье по приоритизации уязвимостей.

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

На изображении ниже я указал порог EPSS ≥ 10, выбрал трендовые уязвимости старше 14 дней и наличие эксплойта. В результате сразу были отфильтрованы тысячи нерелевантных уязвимостей.

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

При использовании порога EPSS в 10% удаётся охватить 63,2% эксплуатируемых уязвимостей, при этом эффективность устранения составляет 65,2% — и всё это при меньших затратах ресурсов.

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

Что бы отключить использование EPSS в фильтрации — достаточно задать значение 0, и фильтр перестанет применяться.

Дополнительно, если задать фильтр по критичности уязвимости выше среднего, то, как правило, в выборке останутся RCE, Command Execution или SQL Injection — именно те уязвимости, которые действительно представляют повышенную угрозу для бизнеса.

Что получается в итоге

EPSS — это мощный инструмент, который позволяет существенно повысить эффективность приоритизации уязвимостей. Вместо того чтобы "тушить пожары вслепую", мы начали работать осознанно — по приоритету.

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

Будет интересно узнать в комментариях:
Используете ли вы EPSS в своей работе?
Даже если не для массовой приоритизации то может быть, в отдельных случаях, когда нужно понять, насколько опасна уязвимость на практике?