Как понять, какие уязвимости исправлять первыми

Почему сортировка по CVSS убивает вашу команду безопасности — и что делать вместо этого

Когда "критично" значит всё — это значит ничего

Представьте себе утро понедельника в команде безопасности среднего размера. Сканер вернул 4 000 уязвимостей. 1 200 из них помечены как Critical или High. Формально команда обязана обработать каждую. На практике у неё есть ресурс на 30–40 исправлений в неделю.

Это не гипотетическая ситуация. Это повседневная реальность большинства DevSecOps-команд в 2025–2026 годах.

Проблема не в том, что уязвимостей слишком много (хотя это тоже правда). Проблема в том, что стандартные инструменты — прежде всего CVSS — дают одно и то же наименование "критическая" тысячам совершенно разных по реальному риску записей. И команды начинают двигаться в произвольном порядке: по дате добавления, по громкости CVE-ID, по тому, что первым попалось на глаза. Это неэффективно и опасно.

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

Материал будет полезен AppSec- и DevSecOps-инженерам, Tech Lead и Engineering Manager, которые отвечают за практику управления уязвимостями, а также CTO и VP Engineering, которым нужно понять, почему "патчить по CVSS" — это системная ошибка.

Часть 1. Масштаб проблемы: цифры, которые меняют всё

Объём CVE вышел за пределы человеческих возможностей

По данным NIST, с 2020 по 2025 год количество CVE-записей выросло на 263% [1]. В 2025 году было опубликовано 46 407 CVE — на 16% больше, чем в 2024-м [2]. Первый квартал 2026 года показывает ещё на треть больше, чем аналогичный период прошлого года. Это 127 новых уязвимостей в сутки.

Одновременно сам National Vulnerability Database (NVD) оказался в структурном кризисе. В апреле 2026 года NIST официально перешёл на модель тиажа: теперь полную аналитику (включая CVSS-баллы) NVD обрабатывает только для CVE, попавших в каталог CISA KEV, федерального программного обеспечения и критической инфраструктуры по Executive Order 14028 [1]. Остальные CVE — в статусе "Not Scheduled". По состоянию на момент перехода около 55 000 CVE за 2024–2025 годы ждали полного обогащения [2].

Практическое следствие: если ваша команда строит приоритизацию на базе CVSS-баллов из NVD, значительная часть входных данных либо отсутствует, либо появляется с задержкой в недели и месяцы.

Временной разрыв закрылся — и пошёл в минус

В 2018 году у команд было в среднем 63 дня между публичным раскрытием уязвимости и первой зафиксированной эксплуатацией [3]. К 2024 году показатель Mean Time to Exploit (TTE) по данным Mandiant стал отрицательным: в среднем -1 день. В 2025 году — уже -7 дней [3, 4].

Это значит, что атаки в среднем начинаются до того, как выходит патч. Злоумышленники мониторят репозитории, участвуют в disclosure-процессах, реверсируют патчи сразу после релиза. CrowdStrike в своём отчёте 2026 года зафиксировал, что 42% эксплуатируемых уязвимостей были атакованы ещё до публичного раскрытия [3].

При этом компании в среднем тратят 74 дня на патчинг критических уязвимостей в приложениях и 32 дня — в edge-устройствах вроде VPN и файрволов [5]. Разрыв между скоростью атакующих и скоростью защитников не сокращается — он растёт.

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

Часть 2. Почему CVSS — плохой компас для приоритизации

Что CVSS измеряет на самом деле

CVSS (Common Vulnerability Scoring System) — стандарт FIRST для измерения технической тяжести уязвимости [6]. Важно понимать: CVSS измеряет severity (тяжесть), а не risk (риск). Это разные вещи.

CVSS описывает, насколько плоха уязвимость в изолированном, теоретическом сценарии. Он не учитывает:

• достижима ли уязвимость из сети конкретной организации;
• насколько критичен для бизнеса атакуемый актив;
• эксплуатируется ли уязвимость прямо сейчас кем-либо в реальности;
• есть ли компенсирующие контроли (WAF, сегментация, EDR-правила).

