Как понять, какую уязвимость исправлять первой: практическое руководство по приоритизации

От очередей по CVSS к риск-ориентированному подходу — для команд, которые хотят закрывать реальные угрозы, а не гнаться за цифрами

Введение: почему нельзя просто патчить «по убыванию CVSS»

Представьте: утром сканер выдал 3 000 уязвимостей. Из них 400 отмечены как «Critical» с CVSS ≥ 9.0. У команды безопасности — два инженера и спринт с двумя другими приоритетами. Что делать?

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

По данным исследования VulnCheck, в 2024 году из более чем 40 000 опубликованных CVE подтверждённо эксплуатировались лишь 768 — то есть около 1% [1]. В 2025 году количество CVE выросло до 48 185, но пропорция эксплуатируемых осталась сопоставимой [2]. Иными словами, 99% уязвимостей в вашей очереди — теоретические угрозы. Вопрос только в том, как найти тот 1%, который действительно горит.

Эта статья — практическое руководство для CTO, Tech Lead и AppSec-инженеров: как выстроить логику приоритизации, какие инструменты использовать и где чаще всего ошибаются даже зрелые команды.

Часть 1. Почему CVSS не работает как инструмент приоритизации

CVSS (Common Vulnerability Scoring System) — стандарт, который большинство команд знает с первых лет работы в ИБ. Он измеряет тяжесть уязвимости по трём группам метрик: базовой (техническая природа), временной (наличие патча и эксплойта) и контекстной (специфика среды).

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

Конкретные следствия:

1. CVSS не учитывает факт активной эксплуатации. Уязвимость с оценкой 6.5, которую прямо сейчас использует APT-группа, формально выглядит менее приоритетной, чем CVE с 9.8, требующая физического доступа к изолированному серверу в закрытом сегменте сети.

1. CVSS создаёт очереди, в которых нельзя расставить реальные приоритеты. Когда у вас 400 «Critical» CVE, ранжирование внутри этой группы всё равно не работает: нужны дополнительные данные.

1. CVSS не отражает контекст вашей среды. Одна и та же уязвимость в публично доступном API и во внутреннем дашборде аналитики — принципиально разные риски.

Исследование Qualys зафиксировало, что 53% всех CVE в 2024 году получили оценки High или Critical [3]. Если высокий приоритет у более чем половины всего потока — это не приоритизация, это отсутствие приоритизации.

Проблема стала настолько очевидной, что даже CVSS 4.0, финализированный в конце 2023 года, добавил метрику «Exploit Maturity» и разделил оценку воздействия на затронутую систему и последующие системы [1]. Это шаг вперёд, но фундаментальный изъян остаётся: CVSS — это показатель тяжести, не риска.

Часть 2. Четыре сигнала, которые действительно нужны

Современный риск-ориентированный подход к приоритизации строится на связке из нескольких взаимодополняющих сигналов. Ни один из них по отдельности не даёт полной картины.

2.1. EPSS: вероятность эксплуатации

Exploit Prediction Scoring System (EPSS) — модель машинного обучения, разработанная FIRST, которая ежедневно рассчитывает вероятность того, что CVE будет проэксплуатирована в течение следующих 30 дней [4]. В отличие от CVSS, EPSS опирается на реальные данные об угрозах: информацию об эксплойтах, сведения из threat intelligence, активность в сети.

Ключевой практический вывод: CVE с CVSS 7.0 и EPSS 90% опаснее для вас сейчас, чем CVE с CVSS 9.8 и EPSS 0.04%. Это не теория — реальный пример: CVE-2024-0646 в ядре Linux получил CVSS 7.0, но EPSS оставался крайне низким, поскольку эксплуатация требует локального доступа и специфичных условий [4]. Напротив, CVE-2024-4577 (критическая уязвимость PHP) получил EPSS ~94% ещё до того, как NVD опубликовал полный анализ и выставил CVSS-оценку.

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

