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

Почему оценка «10 из 10» не означает «патчить прямо сейчас»

Когда «критическое» не значит «срочное»

Представьте сценарий, хорошо знакомый любому специалисту по ИБ: сканер вернул 3 000 уязвимостей после очередного сканирования инфраструктуры. 480 из них — «Critical» и «High» по CVSS. Команда из пяти человек смотрит на этот список и понимает, что при таком темпе устранения очередь рассосётся не раньше, чем придёт следующий отчёт сканера.

Такая ситуация — не исключение. Это новая норма. По данным FIRST, медианное количество CVE в 2026 году достигнет 59 427, а верхняя граница прогноза — 193 000 к 2028 году [1]. При этом, по данным Bitsight, медианное время устранения критической уязвимости в среднем по рынку составляет 4,5 месяца, а более 60% уязвимостей из каталога CISA KEV закрываются после истечения дедлайна, установленного регулятором [5].

Корень проблемы — в том, что индустрия десятилетиями использовала CVSS не по назначению. CVSS создавался как стандартный язык описания серьёзности уязвимости, а не как инструмент управления очерёдностью патчинга [2]. Это различие — между severity и risk — принципиально. И понимание этого различия сегодня определяет разницу между командой, которая тушит пожары по приоритетам злоумышленника, и командой, которая управляет реальным риском организации.

Эта статья — для тех, кто хочет перейти от первого подхода ко второму: инженеров по ИБ, специалистов по vulnerability management, руководителей ИБ и всех, кто принимает решения о том, что патчить сначала.

Часть 1. Что такое CVSS и почему его недостаточно

Как работает CVSS

Common Vulnerability Scoring System (CVSS) — открытый стандарт, разработанный и поддерживаемый организацией FIRST (Forum of Incident Response and Security Teams). Его задача — дать стандартизированную числовую оценку серьёзности уязвимости по шкале от 0 до 10 [2].

Актуальная версия — CVSS 4.0, финализированная в конце 2024 года, — включает четыре группы метрик:

1. Base Metrics — базовые характеристики уязвимости: вектор атаки (сеть, смежная сеть, локальный доступ, физический доступ), сложность атаки, необходимые привилегии, участие пользователя, влияние на конфиденциальность, целостность и доступность.
2. Threat Metrics — новая в CVSS 4.0 группа, заменившая Temporal; включает метрику «Exploit Maturity» — зрелость эксплойта.
3. Environmental Metrics — адаптация оценки под конкретную среду организации: можно понизить оценку, если уязвимый актив изолирован, или повысить, если он критически важен.
4. Supplemental Metrics — дополнительный контекст без влияния на итоговый балл.

Добавление Threat Metrics в CVSS 4.0 — шаг в правильном направлении. Однако даже обновлённый стандарт прямо оговаривает: «CVSS — это измеритель серьёзности, а не рисков» [2]. Эта оговорка критически важна.

Структурные ограничения CVSS

Проблема не в том, что CVSS плохо сделан. Проблема в том, как его применяют, и в нескольких структурных особенностях:

Первое — статичность базовой оценки. CVSS Base Score присваивается при первичном анализе уязвимости — и, как правило, не пересматривается. По данным Tenable, базовая оценка обычно назначается в течение двух недель после обнаружения уязвимости и почти никогда не обновляется впоследствии [6]. Между тем угрозы меняются: публикуется PoC-код, уязвимость попадает в руансомвер-группировки, появляются массовые атаки. Базовая оценка 5.0 образца 2022 года может означать реальный риск уровня 9.0 в 2024-м — но CVSS об этом промолчит.

Второе — инфляция «критичности». По данным Tenable Research, 56% всех уязвимостей получают оценку «High» (7.0–8.9) или «Critical» (9.0–10.0) — вне зависимости от реальных шансов эксплуатации [6]. По другим оценкам, 32,7% всех CVE попадают в категорию Critical или High [3]. Когда треть всех уязвимостей объявляется «критической», понятие критичности теряет операционный смысл.

Третье — отсутствие контекста среды. CVSS оценивает уязвимость в вакууме. Уязвимость с вектором атаки «Network» получает максимальный балл за доступность — независимо от того, является ли система интернет-доступной или изолирована за несколькими слоями сегментации. Уязвимость на DMZ-сервере с публичными данными клиентов и та же уязвимость на тестовом стенде без сетевой связности получат одинаковый CVSS Base Score.