NIST прямо указывает в документации NVD: "CVSS is not a measure of risk" [6]. Тем не менее большинство vulnerability-программ строятся именно на CVSS как на основной метрике приоритизации.

Практические сбои CVSS-ориентированного подхода

Первая проблема — score inflation. Исследования FIRST показывают, что среди всех CVE с оценкой 7.0 и выше только около 2.3% наблюдаются в реальных попытках эксплуатации в течение месяца [7]. Остальные 97.7% никогда не встретятся с реальным злоумышленником — по крайней мере, не в этом месяце, и не в среднестатистической организации.

Вторая проблема — обратная: атаки происходят через уязвимости со средним CVSS. По данным Q1 2025, 28% эксплуатируемых уязвимостей имели только средний CVSS-балл [7]. Если ваша команда фокусируется на Critical/High и игнорирует остальное, она системно пропускает четверть реально опасного.

Третья проблема — несогласованность оценок. В практике встречаются ситуации, когда разные CNА присваивают одной уязвимости кардинально разные баллы [8]. Это происходит потому, что CVSS — экспертная оценка, а не детерминированный алгоритм.

Четвёртая проблема — контекст не учитывается вообще. Уязвимость с CVSS 9.8 на гостевой Wi-Fi-точке несёт принципиально иной риск, чем та же оценка на платёжной системе, напрямую связанной с банком [8]. CVSS не знает, что это разные активы.

Что изменил CVSS 4.0

В конце 2023 года FIRST выпустил CVSS v4.0 с важными архитектурными изменениями [9]. Появилась группа Threat Metrics (ранее Temporal) для учёта реальных данных об эксплуатации. Добавлено понятие Attack Requirements — условий вне контроля атакующего, необходимых для эксплуатации. В 2025 году началась постепенная миграция, и это сыграло роль в снижении доли Critical CVE (с 12.8% до 7.4% за год) [2].

CVSS 4.0 — шаг вперёд, но он не решает фундаментальную проблему: оценка остаётся универсальной и не учитывает специфику конкретной инфраструктуры. Это инструмент для описания уязвимости, а не для принятия решения о приоритете.

Часть 3. Три инструмента, которые меняют картину

Современная приоритизация опирается на три дополнительных сигнала, каждый из которых добавляет измерение, которого нет в CVSS.

EPSS: вероятность эксплуатации в ближайшие 30 дней

Exploit Prediction Scoring System (EPSS) — модель, разработанная FIRST, которая оценивает вероятность того, что уязвимость будет эксплуатирована в дикой природе в течение следующих 30 дней [10]. Оценка строится на основе данных NVD, CISA KEV, Exploit-DB, threat intelligence-фидов и истории эксплуатации — с применением машинного обучения.

Результат — число от 0 до 1. Уязвимость с EPSS 0.92 имеет 92% вероятность быть атакованной в следующий месяц. С EPSS 0.001 — практически нулевую.

В марте 2025 года вышел EPSS v4, который обрабатывает более 250 000 точек threat intelligence ежедневно и охватывает даже CVE из бэклога NVD, у которых ещё нет CVSS-оценки [10]. Это принципиально важно в условиях, когда NVD не успевает обрабатывать входящий поток.

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

Парадокс, зафиксированный в исследованиях: уязвимости с высокой вероятностью эксплуатации (EPSS > 0.7) патчируются в среднем за 109 дней, тогда как с низкой — за 76 дней [7]. Команды часто тратят больше времени именно на то, что атакуется быстрее. Это системная инверсия приоритетов.

CISA KEV: уже эксплуатируется прямо сейчас

Known Exploited Vulnerabilities (KEV) — каталог CISA, в который включены уязвимости с подтверждённой активной эксплуатацией в реальных атаках [11]. По состоянию на конец 2025 года каталог содержал 1 484 записи — на 20% больше, чем в конце 2024-го [11]. В 2025 году CISA добавила 245 CVE, из которых 24 были напрямую связаны с атаками ransomware-групп.