Ограничение EPSS: он предсказывает вероятность эксплуатации «в дикой природе» в целом, но не учитывает, достижима ли уязвимость в вашей конкретной среде.

2.2. CISA KEV: подтверждённая эксплуатация

CISA Known Exploited Vulnerabilities (KEV) Catalog — это живой список уязвимостей, для которых есть подтверждённые свидетельства активной эксплуатации в реальных атаках [6]. Сегодня в каталоге тысячи записей, и он регулярно пополняется.

Логика проста: если уязвимость попала в KEV — атакующие уже её используют. Это самый сильный сигнал для немедленного действия, независимо от того, какую оценку выставил CVSS.

CISA рекомендует всем организациям (не только федеральным структурам США) использовать KEV как входной сигнал в процессе приоритизации [6]. Для организаций в России и СНГ KEV остаётся ценным ориентиром по глобальным угрозам — большинство уязвимостей в нём касаются широко распространённого ПО: Cisco, Microsoft, Fortinet, VMware, Apache.

Ограничение KEV: каталог реактивен по природе. Он фиксирует уже подтверждённую эксплуатацию и не предсказывает, что станет следующей целью. Кроме того, попасть в KEV — не единственный способ быть опасным.

2.3. Критичность актива: контекст вашей среды

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

Критичность актива — это вес уязвимости в вашей конкретной инфраструктуре. Факторы оценки:

• Является ли сервис внешне доступным? Публично доступные активы представляют наикратчайший путь от атакующего к данным [7].
• Насколько важен этот компонент для бизнес-процессов? Производственные системы, системы авторизации, компоненты, обрабатывающие чувствительные данные — первый эшелон.
• Какие компенсирующие контроли уже стоят? WAF, EDR, сегментация сети могут снижать реальную эксплуатируемость даже высокоопасной CVE.
• Есть ли lateral movement potential? Уязвимость на внутреннем сервисе может быть менее очевидной, но если от него тянутся пути к «коронным активам» — это повышает приоритет.

По данным Tenable, риск-ориентированный подход, учитывающий критичность активов, позволяет сократить фактическую очередь на устранение примерно на 97% — оставляя в фокусе те 3% уязвимостей, которые несут наибольший реальный риск [8].

2.4. SSVC: логика решений

SSVC (Stakeholder-Specific Vulnerability Categorization) — методология принятия решений, разработанная Carnegie Mellon SEI совместно с CISA [9]. В отличие от CVSS, EPSS и KEV, SSVC не выдаёт числовую оценку — он даёт действие.

SSVC проводит через дерево решений с несколькими узлами: статус эксплуатации, доступность эксплойта, техническое воздействие, влияние на миссию организации. На выходе — одно из четырёх значений:

1. Track — отслеживайте, действие не требуется прямо сейчас.
2. Track* — повышенное внимание, могут потребоваться изменения.
3. Attend — ускоренное устранение, раньше стандартного цикла патчей.
4. Act — немедленное скоординированное действие.

CISA использует собственную версию SSVC как основной фреймворк для оценки уязвимостей и публичных рекомендаций [9]. Для внутренних команд SSVC особенно ценен тем, что переводит технические данные в конкретные операционные решения — именно то, что нужно Tech Lead или AppSec-инженеру на утреннем стэндапе.

Часть 3. Российский регуляторный контекст: ФСТЭК и БДУ

Для компаний, работающих под российским регулированием, тема приоритизации имеет дополнительное измерение. ФСТЭК России опубликовал «Методику оценки уровня критичности уязвимостей программных и программно-аппаратных средств», утверждённую 30 июня 2025 года [10]. В конце 2025 года была также утверждена «Методика анализа защищённости информационных систем», которая формализует порядок выявления и оценки уязвимостей и устанавливает, что оценка значимости проводится в соответствии с методикой критичности [11].

Согласно руководству ФСТЭК, основным источником данных является Банк данных угроз безопасности информации (БДУ ФСТЭК, bdu.fstec.ru). При этом методика не запрещает использование сторонних баз данных — NVD, CISA KEV — как дополнительных источников [10].