Четвёртое — субъективность при расчёте. Исследование 196 опытных пользователей CVSS, опубликованное на IEEE Symposium on Security and Privacy в 2024 году, показало значимые расхождения в оценках одних и тех же уязвимостей разными аналитиками [7]. Когда NVD и вендор присваивают разные оценки одному CVE — а по некоторым данным, расхождения встречаются почти у 20% записей, — это создаёт дополнительную путаницу при принятии решений [8].

Пятое — игнорирование вероятности эксплуатации. Ключевой вопрос для приоритизации звучит не «насколько серьёзна уязвимость теоретически?», а «насколько вероятно, что её будут эксплуатировать именно сейчас?». CVSS на этот вопрос не отвечает.

Реальные последствия CVSS-центричного подхода

Показательный пример — CVE-2022-30190, уязвимость «Follina» в Microsoft MSDT. Microsoft присвоила ей CVSS 7.8 и квалификацию «Important» вместо «Critical». Организации, закрывавшие только критические уязвимости, пропустили её — несмотря на то, что уязвимость активно использовалась для распространения вымогательского ПО Bisamware на протяжении нескольких месяцев [8]. Оценка по CVSS так и осталась 7.8 — даже когда стало известно об активной эксплуатации.

По данным опроса AM Live 2025 года, в российских компаниях картина схожа: 51% специалистов называют главным критерием приоритизации «критическую значимость актива», 17% — «наличие эксплойта», и только 17% используют методологию ФСТЭК как основной критерий [9]. Это означает, что часть индустрии уже движется в сторону риск-ориентированного подхода — но значительная доля организаций по-прежнему полагается на оценки сканеров и CVSS.

Часть 2. Три оси реального риска

Зрелый подход к приоритизации уязвимостей строится на трёх независимых, но взаимодополняющих измерениях.

Ось 1. Вероятность эксплуатации (EPSS)

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

EPSS версии 4, выпущенной 17 марта 2025 года, анализирует более 1 100 переменных, включая данные о вендоре и популярности продукта, дату публикации CVE, наличие публичного PoC-кода на GitHub, Exploit-DB или Metasploit, присутствие уязвимости в базах угроз (CISA KEV, Google Project Zero, Trend Micro ZDI), упоминания в блогах и форумах по безопасности, а также телеметрию endpoint-систем и данные об активных атаках [11]. Модель обновляется ежедневно.

EPSS v4 демонстрирует радикально более эффективную фокусировку ресурсов по сравнению с CVSS. Чтобы закрыть 74,6% уязвимостей, которые реально будут эксплуатироваться, при стратегии «патчить всё с CVSS ≥ 7» нужно отработать 50% всех известных CVE. При использовании EPSS v4 с порогом 10% тот же уровень охвата достигается при патчинге всего 6% уязвимостей [12].

Практический пример из реальных данных: CVE-2024-4577 (критическая уязвимость PHP для выполнения произвольного кода) получила EPSS около 94% ещё до того, как NVD опубликовал полный анализ и базовую CVSS-оценку. Команды, ориентировавшиеся исключительно на NVD-фид, были слепы к одной из наиболее активно эксплуатируемых угроз того периода [13].

Обратный пример: CVE-2024-0646 в ядре Linux получила CVSS 7.0 (High), однако EPSS-оценка составила 0,04%. Требуется локальный доступ и специализированные условия — злоумышленники не видят в этой уязвимости привлекательной цели для массовых атак [13].

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

Ось 2. Подтверждённая эксплуатация (CISA KEV)

Known Exploited Vulnerabilities (KEV) — каталог CISA, содержащий уязвимости, для которых есть достоверные доказательства реальной эксплуатации [14]. Это не прогноз, а констатация факта: уязвимость уже используется злоумышленниками.

По данным на конец 2025 года, каталог содержал 1 484 записи [15]. В 2025 году CISA добавила 245 уязвимостей — рост на 30% по сравнению со стабильным темпом 185–187 уязвимостей в год в 2023–2024 годах [15]. Из них 24 уязвимости подтверждены как инструменты атак группировок-вымогателей.

Данные о сроках эксплуатации тревожны: в 2025 году 28,96% KEV-уязвимостей начинали эксплуатироваться в день публикации или раньше — рост с 23,6% в 2024 году [4]. Это означает, что для значительной доли уязвимостей в каталоге KEV само понятие «окна патчинга» утрачивает смысл: атаки начинаются до того, как большинство организаций успевает установить патч.