Если уязвимость в KEV — это факт, а не прогноз. Кто-то прямо сейчас использует её в реальных атаках на реальные организации. Это самый сильный сигнал для немедленного действия.

Важная оговорка: KEV — лишь вершина айсберга. По данным VulnCheck, в 2025 году было зафиксировано 883 CVE с первой эксплуатацией в дикой природе, тогда как CISA добавила в каталог только 245 [2]. KEV отстаёт от реальной картины — но именно потому, что CISA придерживается высокой планки доказательства.

Ещё один важный факт: по данным VulnCheck, 81% CVE, впервые эксплуатированных в 2025 году, были раскрыты до 2025 года [2]. Атакующие используют старые уязвимости, которые остаются непропатченными. Это опровергает популярный рефлекс "патчить свежие CVE первыми".

Критичность актива: без неё два предыдущих инструмента бесполезны

Даже идеальная комбинация CVSS + EPSS + KEV даёт одну и ту же оценку для уязвимости на тестовом сервере разработчика и на продакшн-сервере с персональными данными 10 миллионов пользователей. Контекст актива радикально меняет реальный приоритет [12].

Оценка критичности актива строится на нескольких факторах:

• доступность из интернета (публичный edge vs. внутренний сервис);
• тип данных, которые обрабатывает система (PII, платёжные данные, медицинская информация);
• роль в бизнес-процессах (mission-critical vs. вспомогательные инструменты);
• наличие компенсирующих контролей (сегментация, MFA, WAF, EDR-правила).

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

Часть 4. SSVC: от цифры к действию

CVSS, EPSS и KEV дают данные. Но данные — не решение. Решение — это конкретное действие: исправить сейчас, отслеживать, отложить. Именно для этого создана методология SSVC.

Что такое SSVC

Stakeholder-Specific Vulnerability Categorization (SSVC) — фреймворк от Carnegie Mellon SEI, разработанный совместно с CISA [13]. В отличие от систем оценки, SSVC — это дерево решений: аналитик последовательно отвечает на 4–6 вопросов и на выходе получает не число, а рекомендуемое действие.

Ключевые узлы дерева решений в модели Deployer (для организаций, развёртывающих ПО):

1. Exploitation — есть ли публичный PoC или зафиксированная активная эксплуатация?
2. Automatable — может ли атакующий автоматизировать эксплуатацию (mass scanning + exploit)?
3. Technical Impact — даёт ли эксплуатация частичный или полный контроль?
4. Mission and Well-being Impact — насколько критичен затронутый актив для миссии организации?

На выходе — одно из четырёх решений [13]:

• Act: немедленное действие, наивысший приоритет. Активная эксплуатация + высокий impact + критичный актив.
• Attend: ускоренное исправление, быстрее обычного цикла.
• Track*: внимательный мониторинг, статус может измениться.
• Track: стандартный цикл, плановое исправление.

По исследованиям, только около 0.06% CVE достигает уровня "Act" [14]. Это то самое сжатие очереди с тысяч записей до единиц.

Зачем нужен SSVC, если есть KEV

KEV даёт бинарный факт: эксплуатируется / не эксплуатируется. SSVC учитывает этот факт как один из узлов дерева и дополняет его контекстом: автоматизируема ли атака, каков технический impact, критичен ли актив для вашей организации конкретно.

Как формулирует документация SEI: "Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes" [13]. SSVC — не замена CVSS, EPSS или KEV. Это слой принятия решения поверх этих сигналов.

Корректная последовательность работы:

• CVSS даёт язык описания тяжести.
• EPSS добавляет вероятность реальной эксплуатации.
• KEV фиксирует подтверждённую эксплуатацию.
• Reachability-анализ отвечает, достижим ли уязвимый код в вашей среде.
• SSVC переводит всё это в конкретное действие.