Практически важный контекст: по данным аналитиков, в 2025 году ФСТЭК зафиксировал более 25 000 новых записей в БДУ, а средний MTTR (Mean Time to Remediate) в российских компаниях превышал 60 дней — в три раза больше рекомендуемого порога [12]. Это означает, что системная проблема с приоритизацией существует не только в теории.

Часть 4. Практический фреймворк: как расставить приоритеты за 5 шагов

Шаг 1. Фильтр подтверждённой эксплуатации

Первый вопрос к любой CVE: она есть в CISA KEV или в аналогичном списке активно эксплуатируемых уязвимостей? Если да — это немедленный Tier 1 независимо от CVSS. Устраняем по SLA 24–72 часа для внешних активов.

Не пренебрегайте этим шагом даже для «скучных» уязвимостей с невысоким CVSS: в Q1 2025 года 28% реально эксплуатируемых CVE имели оценку «Medium» [1].

Шаг 2. Фильтр высокой вероятности эксплуатации (EPSS)

Для оставшихся CVE смотрим на EPSS. Порог зависит от ресурсов команды, но практика показывает: уязвимости с EPSS выше 70–80-го перцентиля заслуживают повышенного внимания. Комбинация EPSS > 50% и CVSS ≥ 7.0 — сильный сигнал для Tier 2 с SLA около 7 дней.

Помните: EPSS — вероятность эксплуатации в следующие 30 дней на глобальном уровне. Это не гарантия, но значимый количественный сигнал.

Шаг 3. Контекст актива: достижимость и критичность

После первых двух фильтров оцениваем каждую CVE в контексте вашей среды:

• Реально ли уязвимый компонент достижим снаружи или внутри из недоверенных сегментов?
• Насколько критичен этот сервис для бизнеса?
• Какие компенсирующие контроли уже действуют?

Уязвимость на изолированном dev-сервере без выхода наружу и с ограниченным blast radius может оставаться в Tier 3, даже если CVSS у неё высокий.

Шаг 4. Применение логики SSVC

Для уязвимостей, которые прошли через первые три шага и требуют чёткого операционного решения, используйте дерево решений SSVC. CISA предоставляет онлайн-калькулятор (cisa.gov/ssvc-calculator), который позволяет пройти через дерево за несколько минут [9].

Результат — не оценка, а конкретное действие: Act, Attend, Track*, Track. Это именно тот формат, который нужен, чтобы поставить задачу в трекер с обоснованием.

Шаг 5. SLA и операционный трекинг

Без формальных SLA приоритизация — это просто пожелания. Стандартная практика:

• Tier 1 (KEV + внешний актив): 24–72 часа.
• Tier 2 (высокий EPSS + CVSS ≥ 7.0): 7 дней.
• Tier 3 (высокий CVSS без подтверждённой эксплуатации): 30 дней.
• Tier 4 (остальное): в рамках стандартного цикла патчей.

В 2024 году количество эксплуатируемых уязвимостей с доступным патчем, которые не были закрыты в течение 30 дней, выросло на 61% год к году [13]. SLA — это не бюрократия, это инструмент, который переводит «починим когда-нибудь» в «должно быть закрыто до вторника».

Часть 5. Типичные ошибки и как их избежать

Ошибка 1: «Мы патчим всё Critical»

Если в вашей организации 400 Critical-уязвимостей и команда патчит их по убыванию CVSS — вы, вероятно, месяцами исправляете уязвимости, которые никогда не будут атакованы, и при этом пропускаете Medium-CVE с EPSS 90%.

Решение: добавить к CVSS хотя бы один дополнительный сигнал — EPSS или KEV — до формирования очереди.

Ошибка 2: Игнорирование зависимостей и транзитивных компонентов

Уязвимость может прийти не в вашем коде, а в библиотеке, которую использует ваша зависимость. Анализ reachability — достижим ли уязвимый код в рантайме — критически важен для правильной оценки риска.