Присутствие в KEV-каталоге радикально меняет поведение: KEV-уязвимости закрываются в 3,5 раза быстрее остальных [4]. При этом даже критические KEV-уязвимости в среднем закрываются за 174 дня (медиана), тогда как для уязвимостей вне каталога этот показатель превышает 1,7 года [5].

Помимо CISA KEV, существуют альтернативные каталоги, охватывающие более широкий спектр источников. VulnCheck KEV в 2024 году добавил 717 новых известных эксплуатируемых уязвимостей против 170 у CISA KEV [16] — разница почти в 4 раза. Это говорит о том, что CISA KEV — полезный, но не исчерпывающий инструмент.

Ось 3. Критичность актива и экспозиция

Третья ось — контекст конкретной среды организации. Это то, что CVSS Environmental Metrics описывают концептуально, но на практике редко вычисляется вручную.

Ключевые факторы этой оси:

Интернет-экспозиция — является ли актив доступным из интернета? Интернет-доступные системы сканируются автоматизированными инструментами (Shodan, Censys) в течение минут после появления публичного эксплойта. Именно поэтому уязвимости на периметре — VPN-шлюзах, файрволах, веб-серверах — требуют особого внимания даже при относительно низком CVSS [4].

Бизнес-критичность — насколько важен актив для ключевых функций организации? Уязвимость CVSS 6.5 на системе процессинга платежей может быть критичнее уязвимости CVSS 9.0 на тестовом сервере с публичными данными.

Наличие компенсирующих мер — защищён ли актив WAF, IPS, сетевой сегментацией? Это де-факто аналог понижения вектора атаки в CVSS Environmental Score, но основанный на реальных данных об инфраструктуре.

Наличие публичного PoC-кода — это не то же самое, что EPSS, но тесно коррелирует с ним. В 2024 году 42% проанализированных уязвимостей имели публично доступный PoC-эксплойт [17]. Наличие PoC резко снижает барьер для атак: уязвимость, требовавшая квалифицированного атакующего, становится доступна любому скрипткидди.

Связанность актива — насколько широко уязвимый компонент представлен в инфраструктуре? Уязвимость в одном изолированном экземпляре — не то же самое, что уязвимость в библиотеке, используемой 500 сервисами.

Часть 3. SSVC: структурированное дерево решений для каждого контекста

Stakeholder-Specific Vulnerability Categorization (SSVC) — методология, разработанная Carnegie Mellon University SEI в сотрудничестве с CISA в 2019 году. Она предлагает альтернативный подход: вместо числового балла — структурированное дерево решений, результатом которого является рекомендуемое действие [18].

Дерево CISA SSVC включает четыре ключевых узла:

1. Exploitation (статус эксплуатации) — нет публичного PoC / есть PoC / активно эксплуатируется.
2. Automatable (автоматизируемость) — можно ли автоматизировать эксплуатацию на большом количестве целей? Если да — риск массовых атак резко возрастает.
3. Technical Impact (технический эффект) — Partial (ограниченный контроль) или Total (полный контроль над системой).
4. Mission Prevalence / Public Well-being Impact — насколько широко задействован уязвимый компонент в критических функциях организации и насколько его компрометация затронет общественный интерес?

На выходе — одно из четырёх решений: Track (отслеживать), Track* (отслеживать с повышенным вниманием), Attend (реагировать в плановом режиме), Act (немедленное действие).

Принципиальное отличие SSVC от CVSS — в том, что одна и та же уязвимость на разных активах может получить разные решения. Это именно то, что нужно: контекстуализация на уровне инфраструктуры, а не абстрактная глобальная оценка [18].

CISA официально рекомендует внедрение SSVC как инструмента modernизации управления уязвимостями. В 2024 году агентство выпустило проект Vulnrichment — обогащение CVE-записей SSVC-метаданными. VulnCheck развил эту инициативу, сгенерировав SSVC-решения для 244 866 CVE (против 64 142 у CISA Vulnrichment) [19].

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

Часть 4. Российская специфика: ФСТЭК и регуляторный контекст

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

Методология и база данных ФСТЭК

ФСТЭК России ведёт собственную Базу данных угроз (БДУ) — аналог NVD, адаптированный к отечественным реалиям. Для описания уязвимостей в отечественном ПО и оборудовании БДУ использует собственные идентификаторы BDU; для иностранного ПО применяются CVE-идентификаторы [20].