Практическая реализация SSVC

CISA опубликовала два варианта модели: упрощённый Tier-1 (можно запустить за две недели поверх существующего CVSS + KEV пайплайна) и полноценную Deployer-модель (требует калибровки таксономии mission-impact, занимает квартал-полтора) [15].

Для организаций за пределами федерального сектора Tier-1 — валидная отправная точка. Недостаток: он даёт меньше дискриминации внутри band Attend и Track, поэтому эти очереди будут длиннее, чем при полной Deployer-реализации.

Важно: SSVC можно кастомизировать. Можно переименовать уровни, изменить SLA для каждой категории, добавить или убрать узлы. Методология намеренно гибкая.

Часть 5. Decision framework: как выглядит рабочий процесс

Ниже — операционная последовательность, которую можно адаптировать под свой контекст.

Шаг 1. Инвентаризация и классификация активов

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

Для каждого актива определите:

• Является ли он публично доступным из интернета?
• Какие данные он хранит или обрабатывает (PII, платёжные данные, секреты)?
• Является ли он частью mission-critical бизнес-процесса?
• Какие компенсирующие контроли уже применяются?

Результат — тег критичности (например: Critical, High, Medium, Low), который будет использоваться как входной параметр для приоритизации уязвимостей.

Шаг 2. Первичная фильтрация по KEV

При появлении новой уязвимости первый вопрос: есть ли она в CISA KEV? Если да — это автоматически поднимает приоритет в независимости от CVSS. Уязвимость с CVSS 7.0 в KEV опаснее уязвимости с CVSS 9.8 без KEV, если последняя никогда не эксплуатировалась в дикой природе.

Шаг 3. Проверка EPSS

Для CVE вне KEV: EPSS-оценка выше 0.7 (70% вероятность эксплуатации в 30 дней) — сигнал к ускоренному рассмотрению. EPSS выше 0.9 требует такого же внимания, как KEV. Для CVE с EPSS ниже 0.01 можно установить более длинный SLA или вовсе перевести в Track.

Шаг 4. Наложение на критичность актива

Один и тот же KEV + высокий EPSS на разных активах требует разного ответа:

• Уязвимость на публичном API с PII данными → Act.
• Та же уязвимость на изолированном dev-стенде без продакшн-данных → Attend или Track.

Именно это наложение даёт реальный приоритет.

Шаг 5. Reachability-анализ

Является ли уязвимый код достижимым в вашей конкретной среде? Для зависимостей: используется ли уязвимая функция в реальном call path? Для сетевых уязвимостей: доступен ли сервис с потенциально враждебных сегментов сети?

Этот вопрос позволяет устранить значительную часть шума из SAST/SCA-отчётов: уязвимость в библиотеке, которая включена в проект, но код которой никогда не вызывается, несёт существенно меньший реальный риск.

Шаг 6. SSVC-решение

После прохождения шагов 1–5 у аналитика есть все данные для прохождения SSVC-дерева:

• Exploitation: Known/PoC/Active.
• Automatable: Yes/No.
• Technical Impact: Partial/Total.
• Mission Impact: из классификации актива.

На выходе — Act, Attend, Track*, Track — и конкретный SLA для каждого.

Шаг 7. SLA и метрики

Пример SLA по SSVC-решению (настраивается под организацию):

• Act: исправление или митигация в течение 24–72 часов, немедленная коммуникация с CISO.
• Attend: исправление в ближайшем спринте, не позже 14 дней.
• Track*: исправление в течение следующего квартала, еженедельный мониторинг статуса.
• Track: плановое исправление в рамках обычного цикла (30–90 дней в зависимости от типа актива).

Часть 6. Распространённые ошибки и как их избежать

Ошибка 1. CVSS как единственный сигнал

Описана выше подробно. Если ваша команда открывает Jira и сортирует задачи по CVSS-баллу — вы системно движетесь в неправильном направлении. CVSS остаётся полезным как входной параметр, но не как финальное решение.