Команды, которые активно используют AI-кодинг и получают быстрые PR с новыми зависимостями, особенно подвержены этому риску: новая или транзитивная зависимость приезжает незаметно, а её безопасность никто не проверял. Инструменты вроде HighVibe работают именно на этом уровне — анализируя конкретное изменение в PR, его зависимости и контекст релиза, чтобы флагнуть риск до merge, а не после [подробнее на highvibe.dev].

Ошибка 3: Отсутствие инвентаризации активов

Невозможно правильно оценить критичность уязвимости, не зная, на каком активе она находится. Без актуального инвентаря с метками «внешний/внутренний», «production/dev», «обрабатывает PII/не обрабатывает» — любая приоритизация остаётся угадыванием.

Ошибка 4: «Длинный отчёт = безопасность»

Классический симптом незрелого процесса: сканер сгенерировал отчёт на 500 страниц, он ушёл в почту — и на этом работа считается выполненной. Сканирование — это обнаружение, а не устранение. Пропасть между обнаружением и реальным патчем в 2025 году составляет в среднем около 252 дней [2]. Разрыв в 132 дня между средним временем появления эксплойта (5 дней) и средним временем устранения критической уязвимости (~137 дней) — именно там происходят инциденты [14].

Ошибка 5: Разрозненные процессы ИБ и разработки

Приоритизация, которую сделала команда безопасности, но которую разработчики видят через 2 недели в виде тикета без контекста — это неработающий процесс. Чем ближе сигнал о риске к точке принятия решения (PR, релиз), тем меньше friction и тем быстрее реакция.

Часть 6. Особые случаи: zero-day, supply chain и AI-код

Zero-day уязвимости

Zero-day — ситуация, когда патча нет. EPSS и CVSS здесь вторичны: нет патча — нет и традиционного пути устранения. Тактика смещается на компенсирующие контроли: изоляция, ограничение доступа, мониторинг аномалий, временные workarounds от вендора. Следите за CISA KEV и vendor advisories — они появятся раньше, чем NVD успеет обновить запись [5].

В 2025 году Google GTIG отследил 90 zero-day, эксплуатировавшихся в дикой природе, из которых 48% были направлены против корпоративной инфраструктуры — рекордный показатель [2].

Supply chain: зависимости и транзитивные риски

Уязвимости в компонентах с открытым исходным кодом заслуживают отдельной логики приоритизации, поскольку один уязвимый пакет может затрагивать сотни приложений в портфеле компании. Факторы: используется ли уязвимая функция реально? Достижим ли путь к уязвимому коду из точки входа? Есть ли lockfile, который фиксирует версию?

По данным Veracode, 70% критического security debt в современных приложениях происходит из кода сторонних компонентов [2].

Код, написанный с AI-ассистентом

AI-ассистенты ускоряют разработку, но создают специфический контекст для управления уязвимостями. AI может предложить устаревшую версию зависимости, шаблонный код с известными паттернами уязвимостей, или конфигурацию с избыточными правами. При этом PR с AI-кодом нередко проходит ревью быстрее, чем без него: «выглядит правильно» — и идёт в main. Это создаёт слепую зону именно на уровне merge и релиза.

Часть 7. Как выглядит зрелый процесс

Зрелый vulnerability management — не инструмент, а процесс. Несколько признаков:

• Есть актуальный инвентарь активов с метками критичности и экспозиции.
• Каждая CVE оценивается по нескольким сигналам: CVSS + EPSS + KEV + контекст актива.
• Есть формальные SLA по тирам и метрика MTTR (Mean Time to Remediate).
• Команды ИБ и разработки работают с одним трекером и одной очерёдностью — без разрыва «безопасники нашли, девы не видели».
• Перед релизом есть явный gate: «что блокирует выпуск» — не длинный отчёт, а короткий список с обоснованием.
• Процесс регулярно пересматривается: EPSS и статус эксплуатации меняются, и уязвимость, которая была Track* две недели назад, может стать Act сегодня.