В мае 2023 года ФСТЭК утвердила «Руководство по организации процесса управления уязвимостями», ставшее обязательным для государственных информационных систем (ГИС) и субъектов КИИ. В 2025 году регулятор выпустил обновлённую Методику оценки уровня критичности уязвимостей (утверждена 30 июня 2025 года), а в ноябре 2025-го — Методику анализа защищённости информационных систем [21].

Ключевые регуляторные требования:

Уязвимости критического и высокого уровня подлежат обязательному устранению. По уязвимостям среднего и низкого уровня проводится экспертная оценка возможности эксплуатации с последующим решением: устранять или передавать в процесс управления уязвимостями [21].

Методика анализа защищённости формализует структуру отчётности: перечень выявленных уязвимостей с указанием критичности, рекомендации по устранению, результаты повторного анализа, итоговое заключение [21].

Отдельная точка внимания — сертифицированное ПО. По данным экспертов Positive Technologies, многие отечественные разработчики после получения сертификата ФСТЭК считают продукт «неуязвимым» и прекращают активное взаимодействие с сообществом безопасности [22]. Это создаёт ложное ощущение защищённости и задержку в публикации и устранении уязвимостей.

Практические примеры: по данным отраслевых экспертов, за нарушения в области управления уязвимостями ФСТЭК налагает предписания и штрафы — от 200 000 до 300 000 рублей и выше, с требованием устранения нарушений в течение 14–30 дней [20]. В условиях, когда IT-ландшафт организаций постоянно меняется, а ответственность за уязвимости растёт, отсутствие формализованного процесса — прямой регуляторный риск.

Российская практика приоритизации

По данным опроса AM Live 2025 года среди российских ИБ-специалистов:

1. 51% считают главным критерием приоритизации критическую значимость актива.
2. 17% ставят на первое место наличие эксплойта.
3. 17% ориентируются на методологию ФСТЭК.
4. 6% используют собственный скоринг уязвимостей.
5. 6% учитывают трендовость уязвимости в СМИ.
6. 3% полагаются на скоринг сканера [9].

Примечательно, что критичность актива заняла первое место — это соответствует современному пониманию risk-based vulnerability management. Вместе с тем доля специалистов, учитывающих наличие эксплойта как основной критерий, остаётся относительно низкой (17%) по сравнению с мировыми best practices.

Часть 5. Практический фреймворк: как построить приоритизацию по риску

Шаг 1. Инвентаризация активов как фундамент

Невозможно оценить риск, не зная, что защищать. Уязвимость на сервере с ПДн клиентов и та же уязвимость на тестовой виртуальной машине — принципиально разные ситуации.

Базовые требования к инвентаризации: реестр всех активов с актуальными версиями ПО, классификация по бизнес-критичности (хотя бы трёхуровневая: критичный/важный/некритичный), маркировка по интернет-экспозиции, данные о наличии компенсирующих мер.

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

Шаг 2. Применение составного скоринга

Современная best practice — составной балл, объединяющий несколько сигналов. Одна из прозрачных формул:

Приоритет = 0,4 × нормализованный CVSS + 0,4 × EPSS + 0,2 × KEV-флаг + мультипликатор критичности актива [23].

Логика весов: CVSS даёт наихудший сценарий технического ущерба, EPSS — вероятность реализации, KEV-флаг сигнализирует о подтверждённой активной эксплуатации. Мультипликатор критичности актива повышает итоговый приоритет для систем, компрометация которых несёт максимальный ущерб.

Практические пороги для SLA (уровни сервисного обязательства по патчингу):

• Tier 0 (активная эксплуатация + критичный актив): устранение в течение 24 часов или применение компенсирующих мер.
• Tier 1 (EPSS > 50% или KEV-флаг на важном активе): 72 часа.
• Tier 2 (EPSS 10–50%, критичный или важный актив): 7 дней.
• Tier 3 (CVSS High/Critical, EPSS < 10%, некритичный актив): плановый цикл патчинга (2–4 недели).
• Остальные: следующий плановый цикл или принятие риска с документацией.

Шаг 3. Фильтрация через KEV в первую очередь

