В мире управления уязвимостями давно существует парадокс: в системе могут содержаться сотни критических проблем, но эксплуатируются из них лишь единицы. Или, наоборот, ИБ-недостаток со средним CVSS (Common Vulnerability Scoring System) может внезапно стать причиной инцидента, потому что реально используется в атаках прямо сейчас. Этот разрыв между теоретической опасностью и реальной угрозой подчеркивает необходимость более совершенных подходов к приоритизации.
Вопрос, который задают себе все команды AppSec и DevSecOps: «Как понять, что фиксить в первую очередь, если ресурсы ограничены?»
Одно из наиболее эффективных решений – каталог известных эксплуатируемых уязвимостей CISA KEV (Known Exploited Vulnerabilities). В этой статье разберёмся, как он работает, чем отличается от привычных метрик и как правильно его использовать в реальных проектах.
Проблема традиционного подхода: CVE ≠ риск
В современности большинство процессов управления уязвимостями строится вокруг трёх сущностей:
CVE (Common Vulnerabilities and Exposures): что сломано,
CVSS (Common Vulnerability Scoring System): насколько это опасно теоретически,
EPSS (Exploit Prediction Scoring System): вероятность эксплуатации.
Хотя эти метрики кажутся логичными и всеобъемлющими, на практике они часто оказываются недостаточными для эффективной приоритизации уязвимостей. Почему?
CVSS оценивает потенциал уязвимости. Высокий балл CVSS (9.8) указывает на потенциально разрушительную уязвимость, но не гарантирует, что она будет активно эксплуатироваться злоумышленниками. И наоборот, уязвимость со средним баллом (5.3) может быть активно использована в атаках, но ее CVSS-оценка не отражает настоящую критичность этой угрозы в рамках системы. CVSS уязвимости из открытых источников указывает на потенциал эксплуатации уязвимости в вакууме, не учитывая особенности систем. Эта оценка описывает, что только может случиться, но не то, что происходит на самом деле.
EPSS – вероятностная модель. EPSS строится на результатах обработки больших массивов данных и предсказывает общую вероятность эксплуатации. Однако она не может гарантировать, что конкретная уязвимость уже используется в атаках. Это прогноз, а не подтвержденный факт, и для отдельных уязвимостей предсказания EPSS могут не соответствовать текущей ситуации.
Таким образом, эти метрики являются лишь предположениями о том, как уязвимости могут “выстрелить” при атаке и могут не соответствовать реальности. Именно этот критически важный пробел и призван закрыть каталог CISA KEV.
Что такое CISA KEV
CISA KEV – это публичный каталог уязвимостей, которые подтвержденно эксплуатируются в реальных атаках. Поддерживается агентством Cybersecurity and Infrastructure Security Agency (CISA) и служит авторитетным источником информации для организаций, стремящихся приоритизировать свои усилия по устранению уязвимостей.
Это сильно отфильтрованный набор, куда попадают только те уязвимости, для которых существуют подтвержденные кейсы эксплуатации и зафиксированы атаки (APT, массовые кампании, ransomware и т.д.), и которые представляют реальную угрозу инфраструктуре. В отличие от баз CVE или NVD, где уязвимости публикуются массово, в KEV применяется ручной и аналитический отбор.
Источники:
Threat intelligence (включая государственные источники): предоставляют информацию об актуальных тактиках, техниках и процедурах злоумышленников.
Инциденты (включая расследования атак).
Данные от вендоров в области ИБ: поставщики решений по безопасности делятся информацией об обнаруженных и эксплуатируемых уязвимостях.
OSINT / malware campaigns: анализ открытых источников и кампаний вредоносного ПО также служит важным источником данных.
Критерий попадания в каталог: уязвимость должна быть подтвержденно использована в атаках.
Структура записи KEV
Каждая запись в каталоге CISA KEV содержит стандартизированный набор информации, который помогает организациям быстро понять суть угрозы и необходимые действия.
Типичная запись включает:
CVE ID: Уникальный идентификатор уязвимости.
Vendor / Product: Информация о затронутом поставщике и продукте.
Description: Краткое описание уязвимости.
Date Added: Дата добавления уязвимости в каталог KEV.
Required Action: Рекомендуемые действия по устранению уязвимости (например, применение патча, обновление программного обеспечения).
Due Date(для федеральных систем США): дата, к которой необходимо устранить данную уязвимость.
Пример (упрощённо):
CVE-2023-XXXXX
Vendor: Apache
Product: Struts
Description: RCE vulnerability actively exploited
Date Added: 2023-XX-XX
Required Action: Apply patch
KEV не дает скоринговую оценку, подобную CVSS. Вместо этого он предоставляет бинарный сигнал: факт эксплуатации. Это фундаментальное отличие, которое меняет подход к приоритизации уязвимостей.
KEV vs CVSS vs EPSS
Разложим роли:
Метрика | Что показывает |
|---|---|
CVE | наличие уязвимости |
CVSS | техническую критичность |
EPSS | вероятность эксплуатации |
KEV | факт эксплуатации |
Где KEV решает
KEV особенно полезен в:
SCA (Software Composition Analysis): помогает приоритизировать уязвимости в сторонних библиотеках и компонентах, фокусируясь на тех, которые подтверждённо эксплуатируются.
SBOM-анализ (Software Bill of Materials): позволяет быстро выявлять эксплуатируемые уязвимости в составе программного обеспечения.
Asset management: помогает командам управления активами идентифицировать наиболее критичные активы, содержащие эксплуатируемые уязвимости.
Patch management: ускоряет процесс принятия решений о применении патчей, направляя усилия на устранение уязвимостей, которые представляют непосредственную угрозу.
Incident response(ретроспектива): в процессе реагирования на инциденты KEV может использоваться для ретроспективного анализа, помогая понять, какие уязвимости могли быть использованы в атаке.
Как использовать KEV в SCA
В контексте практики SCA (Software Composition Analysis) есть уникальная проблема: зависимости обновляются редко, при этом уязвимостей много.
Каталог KEV даёт простой и очень практичный сигнал о том, что уязвимость нужно срочно устранять. Это позволяет командам DevSecOps и AppSec быстро идентифицировать наиболее опасные недостатки в своих зависимостях и сосредоточить усилия на их устранении, минимизируя риск реальных атак.
Лучший подход к использованию KEV – дополнение существующих метрик. Интеграция KEV в комплексную стратегию управления уязвимостями позволяет создать многоуровневую систему приоритизации, которая учитывает как потенциальную опасность, так и реальную угрозу.
Идеальная комбинация факторов для приоритизации включает:
Базовую фильтрацию: есть CVE → уже повод посмотреть
Оценку опасности: CVSS (насколько плохо может быть)
Вероятность: EPSS (насколько вероятно)
Факт эксплуатации: KEV (используется ли прямо сейчас)
Хорошая рабочая модель:
KEV → приоритет №1 (фикс немедленно)
EPSS высокий → приоритет №2
CVSS высокий → приоритет №3
Или проще: KEV = “исправить прямо сейчас”
Рассмотрим несколько типичных сценариев, демонстрирующих, как KEV меняет подход к приоритизации:
1. RCE в библиотеке с высоким CVSS и KEV
Решение: немедленный фикс. Несмотря на то, что EPSS может быть средним, факт наличия в KEV означает, что уязвимость уже эксплуатируется, и ее устранение является наивысшим приоритетом.
CVSS: 9.8 (Критический)
EPSS: Средний
KEV: Есть
2. Высокий CVSS, но без активной эксплуатации
Решение: можно отложить. Хотя CVSS высок, отсутствие KEV и низкий EPSS указывают на то, что уязвимость пока не представляет непосредственной угрозы. Ее можно устранить в рамках планового обслуживания или следующего цикла патчинга.
CVSS: 9.0 (Высокий)
EPSS: Низкий
KEV: Нет
3. Средний CVSS, но KEV есть
Решение: приоритет выше, чем у “критического” без KEV.
Несмотря на средний балл CVSS, факт активной эксплуатации (KEV) делает эту уязвимость более опасной, чем многие уязвимости с высоким CVSS, которые не эксплуатируются. Здесь реальная угроза важнее теоретической оценки.
CVSS: 6.5 (Средний)
EPSS: Не указан (или низкий/средний)
KEV: Есть
Какие ограничения есть у KEV
Несмотря на свою ценность, этот каталог имеет определенные ограничения:
Неполный список: KEV включает только часть всех существующих уязвимостей. В него попадают лишь те, для которых CISA смогла собрать надежные доказательства активной эксплуатации. Это означает, что существуют и другие эксплуатируемые уязвимости, которые еще не были добавлены в каталог.
Существует задержка (лаг): между началом активной эксплуатации уязвимости злоумышленниками и ее попаданием в каталог KEV может пройти некоторое время. Этот “лаг” обусловлен необходимостью сбора и проверки доказательств.
Отсутствие контекста вашей системы: KEV предоставляет глобальный сигнал об эксплуатации, но не учитывает специфику вашей инфраструктуры. Он не дает информации о том, является ли уязвимость реально достижимой в вашей среде или может ли она быть эксплуатирована в вашем конкретном окружении. Например, дефект может быть в KEV, но затрагиваемый компонент может быть недоступен извне или уже защищен другими средствами контроля.
Практическая проблема: KEV есть, но его не используют
Несмотря на очевидную ценность и практическую значимость CISA KEV, в реальных проектах часто возникают ситуации, когда этот инструмент не используется в полной мере. Типичные проблемы:
Отсутствие интеграции в пайплайны: KEV не всегда интегрирован в автоматизированные процессы разработки и безопасности (CI/CD-пайплайны), из-за чего проверки могут быть неэффективными и возникнет необходимость ручного тестирования.
Нет автоматической корреляции с SBOM: Отсутствие автоматического сопоставления уязвимостей из SBOM с каталогом KEV означает, что команды могут упускать критически важные сигналы об активной эксплуатации.
Фокус только на CVSS: Многие команды по-прежнему ориентируются исключительно на баллы CVSS для приоритизации, игнорируя более актуальные данные об эксплуатации.
В итоге критические с точки зрения реальных атак уязвимости теряются в “шуме” из тысяч потенциальных проблем, что снижает общую эффективность программы управления уязвимостями и увеличивает риск успешных кибератак.
Как мы реализовали интеграцию с CISA KEV в AppSec.Track
Мы встроили в нашу OSA/SCA-платформу поддержку KEV непосредственно в процесс анализа зависимостей. Что это дает:
Автоматическое сопоставление CVE из SBOM с KEV: наша платформа автоматически сопоставляет уязвимости, обнаруженные в компонентах, с каталогом KEV, выделяя те, которые активно эксплуатируются.
Выделение реально эксплуатируемых уязвимостей: позволяет командам быстро идентифицировать наиболее критичные угрозы, не тратя время на анализ тысяч потенциальных проблем.
Приоритизация без ручного анализа: автоматическая приоритизация значительно ускоряет процесс реагирования и позволяет сосредоточить ресурсы команды на наиболее важных задачах.
Как это работает на примере SCA-анализа:
AppSec.Track сканирует зависимости проекта.
Формируется список обнаруженных компонентов (SBOM или через прямой анализ манифестов – package.json, go.mod, requirements.txt и др.) и их уязвимостей (CVE).
Для запрашиваемого компонента плагин обращается к фиду AppSec.Track, размещённому в инфраструктуре сервиса, для получения сведений о составе компонентов и известных уязвимостях (CVE). При этом на стороне клиента используется кэш, позволяющий ускорять обработку повторных запросов и снижать количество обращений через интернет.
Данные о наличии эксплуатации (CISA KEV) заранее импортируются в фид и хранятся вместе с уязвимостями, поэтому признак exploited in the wild доступен без дополнительной корреляции в момент запроса.
На основе преднастроенных политик (quality gates), в том числе по политике KEV, принимается решение о необходимости внесения фиксов. Пример в SCA:
Как это работает на примере OSA-анализа:
AppSec.Track интегрируется с репозиторий-менеджером (например, Sonatype Nexus) через нативный плагин и перехватывает все запросы на загрузку open-source компонентов.
Для запрашиваемого компонента плагин обращается к фиду AppSec.Track для получения информации о составе компонентов и CVE; здесь, как и в SCA, на стороне клиента используется кэш, позволяющий ускорять обработку повторных запросов и снижать количество обращений через интернет.
Данные CISA KEV заранее импортируются в фид и хранятся вместе с уязвимостями. Признак exploited in the wild доступен без дополнительной корреляции в момент запроса.
На основе quality gates, в том числе по политике KEV, принимается решение: разрешить загрузку компонента разработчику или заблокировать его.
Пример детектирования и блокировки компонента с наличием KEV (плагин):
Пример факта детектирования и блокировки компонента с наличием KEV (в AppSec.Track):
Практический эффект
Снижение шума: из сотен CVE остаются десятки действительно важных;
Фокус на реальных атаках: команда работает с тем, что уже используют злоумышленники;
Ускорение реакции: KEV → триггер для немедленного действия.
Вывод
Современный AppSec уже не может опираться только на CVSS: сканер выдает список, сортируем по 9.8 – чиним, остальное откладываем. В итоге ресурсы тратятся на критикалы, а инциденты приходят из совсем других мест.
Чтобы реально управлять рисками, нужно учитывать вероятность (EPSS), контекст (reachability) и, самое главное, факт эксплуатации уязвимости (KEV). Именно поэтому его интеграцию в процессы SCA и управления уязвимостями мы считаем необходимой и реализовали это у себя в продукте, чтобы синхронизировать приоритизацию с реальной картиной атак.