В российском контексте дополнительный ориентир — методология ФСТЭК и обязательное использование БДУ как источника данных для организаций, работающих с ГИС и ЗОКИИ [10][11].

Заключение: от списка к решению

Vulnerability management в 2026 году — это не про «залатать побольше», а про «принять правильное решение быстро».

Ключевые операционные выводы:

1. CVSS — отправная точка, не финальный вердикт. Всегда добавляйте хотя бы EPSS и KEV перед формированием очереди.
2. Самый сильный сигнал — подтверждённая активная эксплуатация. Если CVE в CISA KEV — это Tier 1, независимо от цифры CVSS.
3. Контекст среды умножает или снижает риск. Одна уязвимость на внешнем API и на изолированном dev-сервере — разные задачи с разными дедлайнами.
4. SSVC переводит оценку в действие. Track, Attend, Act — это операционный язык, который работает в трекере.
5. Скорость окна сжалась. Медианное время до появления эксплойта — около 5 дней. Цикл «нашли → оценили → поставили задачу → закрыли» должен быть быстрее среднего MTTR.

Если ваша команда ускорила разработку с помощью AI-инструментов, но контроль изменений не вырос с той же скоростью — именно здесь возникает разрыв между «работает» и «безопасно для production». Инструменты вроде HighVibe закрывают этот разрыв, анализируя конкретные изменения и зависимости на уровне PR и давая команде короткий понятный сигнал: можно ли безопасно принять это изменение сейчас. Подробнее — на highvibe.dev.

Источники

[1] VulnCheck / The Hacker News — "768 CVEs Exploited in 2024, Reflecting a 20% Increase from 639 in 2023" — https://thehackernews.com/2025/02/768-cves-exploited-in-2024-reflecting.html

[2] AppSec Santa — "Software Vulnerability Statistics 2026: 60+ Key Facts & Data" — https://appsecsanta.com/research/software-vulnerability-statistics

[3] Infosecurity Magazine — "CVEs Surge 30% in 2024, Only 0.91% Weaponized" — https://www.infosecurity-magazine.com/news/cves-surge-30-2024/

[4] Cloudsmith — "CVSS vs EPSS: Smarter Vulnerability Risk Prioritization" — https://cloudsmith.com/blog/vulnerability-scoring-systems

[5] Zafran — "Prioritizing Vulnerabilities: Best Practices for Risk-Based Patching" — https://www.zafran.io/ctem-academy/prioritizing-vulnerabilities-risk-based-patching

[6] CISA — "Known Exploited Vulnerabilities Catalog" — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

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

[8] Tenable — "Risk-Based Vulnerability Management Principles" — https://www.tenable.com/principles/risk-based-vulnerability-management-principles

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

[10] Гарант / ФСТЭК — "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств (утв. ФСТЭК 30 июня 2025 г.)" — https://www.garant.ru/products/ipo/prime/doc/412283948/

[11] iTPROTECT — "Утверждена новая методика ФСТЭК России для анализа защищённости" — https://itprotect.ru/mediacenter/news/novaya-metodika-fstek/

[12] SGRC CyberOsnova — "Процесс управления уязвимостями: этапы, методика ФСТЭК и автоматизация" — https://sgrc.cyberosnova.ru/blog/process-upravleniya-uyazvimostyami/

[13] Secure.com — "How to Set Effective Vulnerability Remediation SLAs by Severity and Business Impact" — https://www.secure.com/blog/infrastructure-security/vulnerability-remediation-slas

[14] Hexnode — "Patch Management vs Vulnerability: Bridging the Remediation Gap" — https://www.hexnode.com/blogs/the-remediation-gap-why-patch-management-and-vulnerability-management-are-not-synonyms/

[15] Expert Insights — "Vulnerability Prioritization: Why CVSS Scores Alone Aren't Enough" — https://expertinsights.com/endpoint-management/vulnerability-prioritization-why-cvss-scores-alone-arent-enough

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