Любая уязвимость, попавшая в CISA KEV, должна автоматически получать наивысший приоритет вне зависимости от CVSS-оценки. Средняя CVSS-оценка уязвимостей в KEV составляет 8,21 [24] — но встречаются и записи с CVSS в диапазоне «Medium». Игнорировать KEV ради CVSS-логики — значит повторять ошибку с Follina.

Для российских организаций, работающих с отечественным ПО, аналогом является актуальный раздел «Наиболее опасные уязвимости» в бюллетенях ФСТЭК.

Шаг 4. Учёт интернет-экспозиции

Одна из важнейших переменных — является ли уязвимый актив доступным из интернета. В 2025 году 48% нулевых дней были направлены против корпоративных технологий периметра: сетевого оборудования, VPN-шлюзов, прокси [4]. Edge-инфраструктура — это цели номер один, потому что компрометация даёт атакующему сетевой плацдарм, доступ к учётным данным и возможность длительного присутствия.

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

Шаг 5. Компенсирующие меры как временная альтернатива

В ряде случаев немедленный патчинг невозможен: зависимости от вендора, требования доступности, сертификационные ограничения (особенно актуально для систем с сертификатами ФСТЭК). В таких случаях необходимы компенсирующие меры:

• Сетевая сегментация и ограничение доступа к уязвимому сервису.
• Виртуальный патч (WAF, IPS) — если есть соответствующие сигнатуры.
• Усиленный мониторинг попыток эксплуатации через SIEM.
• Ограничение пользовательских привилегий.
• Отключение неиспользуемых учётных записей и функций.

Компенсирующие меры не отменяют необходимость патчинга, но позволяют управляемо снизить риск в период ожидания.

Шаг 6. Измерение и итерация

Ключевая метрика зрелости — Mean Time to Remediate (MTTR), медианное время от обнаружения до устранения, раздельно по уровням приоритета. Разумные цели по отраслевым стандартам: Critical — не более 15–30 дней, High — не более 30–60 дней [25]. Для Tier 0 в зрелых программах цель — 24–48 часов.

Другие полезные метрики: процент уязвимостей Tier 0, устранённых в рамках SLA; размер и динамика backlog; доля повторно открытых уязвимостей (показатель качества патчинга).

Часть 6. Типовые ошибки и как их избежать

Ошибка 1: «Патчить всё Critical»

Смотреть только на Critical/High по CVSS и игнорировать активно эксплуатируемые Medium-уязвимости. По данным за Q1 2025 года, 28% эксплуатируемых уязвимостей имели лишь «Medium» базовую оценку [23]. Подход «только Critical» гарантированно пропустит часть наиболее активно атакуемых уязвимостей.

Ошибка 2: Игнорирование контекста среды

Обрабатывать уязвимости без привязки к конкретным активам. Это ведёт к ситуации, когда команда тратит неделю на патчинг 1 000 малозначимых активов по «популярному» CVE, упуская при этом одну критически важную уязвимость на ключевой системе.

Ошибка 3: Одноразовые аудиты вместо непрерывного мониторинга

IT-ландшафт меняется постоянно: появляются новые сервисы, интеграции, поля в базах данных. Аудит один раз в квартал даёт лишь моментальный снимок. EPSS-оценки обновляются ежедневно; угрозы меняются стремительно. Эффективное управление уязвимостями — это непрерывный процесс, а не периодическая кампания.

Ошибка 4: Отсутствие ответственных владельцев

Уязвимость идентифицирована, но непонятно, кто её должен закрыть. Классический провал на стыке ИБ и ИТ: безопасники видят проблему, ИТ-команда не понимает, что от неё требуется. Решение — формализованные SLA с явным назначением владельца каждой уязвимости (по активу или по системе) и автоматическое создание тикетов.

Ошибка 5: Нет документации принятых рисков

Если уязвимость не закрыта — это не всегда халатность; иногда это осознанное решение принять риск. Но принятие риска без документации — это регуляторный и операционный провал. При проверке ФСТЭК или в ходе расследования инцидента отсутствие журналов принятых решений становится самостоятельной проблемой [20].

Ошибка 6: Доверие к «окончательному» CVSS-баллу

Различные источники — NVD, вендор, сканер — могут присваивать разные CVSS-оценки одному CVE. Использование нормализованного фида из единого доверенного источника и понимание природы расхождений — обязательный элемент зрелой программы.

Часть 7. Кейсы и реальные примеры

Кейс 1: CVE-2024-4577 (PHP)