Ошибка 2. Игнорирование старых CVE

По данным 2025 года, 81% эксплуатируемых уязвимостей были раскрыты до того же года [2]. Фокус только на свежих CVE оставляет огромную поверхность атаки. Проверяйте KEV систематически — в том числе для CVE старше года.

Ошибка 3. Отсутствие карты активов

Без актуальной карты активов невозможно правильно сопоставить уязвимость с реальным риском. Инвентаризация активов — не разовый проект, а непрерывный процесс.

Ошибка 4. Патчить одно, пропускать другое

Breacher в 2019 году против Capital One произошёл не через самую высокорейтинговую CVE, а через цепочку: неправильно сконфигурированный WAF + SSRF + избыточные IAM-права [16]. Приоритизация цепочек атаки (attack path analysis) — важная компетенция, которую сложно полностью автоматизировать.

Ошибка 5. Игнорировать то, что сканер не видит

Уязвимости без CVE-идентификаторов (мисконфигурации, избыточные привилегии, hardcoded secrets, небезопасные дефолтные настройки) не попадают в CVSS/EPSS-пайплайн, но активно используются атакующими. Это дополнительный слой риска, требующий отдельного подхода.

Ошибка 6. Доверять только NVD

В условиях бэклога NVD полагаться на него как на единственный источник данных — значит работать с неполной информацией. Диверсифицируйте источники: CVE.org, CISA KEV напрямую, vendor advisories, OSV.dev, Exploit-DB, VulnCheck [17].

Часть 7. AI-кодинг и приоритизация уязвимостей: новый контекст

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

Это создаёт специфическую проблему для vulnerability management: классический сканер смотрит на статичный репозиторий. Но в реальности риск часто возникает именно в момент изменения — когда в lock-файл добавляется транзитивная зависимость с известной уязвимостью, или когда в конфиг попадает небезопасный дефолт.

Инструменты, которые умеют анализировать конкретное изменение в контексте релиза — не весь репозиторий целиком, а именно diff и связанный контекст — дают команде ответ на вопрос "безопасно ли принять этот PR прямо сейчас". Это другой операционный угол, чем традиционный vulnerability scan, и он хорошо дополняет его, а не заменяет.

HighVibe работает именно в этой точке: анализирует изменения кода, конфигурации, зависимостей и служебных файлов до merge и релиза. Инструмент не заменяет SAST/SCA/SBOM-пайплайн — он добавляет слой контроля на уровне pull request, когда ещё можно остановить проблему до продакшна.

Часть 8. Тренды, которые изменят подход к приоритизации в ближайшие годы

AI ускоряет эксплуатацию

В 2024 году исследователи из University of Illinois показали, что GPT-4 способен автономно эксплуатировать 87% one-day уязвимостей при наличии CVE-описания — стоимостью около $8.80 за эксплойт [5]. AI снижает барьер входа для атакующих и дополнительно сжимает временной разрыв между раскрытием и эксплуатацией.

LEV: новая метрика NIST

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

Control-validated prioritization

Следующий шаг после EPSS+KEV+asset criticality — валидация через реальные контроли. Работает ли правило SIEM? Поймает ли EDR этот вектор? Блокирует ли WAF нужный паттерн? Только те уязвимости, которые прошли сквозь существующие контроли, действительно эксплуатируемы в данной среде. По данным Blue Report 2025, только 14% adversarial activity генерирует реальный алерт [7].

Сокращение KEV-окна

По информации от мая 2026 года, CISA рассматривает сокращение стандартного окна ремедиации KEV с двух недель до трёх дней — в ответ на AI-ускорение эксплуатации [4]. Это повысит планку требований к операционной скорости команд.

Заключение: что делать уже сейчас

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

1. Признать, что CVSS — один из входных параметров, а не ответ. Перестать строить SLA напрямую на CVSS-баллах.

1. Подписаться на CISA KEV как на обязательный сигнал. KEV = факт активной эксплуатации = наивысший приоритет при наличии на критичном активе.

