CVE-2025-0282 - stack-based buffer overflow в Ivanti Connect Secure (CVSS 9.0, CWE-121/CWE-787) - попала в каталог CISA KEV 8 января 2025 года: активная эксплуатация в ransomware-кампаниях. Публичный PoC на Exploit-DB (EDB-52213) появился 15 апреля 2025 - спустя три с лишним месяца. Для CVE-2024-50623 (unrestricted file upload в Cleo Harmony/VLTrader/LexiCom, CVSS 9.8, CWE-434) - обратная история: на Exploit-DB записи нет до сих пор, зато на GitHub с декабря 2024 лежит PoC от watchtowrlabs. Пайплайн, привязанный только к NVD + Exploit-DB, первый вектор пропустит из-за задержки публикации PoC, а второй - потому что в Exploit-DB его попросту нет (хотя CVE-2024-50623 сидит в CISA KEV с 13 декабря 2024, и подключение KEV-фида решает проблему). Ниже - как собрать автоматический сбор данных об уязвимостях, который не зависит от одного источника и обогащает каждый CVE контекстом эксплуатации до того, как это сделает NIST.
Зачем атакующим ваш пробел в разведке уязвимостей
Атакующие пользуются теми же базами, что и мы. В терминах MITRE ATT&CK это Vulnerability Scanning (T1595.002, Reconnaissance) и Scan Databases (T1596.005, Reconnaissance): сканирование диапазонов IP на известные CVE и поиск уязвимых версий ПО - Software (T1592.002, Reconnaissance). Разница - в скорости. Атакующая сторона мониторит GitHub, Telegram-каналы и форумы задолго до формального обогащения записи в NVD. Та же CVE-2024-50623, через которую Clop атаковала файловые трансферы Cleo, имела EPSS 0.9861 (Top 1% по вероятности эксплуатации) и SSVC-решение «Act» - но для пайплайнов, привязанных к Exploit-DB, этого вектора не существовало. Ноль. Пустота. Подробнее - в нашем материале про threat intelligence платформы.Когда SOC видит CVE без CVSS score, без CPE-маппинга, без CWE - для автоматизированного пайплайна этой уязвимости функционально нет. Для атакующего она существует с момента публикации PoC. Каждый час разрыва - окно для компрометации.
Финансовый контекст тоже давит: регуляторные рамки - от FedRAMP до приказов ФСТЭК №17 и №21 - ссылаются на severity scores при определении сроков устранения уязвимостей. Если score отсутствует (а для ~80% новых CVE его скоро не будет), SLA формально не запускается, уязвимость «зависает» вне процесса remediation. Штрафы по ФЗ-152 за утечку через незакрытую брешь от этого не уменьшаются.
NVD в 2026 году: конец универсального обогащения CVE
NIST перешёл к risk-based triage модели и отказался от цели полного анализа каждого CVE. По оценкам сообщества, полное обогащение метаданными (CPE-идентификаторы, CVSS score, CWE-классификация) теперь получают преимущественно записи в CISA KEV, CVE для ПО федерального правительства США и CVE для критического софта по Executive Order 14028 - а это малая часть от годового объёма.Остальные ~80% CVE попадают в NVD без CPE, без CVSS, без CWE. Для vulnerability management платформ, которые сопоставляют CVE с инвентаризацией активов через CPE-маппинг, такая запись операционно невидима. Сканер завершает проход, отчитывается «чисто» - а уязвимость существует и эксплуатируется. Красиво, правда?
Объём CVE-submissions за последние годы вырос кратно. NIST увеличил число обогащённых CVE, но даже этого не хватило: значительная часть опубликованных CVE получила статус «Not Scheduled» - обогащение не планируется без явного запроса.
Отдельная боль: NIST объявил, что больше не будет выставлять собственный CVSS score, если CNA (CVE Numbering Authority) уже предоставил свой. Но CNA-supplied scores исторически менее проверены - расхождения между CVSS-оценками от разных CNA бывают достаточными, чтобы перебросить CVE между severity-уровнями. Скоринговая картина стала неоднородной, и полагаться только на NVD - значит получать неполную картину.
Источники для агрегации данных об уязвимостях
Рабочий пайплайн vulnerability intelligence автоматизации строится на параллельном опросе нескольких источников с нормализацией в единую схему.| Источник | Что даёт | API / доступ | Rate limit |
|---|---|---|---|
| NVD API 2.0 | CVE, CPE, CVSS, CWE | REST, без ключа | 5 запросов/30 сек (50 с ключом) |
| CISA KEV | Подтверждённая эксплуатация, due dates | JSON-фид | Нет (обновление 1–2 раза/день) |
| FIRST EPSS | Вероятность эксплуатации за 30 дней | CSV/REST | Без ограничений |
| CISA Vulnrichment | SSVC-решения, timeline эксплуатации | GitHub API | Стандартный GitHub rate limit |
| OSV.dev | Уязвимости open-source пакетов (npm, PyPI, Maven) | REST | 100 запросов/мин |
| GitHub Advisory DB | GHSA, пакетные уязвимости | GraphQL | 5000 запросов/час (с токеном) |
Чего нет в таблице, но без чего пайплайн слепой: Exploit-DB и поиск PoC на GitHub. Структурированных API для автоматического мониторинга новых CVE у них нет, но наличие публичного PoC радикально меняет приоритет. Для Exploit-DB используется RSS-фид или SearchSploit CLI, для GitHub -
code search API с запросом по шаблону CVE-YYYY-NNNNN extension:py.OSV.dev отдельно ценен тем, что отдаёт данные на уровне конкретных пакетов. Для CVE-2021-44228 (Log4Shell, CVSS 10.0, EPSS 1.0000) OSV показывает, что уязвим
org.apache.logging.log4j:log4j-core начиная с версии 2.0-beta9, исправлено в 2.15.0. Этот уровень детализации - какой именно пакет и какие версии - отсутствует в чистом NVD-потоке и нужен для SCA-интеграций.Коммерческие провайдеры (VulnCheck, например) покрывают SSVC-оценками значительно больше CVE, чем бесплатный CISA Vulnrichment. Разница существенная, но Vulnrichment бесплатен и подходит командам без бюджета на коммерческий threat intelligence. Если бюджет есть - берите оба.
Автоматизация CVE обработки: от сбора до обогащения
Контраст на верифицированных данных - тут становится интересно:
| CVE | CVSS | EPSS | Percentile | SSVC | Эксплуатация |
|---|---|---|---|---|---|
| CVE-2023-22900 (Efence SQLi, CWE-89) | 9.8 | 0.0103 | 60.69% | Track | Не зафиксирована, публичного PoC не обнаружено |
| CVE-2023-24154 (TOTOLINK CMDi, CWE-77) | 9.8 | 0.0195 | 78.46% | Track* | В Exploit-DB нет, наличие PoC на GitHub не подтверждено |
| CVE-2024-50623 (Cleo upload, CWE-434) | 9.8 | 0.9861 | 99.92% | Act | Активная с 13.12.2024 |
| CVE-2025-0282 (Ivanti BoF, CWE-121/787) | 9.0 | 0.9997 | 99.98% | Act | Активная с 08.01.2025 |
Три CVE с CVSS 9.8 - и разброс EPSS от 0.01 до 0.99. По голому CVSS все три получат одинаковый приоритет. На практике - это как ставить одинаковый замок на дверь квартиры и на дверь серверной.
Запрос EPSS для конкретного CVE:
Python:
import requests
def get_epss(cve_id: str) -> dict:
resp = requests.get(
f"https://api.first.org/data/v1/epss?cve={cve_id}"
)
data = resp.json()["data"]
if data:
return {"epss": float(data[0]["epss"]),
"percentile": float(data[0]["percentile"])}
return {"epss": None, "percentile": None}get_epss() для каждого CVE из NVD-фида и добавляет результат к записи перед отправкой в SIEM или тикет-систему. Запрос к EPSS API не требует аутентификации, но для массовой обработки используйте batch-запросы (?cve=CVE-1,CVE-2,...,CVE-100) вместо тысяч отдельных вызовов - иначе рискуете словить блок на уровне CDN/WAF.Автоматический скоринг уязвимостей и интеграция vulnerability intelligence с SOC
Формула приоритизации вместо голого CVSS
Рабочая модель для SOC, которая вытесняет чистый CVSS-скоринг:Приоритет = f(EPSS, KEV_status, SSVC_decision, asset_exposure, business_criticality)
Конкретная логика маршрутизации:
- CVE в CISA KEV - немедленный патч, SLA 24 часа
- EPSS > 0.6 И SSVC = Act - высокий приоритет, SLA 48 часов
- EPSS > 0.3 И PoC доступен (GitHub/EDB) - средний приоритет, SLA 7 дней
- CVSS >= 9.0, но EPSS < 0.1 И SSVC = Track - мониторинг без немедленного действия
Detection-чеклист: что пайплайн отдаёт в SIEM
Каждая запись из пайплайна vulnerability intelligence должна содержать:- CVE ID + affected CPE - корреляция с asset inventory в SIEM
- EPSS score + percentile - динамическая приоритизация алертов
- KEV status - boolean-флаг для немедленной эскалации
- SSVC decision (Track / Track* / Attend / Act) - маршрутизация в playbook
- PoC availability - URL репозитория или EDB-ID, если существует
- Days since disclosure - отслеживание exposure window
- CWE - тип уязвимости для группировки (все CWE-434 = file upload, все CWE-89 = SQLi)
Точки интеграции
SIEM (Elastic, Splunk, MaxPatrol SIEM). Данные передаются через REST API или syslog в JSON:cve_id, cvss_score, epss_score, kev_status, ssvc_decision, affected_cpe, poc_url. Корреляция сопоставляет affected_cpe с данными инвентаризации активов.Тикет-система (Jira, TheHive). Автоматическое создание задач при совпадении CVE с активом из CMDB. TheHive + MISP - связка для хранения IOC и vulnerability data в одном месте. В реальных проектах это экономит кучу времени на ручном заведении тикетов.
Мессенджеры. Slack/Telegram webhook для критических алертов: CVE ID, CVSS, EPSS, KEV-статус, затронутые продукты, PoC-ссылка. Когда в три ночи прилетает алерт с KEV=true и EPSS 0.99 - хочется видеть всё сразу, а не лезть в консоль.
Оркестрация. n8n или Airflow для scheduling и retry logic. Типовой workflow: каждые 6 часов опросить NVD API, обогатить EPSS, проверить KEV, найти PoC на GitHub, отправить результаты в Slack + SIEM.
Ограничение подхода: пайплайн на публичных API работает с задержкой от часов до суток относительно коммерческих платформ (VulnCheck, Recorded Future), которые мониторят GitHub, форумы и мессенджеры в реальном времени. Для организаций с бюджетом на threat intelligence - коммерческие решения дополняют, но не заменяют собственную автоматизацию. Для команд без бюджета - описанный подход закрывает основную потребность в vulnerability management автоматизации. Не идеально, но работает.
Последние два года я строю пайплайны vulnerability intelligence для разных команд - от двух человек в региональном банке до SOC на 30 аналитиков. Вывод один: проблема не в технологиях, а в привычке верить единственному источнику правды. NVD был таким источником 20 лет, и инерция оказалась сильнее фактов. Даже после перехода NIST к triage-модели многие VM-процессы продолжают ссылаться на «CVSS score из NVD» как триггер SLA - score, которого для 80% новых CVE больше не будет.
EPSS меняет подход к приоритизации радикальнее, чем любой другой инструмент за последние пять лет. Но сопротивление реально: security-менеджеры не готовы объяснять руководству, почему CVE с CVSS 9.8 получила низкий приоритет. Проще залатать всё подряд и отчитаться. Это работает ровно до момента, когда количество необогащённых CVE начнёт расти быстрее, чем пропускная способность команды - и «латать всё подряд» станет физически невозможно. Кто выстроит автоматизированный pipeline с множественными источниками сейчас - через год будет объяснять остальным, как это делается. Если хочется обсудить конкретные реализации обогащения CVE-фидов или обменяться конфигами n8n-workflow для VM - на форуме codeby.net разбирают vulnerability intelligence и автоматизацию VM-процессов.