Критическая уязвимость удалённого выполнения кода в PHP. EPSS достиг ~94% ещё до того, как NVD завершил полный анализ. Команды, использующие исключительно NVD-фид и CVSS, оставались «слепы» к угрозе в течение нескольких дней — при том что эксплуатация шла полным ходом. Организации, отслеживавшие EPSS и vendor advisories, могли реагировать на несколько дней раньше [13].

Кейс 2: Уязвимости Ivanti Connect Secure (2024–2025)

Несколько уязвимостей в Ivanti Connect Secure попали в CISA KEV. Использование VPN-шлюза Ivanti широко распространено в корпоративной среде. Уязвимые компоненты относились к edge-инфраструктуре с высокой интернет-экспозицией — именно то сочетание, которое требует ускоренного (Tier 0) патчинга. Организации, полагавшиеся только на CVSS без учёта KEV и экспозиции, рисковали долгое время оставаться уязвимыми перед активными атаками. Ivanti входит в список вендоров с наибольшим числом KEV-записей за 2024–2025 годы [15].

Кейс 3: Follina (CVE-2022-30190) — классика CVSS-провала

Уязвимость MSDT с CVSS 7.8. Несколько месяцев активно эксплуатировалась для распространения вымогательского ПО — пока оценка оставалась «Important» вместо «Critical». Организации с пороговой политикой «патчить только Critical» пропустили одну из наиболее активно используемых угроз того периода [8].

Часть 8. Тренды и будущее управления уязвимостями

Рост объёма CVE и автоматизация

Прогноз FIRST на 2026 год — 59 427 CVE (медиана); верхняя граница на 2028 год — 193 000 [1]. Ручная приоритизация при таких объёмах физически невозможна. Будущее — в автоматизированном составном скоринге с интеграцией в тикетные системы (Jira, ServiceNow) и автоматическим назначением владельцев.

Сжатие окна эксплуатации

В 2024 году медиана времени от публикации CVE до появления эксплойта составляла менее одного дня (по данным Mandiant). Это означает, что традиционные двухнедельные и месячные циклы патчинга де-факто устарели для уязвимостей высокого приоритета [23].

CTEM как эволюция VM

Continuous Threat Exposure Management (CTEM) — следующая ступень эволюции vulnerability management. В отличие от периодического сканирования, CTEM предполагает непрерывную переоценку экспозиции с учётом изменений инфраструктуры, угроз и бизнес-контекста. Gartner выделяет CTEM как один из ключевых трендов кибербезопасности.

Роль искусственного интеллекта

Автоматизированный патчинг с применением AI начинает выходить за пределы экспериментальных проектов (Google Research, Red Hat Lightspeed MCP). Перспективное направление — AI-assisted тriage, где алгоритмы предварительно классифицируют уязвимости с учётом контекста, снижая когнитивную нагрузку на аналитиков.

Российская специфика: импортозамещение и VM

Быстрый рост номенклатуры отечественного ПО создаёт дополнительную сложность: CVE-база хуже покрывает российское ПО, а культура ответственного раскрытия уязвимостей (responsible disclosure) находится в стадии формирования [22]. Это означает, что российские организации должны особенно внимательно отслеживать БДУ ФСТЭК и вендорские бюллетени — в дополнение к международным базам.

Заключение: от огнетушения к риск-менеджменту

Суть перехода к risk-based vulnerability management можно сформулировать кратко: нельзя защититься от всего, но можно защититься от того, что действительно важно прямо сейчас.

Практические шаги:

1. Перестать воспринимать CVSS Base Score как инструмент приоритизации — принять его как один из входных сигналов.
2. Внедрить ежедневный мониторинг CISA KEV (и/или VulnCheck KEV) и БДУ ФСТЭК как обязательный элемент процесса.
3. Интегрировать EPSS в составной скоринг: пороговое значение 10% — разумная точка отсчёта для фокуса внимания.
4. Классифицировать активы по критичности и интернет-экспозиции — без этого любой скоринг остаётся абстрактным.
5. Ввести дифференцированные SLA: Tier 0 (24 часа) для KEV + критичный актив; плановые циклы для остального.
6. Документировать все принятые риски — это не бюрократия, а защита от регуляторных и операционных последствий.
7. Измерять MTTR в разбивке по приоритетным уровням и итерировать процесс.

Риск-ориентированная приоритизация — это не разовый проект, а зрелый процесс. Организации, выстроившие его, перестают реагировать на шум тысяч «критических» уязвимостей и начинают управлять реальным риском.