1. Добавить EPSS в pipeline. Уязвимость с EPSS > 0.7 требует такого же внимания, как высокий CVSS. Уязвимость с EPSS < 0.01 и отсутствием в KEV может ждать планового цикла.

1. Классифицировать активы. Без карты активов с тегами критичности нет правильной приоритизации. Это фундамент.

1. Внедрить SSVC или аналогичное дерево решений. Цель — получать на выходе не цифру, а действие: Act, Attend, Track, Ignore.

1. Диверсифицировать источники данных. NVD не успевает. Подключите CVE.org, CISA KEV, vendor advisories, OSV.dev напрямую.

1. Контролировать изменения до продакшна. Уязвимость в зависимости, обнаруженная после релиза, стоит дороже, чем остановленная на уровне PR.

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

Источники

[1] NIST — "NVD Updates Operations to Address Record CVE Growth" — https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

[2] Zafran — "The 2025 Spike in Vulnerabilities Isn't the Full Story" — https://www.zafran.io/resources/the-2025-spike-in-vulnerabilities-isnt-the-full-story

[3] Help Net Security — "Attackers are handing off access in 22 seconds, Mandiant finds" — https://www.helpnetsecurity.com/2026/03/24/mandiant-m-trends-2026-report/

[4] Security Boulevard — "Mean Time to Exploit Has Gone Negative. Security Strategy Has to Change." — https://securityboulevard.com/2026/05/mean-time-to-exploit-has-gone-negative-security-strategy-has-to-change/

[5] CybelAngel — "Why Time to Exploit Is Collapsing" — https://cybelangel.com/blog/why-time-to-exploit-is-collapsing/

[6] NIST NVD — "Vulnerability Metrics (CVSS)" — https://nvd.nist.gov/vuln-metrics/cvss

[7] Picus Security — "Vulnerability Prioritization in 2026: Why CVSS Isn't Enough" — https://www.picussecurity.com/resource/blog/vulnerability-prioritization-why-cvss-isnt-enough

[8] Maze — "The Hidden Problem With CVSS: The Same CVE Gets Different Scores" — https://mazehq.com/blog/hidden-problem-with-cvss

[9] Malwarebytes — "How CVSS v4.0 works: characterizing and scoring vulnerabilities" — https://www.malwarebytes.com/blog/news/2025/11/how-cvss-v4-0-works-characterizing-and-scoring-vulnerabilities

[10] Picus Security — "Comparing CVSS, EPSS, KEV, SSVC, LEV, and PXS" — https://www.picussecurity.com/resource/blog/comparing-cvss-epss-kev-ssvc-lev-and-pxs-from-scores-to-security-proof

[11] Fencer.dev — "What is KEV? CISA's Known Exploited Vulnerabilities catalog explained" — https://www.fencer.dev/cyber-101/kev-known-exploited-vulnerabilities

[12] Kiuwan — "Risk-Based Vulnerability Management: Complete Guide for AppSec Teams" — https://www.kiuwan.com/blog/risk-based-vulnerability-management/

[13] CISA — "Stakeholder-Specific Vulnerability Categorization (SSVC)" — https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc

[14] FOSSA — "Actioning the Stakeholder-Specific Vulnerability Categorization (SSVC) Model" — https://fossa.com/blog/actioning-stakeholder-specific-vulnerability-categorization-ssvc-model/

[15] SecPortal — "SSVC: Stakeholder-Specific Vulnerability Categorization" — https://secportal.io/blog/ssvc-stakeholder-specific-vulnerability-categorization

[16] Wiz — "Vulnerability Prioritization Best Practices for 2026" — https://www.wiz.io/academy/vulnerability-management/vulnerability-prioritization

[17] Socket.dev — "NVD Backlog Crisis Deepens Amid Surging CVE Disclosures" — https://socket.dev/blog/nvd-backlog-crisis-deepens-amid-surging-cve-disclosures