О решении «Пятый фактор»

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

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

Пятый фактор — on-prem платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах (БД, хранилища, почта, AD/LDAP, CRM, 1С, API). Принципиальная особенность решения — работа исключительно с метаданными, структурой и агрегатами, без хранения и передачи «сырых» ПДн. Это означает, что платформа сама не становится источником риска.

Для процесса управления уязвимостями это означает конкретное преимущество: живая «карта данных» позволяет точнее классифицировать активы по критичности — не абстрактно, а с учётом реального состава данных. Система, содержащая ПДн клиентов или финансовые данные, автоматически получает более высокий приоритет в очереди патчинга. Новые источники данных и интеграции видны сразу — до того, как они превращаются в неизвестные риски. Это превращает непрерывный контроль из желаемого в достижимое.

Источники

[1] FIRST Annual Vulnerability Report 2026 — https://www.hackerstorm.com/index.php/articles/our-blog/hackerstorm/50k-cves-2026-vulnerability-management-strategy

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

[3] HackerStorm — Vulnerability Management: Operational Risk & Exposure-Based Prioritization — https://www.hackerstorm.com/index.php/articles/our-blog/vulnerabililty-intelligence/vulnerability-management-operational-risk-exposure-prioritization

[4] VulnCheck / Cybernews — Zero-day Exploit Trends 2025 — https://www.hackerstorm.com/index.php/articles/our-blog/vulnerabililty-intelligence/vulnerability-management-operational-risk-exposure-prioritization

[5] Bitsight — A Global View of the CISA KEV Catalog: Prevalence and Remediation — https://www.helpnetsecurity.com/2024/05/13/kev-catalog-prevalent-vulnerabilities/

[6] Tenable — Why You Need to Stop Using CVSS for Vulnerability Prioritization — https://www.tenable.com/blog/why-you-need-to-stop-using-cvss-for-vulnerability-prioritization

[7] Beyond CVSS: New Frameworks for Vulnerability Risk Assessment (Infosecurity Europe) — https://www.infosecurityeurope.com/en-gb/blog/future-thinking/new-frameworks-vulnerability-risk-assessment.html

[8] Ivanti — Risk-Based Patch Management Prioritizes Active Exploits — https://www.ivanti.com/blog/how-implementing-risk-based-patch-management-prioritizes-active-exploits

[9] Anti-Malware.ru — Управление уязвимостями в 2025 году (AM Live) — https://www.anti-malware.ru/analytics/Technology_Analysis/Vulnerability-Management-AM-Live-2025

[10] FIRST — EPSS Model — https://www.first.org/epss/model

[11] SecOps Solution — EPSS v4 — https://www.secopsolution.com/blog/epss-v4

[12] Orca Security — EPSS Scoring System Explained — https://orca.security/resources/blog/epss-scoring-system-explained/

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

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

[15] Cyble — 2025 CISA KEV Catalog Hits 1,484 Exploited Vulnerabilities — https://cyble.com/blog/cisa-kev-2025-exploited-vulnerabilities-growth/

[16] VulnCheck — A Peek Into the Known Exploited Vulnerabilities of 2024 — https://www.vulncheck.com/blog/comparing-kevs-jupyter

[17] Black Kite — 2025 Supply Chain Vulnerability Report — https://content.blackkite.com/ebook/2025-supply-chain-vulnerability-report/trends-and-statistics

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

[19] VulnCheck — Helping Enterprises & Governments Adopt SSVC — https://www.vulncheck.com/blog/automating-ssvc

[20] Инфратех — Управление уязвимостями ФСТЭК: процесс, требования и примеры — https://blog.infra-tech.ru/upravlenie-uyazvimostyami-fstek/

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

[22] Positive Technologies / itsec.ru — Управление уязвимостями в 2024 году: что изменилось — https://www.itsec.ru/articles/upravlenie-uyazvimostyami-v-2024-godu-chto-izmenilos-i-kak-perestroit-process

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

[24] S2W Blog / Medium — Detailed Analysis of Recent Trends in Known Exploited Vulnerabilities — https://medium.com/s2wblog/detailed-analysis-of-recent-trends-in-known-exploited-vulnerabilities-c81678a47f39

[25] Tandem — How Soon Should Vulnerabilities Be Patched? — https://tandem.app/blog/how-soon-should-vulnerabilities-be-patched