? Это часть 10 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Это, пожалуй, самая важная глава серии. Найти уязвимости несложно, сканер выдаст их тысячами. Сложно понять, за какие хвататься.

Цифры за 2025 год: опубликовано 48 185 уязвимостей, а признаки эксплуатации в реальных атаках к концу года нашлись примерно у одного процента из них [1]. Вся приоритизация сводится к тому, чтобы найти этот процент раньше, чем его найдут против вас.

Аргумент, что это не теория, дал Verizon в отчете за 2026 год. Эксплуатация уязвимостей впервые за девятнадцать лет наблюдений вышла на первое место среди способов первичного проникновения: 31% взломов против 13% через украденные учетные данные [2]. Раньше первое место годами держали учетки. Теперь ломают через дыры, которые кто-то не закрыл вовремя.

“Любая приоритизация не будет работать, если не проведена качественная инвентаризация и не проведена категоризация каждого узла в вашей инфраструктуре”.

Приоритизировать можно по-разному. Одни компании собирают экспертные комиссии и оценивают все сами, другие целиком полагаются на методику вендора или регулятора. Разберем, какие инструменты для этого есть, как они устроены и что с ними случилось за последние два года.

Почему одного CVSS недостаточно

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

Посмотрите на масштаб. Из 48 185 уязвимостей 2025 года высокий или критический уровень получили около 39%: 15 003 высоких и 3 984 критических [1]. Доля, кстати, снижается четвертый год подряд, но легче от этого не становится: девятнадцать тысяч “срочных” уязвимостей в год - это примерно пятьдесят каждый день, включая выходные. Патчить все подряд по этому критерию невозможно физически. А самое обидное, что подавляющее большинство из них никто никогда не тронет. CVSS не отвечает на главный вопрос: воспользуется ли этим хоть кто-нибудь?

Поэтому работает совокупность факторов. Сначала смотрим на опасные уязвимости на периметре, потом на целевые и ключевые системы, ведь именно через них приходят к недопустимым событиям. Критерии, по которым стоит расставлять приоритеты:

Возможные последствия эксплуатации. В одной системе бывают сотни уязвимостей с одинаковым баллом и совершенно разными последствиями. Отказ в обслуживании в веб-приложении на периметре неприятен, но контроля над приложением злоумышленнику не дает. А обход аутентификации с тем же баллом открывает админ-интерфейс без пароля, и если на сервере есть интерфейс внутренней сети, вы получаете готовую точку входа внутрь. Приоритет у второй уязвимости совсем другой.

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

Наличие эксплойта или примера эксплуатации. Есть готовый эксплойт - уязвимостью воспользуется даже школьник. Круг потенциальных нарушителей расширяется мгновенно. А квалифицированному злоумышленнику хватит одного описания, чтобы написать эксплойт самому.

Доступность актива для нарушителя. Система в закрытом сегменте или вообще за воздушным зазором интересна куда меньшему кругу желающих. Одна и та же уязвимость на периметре и во внутренней сети - это две разные уязвимости с точки зрения риска.

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

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

CVSS: как он устроен

CVSS (Common Vulnerability Scoring System) - международный стандарт оценки опасности уязвимостей, который ведет организация FIRST. Балл считается по формуле, поэтому оценки разных людей сходятся, а результат можно сравнивать.

Шкала простая: от 0,1 до 3,9 - низкая опасность, от 4,0 до 6,9 - средняя, от 7,0 до 8,9 - высокая, от 9,0 до 10,0 - критическая.

CVSS 3.1: три группы метрик

Отрасль долго жила на версии 3.1, и она до сих пор доминирует. Метрики делятся на три группы:

• базовые - неизменные свойства уязвимости: как трудно ее эксплуатировать и что она ломает в конфиденциальности, целостности, доступности;

• временные - поправка на момент: созрел ли эксплойт, вышел ли патч, насколько достоверны сведения;

• контекстные - привязка к вашей инфраструктуре: что для вас важнее, конфиденциальность или доступность.

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

Базовый балл собирается из вектора атаки (насколько удаленно можно бить), сложности атаки, требуемых привилегий, необходимости взаимодействия с пользователем, области действия и влияния на конфиденциальность, целостность и доступность.

Пример расчета и заодно урок. CVE-2023-36884 - удаленное выполнение кода в Windows Search, которое эксплуатировали через специально сформированные документы Office. Вектор атаки сетевой, сложность высокая, привилегии не нужны, а вот жертва должна открыть файл. Влияние на конфиденциальность, целостность и доступность высокое. Итог по формуле CVSS 3.1 - 7,5 балла, высокий уровень [3].

Урок в другом. При публикации в июле 2023 года Microsoft дала этой уязвимости 8,3 балла, а позже снизила оценку до 7,5. Балл CVSS - не физическая константа. Он меняется, когда меняется понимание уязвимости, и по одной и той же CVE у вендора и в базе данных вполне могут стоять разные цифры. Строить процесс на предположении, что балл вечен, не стоит.

CVSS 4.0: что изменилось

В ноябре 2023 года FIRST выпустила CVSS 4.0, первый мажорный релиз с 2015 года [4]. Главное:

• Явная номенклатура. Теперь видно, что именно учли: CVSS-B (только базовые метрики), CVSS-BT (плюс угрозы), CVSS-BE (плюс контекст), CVSS-BTE (все сразу). Прямой ответ на болезнь голого базового балла.

• Новая метрика Attack Requirements (AT) - условия, при которых атака вообще возможна, отдельно от сложности атаки.

• Взаимодействие с пользователем описывается детальнее: None / Passive / Active вместо “нужно или не нужно”.

• Scope заменили двойной моделью воздействия: отдельно на уязвимую систему (VC/VI/VA) и на смежные (SC/SI/SA). Стало видно, запирается ли ущерб внутри одной системы или растекается дальше.

• Группу Temporal переименовали в Threat и ужали до одной метрики - зрелости эксплойта.

• Появились Supplemental Metrics. На балл они не влияют, но дают контекст. Среди них Safety: может ли эксплуатация покалечить или убить людей. Для АСУ ТП и медицинской техники это не абстракция.

Теперь оговорка для практики. Переход идет медленно: из уязвимостей, опубликованных за 2025 год, оценку по версии 4.0 получили 25,9% [5]. Причина не в лени вендоров, а в том, что главные источники обогащения данных, NVD и программа CISA ADP, версию 4.0 почти не публикуют. Так что ближайшие годы мы проведем в мире, где у одной уязвимости спокойно бывает два разных балла по двум разным версиям стандарта.

Балл, которого может не быть

А в апреле 2026 года случилось то, что ломает привычку опираться на CVSS сильнее любых версий стандарта. NIST объявил, что NVD обогащает данными только те уязвимости, которые попали в каталог активно эксплуатируемых, относятся к федеральному ПО США или к критическому ПО по американскому перечню. Остальные получают статус наименьшего приоритета: без балла CVSS, без привязки к продуктам, без классификации типа. Около 29 тысяч накопленных записей перевели в разряд “не запланировано к обработке” [6].

Что это значит на практике. Если ваш процесс приоритизации начинается со строчки “берем балл CVSS из NVD”, то по доброй половине свежих уязвимостей вы этот балл просто не получите. Придется брать оценку у вендора, из БДУ ФСТЭК или считать самим. И держать в голове, что вендорские оценки и оценки NIST расходятся больше чем в половине случаев, где есть обе, а расхождение доходит до 6,9 балла из 10 [6]. Подробнее эту историю с источниками данных разбираем в следующей части, здесь важен вывод: единого авторитетного балла для всего потока уязвимостей больше нет, и приоритизация переезжает на другие опоры.

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

CVSS отвечает на вопрос “насколько уязвимость тяжелая”. EPSS отвечает на вопрос “воспользуются ли ею”. Для приоритизации второй вопрос обычно важнее.

EPSS (Exploit Prediction Scoring System) - вероятностная модель FIRST, которая каждый день пересчитывает, будет ли уязвимость эксплуатироваться в ближайшие 30 дней [7]. Под капотом машинное обучение примерно на 1 100 признаках: публичные эксплойты, упоминания в соцсетях и рассылках, данные threat intelligence, телеметрия средств защиты.

Модель выдает два числа, и их постоянно путают:

• probability (вероятность) - от 0 до 1. Значение 0,05 читается как “5% вероятности эксплуатации в следующие 30 дней”;

• percentile (перцентиль) - какая доля всех уязвимостей набрала балл ниже. Вероятность 0,10 соответствует примерно 88-му перцентилю: 88% уязвимостей оценены ниже [8].

Ошибка, которую совершают почти все на старте: выставляют порог по перцентилю, думая, что настроили порог по вероятности. Перцентиль 90 звучит внушительно, но означает всего лишь “выше девяти десятых потока”, а сама вероятность там может быть меньше 0,1. Решайте, что именно вам нужно, и подписывайте это в регламенте словами, а не числом без единиц.

В марте 2025 года вышла четвертая версия модели. К признакам добавили телеметрию вредоносного ПО и теперь EPSS видит активность эксплуатации примерно по 12 тысячам уязвимостей ежемесячно [9].

Насколько это выгоднее привычного порога по CVSS, FIRST показывает на своих же цифрах. Стратегия “патчим все с CVSS 7 и выше” накрывает 82,2% реально эксплуатируемых уязвимостей, но точность у нее 3,96%: из ста запатченных уязвимостей в дело пошли бы четыре. Стратегия “патчим все с EPSS выше 0,1” накрывает 63,2% при точности 65,2% [7]. Покрытие просело, а вот отношение полезной работы к бесполезной выросло примерно в шестнадцать раз. Это и есть разница между командой, которая захлебывается, и командой, которая успевает.

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

LEV: а не эксплуатировали ли ее раньше

В мае 2025 года NIST выпустил документ CSWP 41 с новой метрикой LEV - Likely Exploited Vulnerabilities [10]. Идея простая и до странного очевидная: EPSS каждый день говорит про будущие 30 дней, но никто не складывал эти ежедневные оценки за всю историю уязвимости. А если сложить, получится оценка того, что уязвимость уже эксплуатировали, просто это нигде не зафиксировали.

Зачем это нужно. Каталоги эксплуатируемых уязвимостей заведомо неполны: туда попадает то, что заметили и подтвердили. EPSS смотрит вперед и по старым уязвимостям обычно дает низкие баллы, потому что всплеск активности давно прошел. Между этими двумя инструментами есть слепая зона: старая уязвимость, которую активно эксплуатировали полгода назад, ни в один каталог не попала и сегодня выглядит безобидно. LEV эту зону подсвечивает. Кстати ни в каком отечественном решении я не видел LEV, (по крайней мере на момент написание текста) может конечно сыровато еще.

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

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

CISA KEV (Known Exploited Vulnerabilities) - каталог уязвимостей с подтвержденными фактами эксплуатации в реальных атаках [11]. Логика предельно простая: если уязвимость здесь, значит, ею уже пользуются, и патчить надо немедленно, что бы ни говорил балл CVSS.

За 2025 год каталог пополнился на 245 записей и закрыл год на отметке 1 484, а к июлю 2026 года дорос примерно до 1 650 [12]. Это меньше половины процента от всех известных уязвимостей - тот самый процент, который реально опасен.

Долгое время сроки устранения задавала директива BOD 22-01: федеральные агентства США обязаны были закрывать KEV-уязвимости в фиксированные сроки, а всем остальным она досталась как бесплатный ориентир. В июне 2026 года ее заменила BOD 26-04, и логика стала тоньше: вместо единого срока для всего каталога появилась матрица, где сроки зависят от риска, а самое горячее закрывают за трое суток [13]. Направление понятное - даже двухнедельный срок для активно эксплуатируемой дыры на периметре уже выглядит роскошью.

И тут же грустная статистика. По Verizon DBIR 2026 полностью устраняется лишь 26% уязвимостей из KEV, а медиана времени устранения - 43 дня [2]. Годом раньше было 38% и 38 дней. То есть по уязвимостям, про которые точно известно, что их эксплуатируют, компании стали работать медленнее, а не быстрее.

Каталог не один

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

Первая - методология. CISA включает в каталог уязвимость только тогда, когда для нее есть понятное исправление или обходное решение. Для директивы, которая обязывает агентства действовать, это разумно: нельзя требовать закрыть то, что закрыть нечем. Но часть реально эксплуатируемых уязвимостей в каталог из-за этого не попадает. Коммерческий каталог VulnCheck KEV таких ограничений не ставит: записей в нем больше 3 600, вендоров он охватывает в разы больше, а уязвимости появляются в среднем на 27 дней раньше, чем у CISA [14]. Двадцать семь дней при нынешнем темпе атак - целая эпоха.

Вторая причина организационная. CISA с начала 2025 года потеряла заметную часть сотрудников, и бюджетные планы предполагают дальнейшие сокращения [15]. Каталог держится на людях, которые подтверждают факты эксплуатации. Меньше людей - выше шанс, что каталог начнет отставать. Для нас вывод простой: американский каталог полезен, но первым делом смотреть стоит на трендовые уязвимости БДУ, о которых ниже.

Работают ли EPSS и KEV в России

Здесь нужно остановиться и сказать то, чего обычно не говорят в переводных статьях про приоритизацию. Оба инструмента, которые мы только что разобрали, устроены вокруг CVE. Нет CVE - нет ни балла EPSS, ни шанса попасть в KEV: наличие идентификатора прямо записано первым из трех условий отбора CISA [11]. И для российской инфраструктуры это ограничение работает жестче, чем кажется.

В БДУ ФСТЭК больше 88 тысяч записей, и часть из них живет без CVE - это, как правило, уязвимости отечественного ПО, которые вендор не регистрировал через MITRE. Для них EPSS не существует в принципе. Не “низкий балл”, а пустое место.

Дальше начинается вторая проблема, менее очевидная. EPSS предсказывает эксплуатацию по наблюдаемым сигналам: публичные эксплойты, упоминания, телеметрия средств защиты, ханипоты, сканеры вроде Shodan. Все эти источники смотрят в глобальный интернет и в парк западных вендоров. Российский корпоративный сегмент они видят плохо, а специфический отечественный софт не видят вовсе. Это, к слову, не заговор против нас: та же слепота накрывает любой региональный и нишевый продукт, у которого нет большой международной инсталляционной базы. Просто у нас доля такого софта растет с каждым годом импортозамещения.

С каталогом KEV история похожая. Его собирает CISA, американское агентство при Министерстве внутренней безопасности, и собирает под конкретную задачу - обязать федеральные агентства США закрывать то, что бьет по ним. Формально критерии универсальны, фактически состав отражает американский парк ПО: за 2025 год лидеры по числу добавленных записей - Microsoft (39 записей), следом Apple, Cisco, Google, Ivanti, Linux. Российских продуктов в каталоге нет ни одного [12].

В августе 2025 года Positive Technologies раскрыла цепочку уязвимостей в TrueConf Server - российской системе видеоконференций, у которой в стране больше семи тысяч установок. Самая тяжелая из них, BDU:2025-10116, позволяла выполнить произвольные команды операционной системы, оценка 9,8. Патчи вышли 27 августа [16].

С сентября того же года эту цепочку начала эксплуатировать в атаках на российские организации группировка PhantomCore [17]. То есть перед нами ровно то, ради чего придумана приоритизация: критическая уязвимость, публичный эксплойт, подтвержденные атаки, широко распространенный в стране продукт.

Публичного CVE у этой цепочки нет. В CISA KEV она не попала и не могла попасть. Балла EPSS у нее нет и не будет. Компания, которая приоритизирует уязвимости по западным метрикам, увидела бы на этом месте пустоту.

Финальный штрих. В апреле 2026 года в KEV попала уязвимость TrueConf - только другая, про проверку целостности обновлений клиента, с нормальным номером CVE-2026-3502 [18]. Она была интересна международной аудитории продукта. Вывод неутешительный: в западные каталоги вас пускает не опасность уязвимости, а ее международная заметность.

Теперь честно про обратную сторону, потому что вывод “выбросить западные метрики” был бы такой же ошибкой. Windows, Linux, Kubernetes, nginx, PostgreSQL, VMware, сетевое железо стоят и в российских инфраструктурах, зачастую составляя их основу. По этому пласту EPSS и KEV работают ровно так же хорошо, как везде, и отказываться от них странно. Больше того, там, где отечественный вендор ведет открытую программу багбаунти или собирает продукт из открытого кода, CVE появляются исправно.

А вот где у закрытого отечественного продукта своя разработка и нет международного внимания - там публичных CVE почти нет. Это не значит, что уязвимостей нет. Это значит, что узнать о них можно только из БДУ, если вообще можно.

Практический вывод простой. EPSS и KEV в российской инфраструктуре - вспомогательный слой, работающий по международной части вашего стека. Первым эшелоном для нас идет другое.

Трендовые уязвимости: первый эшелон

ФСТЭК ведет в БДУ раздел наиболее опасных уязвимостей - те самые трендовые [20]. По смыслу это российский аналог KEV, только с поправкой на то, какой софт стоит у нас и кто по нам работает.

Сразу оговорка о точности: отдельного публичного документа с формальными критериями отбора именно в этот раздел ФСТЭК не публиковал. По практике и по описаниям российских VM-вендоров критерий читается так: есть публичный эксплойт плюс подтвержденные факты эксплуатации в атаках. Регламент включения в саму БДУ при этом задает сроки - уязвимости критического и высокого уровня попадают в базу не позднее пяти рабочих дней с момента получения сведений.

За 2025 год в трендовые добавили 216 уязвимостей, и 74 из них в каталоге KEV отсутствовали [20]. Больше трети российского горящего списка американский каталог не увидел.

Списки вендоров: тоже самое, но быстрее

Помимо регулятора, свои списки трендовых ведут российские VM-вендоры, и это не маркетинговое дублирование. Регулятору положено быть точным, вендору - быстрым, и на дистанции в несколько часов эта разница решает.

Подробнее всех методику раскрывают ребята из Positive Technologies. Уязвимость признают трендовой, когда сходятся три условия: злоумышленник может через нее развить атаку до недопустимого события, для нее есть эксплойт (в идеале публичный и проверенный), и продукт широко распространен в российских компаниях. Заявленный срок доставки детекта в продукт - не больше 12 часов с момента признания. За 2025 год трендовыми признали чуть больше шестидесяти уязвимостей, почти половина из них - продукты Microsoft [21].

R-Vision собирает собственную базу, куда данные стекаются из более чем трех сотен источников с обновлением каждые восемь часов; критерий тот же - публичный эксплойт плюс подтвержденная эксплуатация [20].

Обратите внимание на порядок цифр. У регулятора счет идет на дни, у вендоров - на часы, а трендовых уязвимостей за год набирается несколько десятков против сорока восьми тысяч в общем потоке. Это и есть тот самый рабочий список, который реально можно закрыть за сутки.

Чем ломают на самом деле

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

По данным RED Security за 2025 год и начало 2026 года, эксплуатация публично доступных приложений встречается примерно в каждом втором инциденте, а на отрасли, связанные с КИИ, приходится подавляющее большинство атак [22]. В отчете ГК “Солар” о реальных проверках периметра картина дополняется: недостатки контроля доступа - 33% находок, использование ПО с известными уязвимостями - 28%, слабые пароли и SQL-инъекции - по 20%. Во внутренней сети на первом месте слабые и дефолтные пароли (53%) и устаревшее ПО (42%), а уязвимости, дающие проход внутрь, нашлись у 78% проверенных компаний [23].

Из этого следуют две вещи, которые стоит принять как есть. Первая: в топе эксплуатируемого у нас по-прежнему западные и открытые продукты - SharePoint, Cisco, WSUS, Chrome, Bitrix, Kibana. Значит, международные источники данных нужны. Вторая: заметная часть входов - это вообще не уязвимости в смысле CVE, а слабые пароли и дырявый контроль доступа, которые ни в KEV, ни в EPSS, ни в трендовых не появятся никогда. Приоритизация уязвимостей не заменяет базовую гигиену.

SSVC: дерево решений вместо балла

SSVC (Stakeholder-Specific Vulnerability Categorization) придумали в Институте программной инженерии университета Карнеги-Меллона, а CISA сделала свою версию [24]. Вместо числа вы получаете решение, к которому приводит дерево вопросов:

• Act - устранять немедленно;

• Attend - устранять ускоренно, вне планового цикла;

• Track* - следить с повышенным вниманием;

• Track - устранять в плановом порядке.

Узлы дерева: эксплуатируется ли уязвимость (нет данных / есть PoC / активная эксплуатация), можно ли автоматизировать атаку, каков технический ущерб, насколько актив важен для работы организации, влияет ли это на безопасность людей. В версии 2.1 узел Utility заменили на Automatable, и дерево для эксплуатирующей организации похудело со 108 конечных узлов до 72 [24]. Мелочь, а на практике это разница между методикой, которую применяют, и методикой, которую распечатали и повесили на стену.

Ценность SSVC не в дереве как таковом, а в том, что оно заставляет проговорить контекст вслух. По сути это формализация той самой совокупности факторов, с которой мы начали статью.

Методика ФСТЭК: российский стандарт

Для российских компаний, особенно из госсектора, КИИ и финансов, главный ориентир - методика ФСТЭК. В июне 2025 года вышла новая редакция “Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств”, и от редакции 2022 года она отличается заметно [25].

Внимание. Если вы знаете методику по старым статьям и презентациям, сверьтесь с оригиналом: за три года изменилось и то, что считают, и то, какие пороги считают критичными. В редакции 2022 года формула состояла из двух множителей - базовой оценки CVSS и влияния на инфраструктуру. В редакции 2025 года к ним добавились доступность эксплойта и характер последствий, а границы уровней критичности сдвинулись вверх.

Формула (редакция 2025 года)

Где:

• I_cvss - базовая оценка по CVSS 3.1. Берем у вендора, в БДУ или в NVD; версия 4.0 методике не нужна.

• I_infr - насколько уязвимый компонент влияет на инфраструктуру. Считаем как . Здесь K описывает тип компонента и меняется от 0,1 для прочих до 1,1 для тех, что заняты в критичных бизнес-процессах: межсетевой экран и сетевое оборудование весят 0,9, сервер - 0,7, рабочая станция - 0,5. L показывает, какая доля компонентов уязвима: 0,5, если меньше десятой части, и до 1,0, если больше семидесяти процентов. P отвечает за периметр: 0,6, если из интернета не достучаться, и до 1,1, если достучаться можно.

• I_at - можно ли уязвимость эксплуатировать. Ставим 0,6, если эксплуатацию подтвердили в реальных атаках; 0,3, если известно о готовых инструментах; 0,1, если про эксплуатацию ничего не слышно.

• I_imp - к чему приведет эксплуатация. Выполнение произвольного кода и повышение привилегий весят 0,5, обход средств защиты - 0,4, внедрение кода - 0,34, кража конфиденциальных данных и нарушение целостности - 0,3, отказ в обслуживании - 0,26, а дальше шкала спускается до 0,1 за межсайтовый скриптинг.

Дальше итоговое V раскладывается по уровням: больше 8,0 - критический, от 5,0 до 8,0 - высокий, от 2,0 до 5,0 - средний, меньше 2,0 - низкий. Обратите внимание, что пороги в редакции 2025 года подняли: раньше критическим считалось все, что выше 7,0.

Теперь посмотрим, как это работает, на примере из самой методики. Уязвимость в межсетевом экране, который доступен из интернета, базовая оценка CVSS - 8,8. Считаем влияние на инфраструктуру: . Данных об эксплуатации нет, значит I_at равен 0,1. Последствие - обход средств защиты, это 0,4. Итого , средний уровень [25].

Вдумайтесь в этот результат. По CVSS уязвимость почти критическая, по методике - средняя. Вся разница в том, что эксплуатировать ее пока нечем.

А теперь представьте, что через неделю появился рабочий эксплойт и подтвердились атаки. I_at вырастает до 0,6, и та же самая уязвимость дает - высокий уровень, вплотную к критическому. В инфраструктуре не изменилось ничего. Изменился внешний мир.

Отсюда прямое следствие, которое методика проговаривает отдельно: оценка справедлива только на текущий момент. Появились активы, обновились сведения об узле или об уязвимости - пересчитывайте. Вручную это делается ровно один раз, поэтому пересчет должна выполнять VM-система.

Чем хороша новая редакция? Она проще в автоматизации, потому что не требует возиться с временными и контекстными метриками CVSS, которых все равно почти нигде нет. И по смыслу она пришла туда же, куда пришел весь мир: тяжесть уязвимости сама по себе мало что значит, значение имеют эксплуатируемость и последствия.

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

Алгоритм НКЦКИ: обновлять или нет

Есть еще один документ, который в 2022 году был реакцией на конкретную беду, а с тех пор стал рабочим инструментом. В апреле 2022 года НКЦКИ опубликовал критерии для принятия решения об обновлении критичного ПО, не относящегося к open source [26]. Проблема, которую он решает, специфически наша: обновление зарубежного ПО из способа закрыть уязвимость превратилось в самостоятельный риск, потому что в апдейте может приехать сюрприз.

Напомню, что способов управлять уязвимостью всего три: обновиться, принять риск с компенсирующими мерами, отказаться от ПО и заменить его. Алгоритм помогает выбрать между первым и вторым.

Дерево решений выглядит так:

1. Разработчик ПО - резидент РФ? Если да, обновляемся, дальше идти незачем. Если нет - следующий вопрос.

2. Уязвимость на периметре? Если да, проверки эксплойта и типа уязвимости пропускаются, и мы сразу переходим к оценке по CVSS. Периметр - это то, куда стучатся каждый день.

3. Есть публичный эксплойт? Если да, обновляемся.

4. Тип уязвимости - RCE, LPE или DoS? Если нет, обновление не производим.

5. Базовая оценка CVSS 3.1 выше 7? Если да, обновляемся.

6. Существенно ли влияние на бизнес при отказе сервиса? Если нет, обновление не производим.

7. Мешают ли эксплуатации уже имеющиеся средства защиты? Если да, обновление не производим. Если нет, обновляемся.

И отдельной стрелкой в схеме - периодическая переоценка, то есть возврат в начало. Решение “пока не обновляем” не бессрочное.

Оговорки самого НКЦКИ стоит держать в голове. Алгоритм рекомендательный, граничные случаи не разбирает, обновление в любом случае положено гонять в тестовой среде, а для АСУ ТП и мобильных операционных систем эта схема не предназначена вовсе. Ну и главное: если у вас есть возможность самостоятельно проверить обновление на недекларированные возможности, руководствуйтесь результатами своей проверки, а не блок-схемой.

На больших масштабах алгоритм имеет смысл применять не к каждой уязвимости, а к каждому продукту в инфраструктуре, и результат фиксировать в регламенте. Иначе на седьмом вопросе по сотому продукту вы просто устанете.

P.S. Справедливости ради, сейчас почти нигде не вижу применения этого алгоритма

Сколько на самом деле нужно патчить

Отдельно стоит сказать про масштаб, потому что он снимает лишнюю тревогу. Многолетние исследования Cyentia и Kenna Security по приоритизации дают устойчивую картину: известные эксплойты есть примерно у 5% опубликованных уязвимостей, а у 62% вероятность эксплуатации не дотягивает и до одного процента. При этом типичная организация закрывает около 15% открытых уязвимостей в месяц [27].

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

Инструментов набрался целый арсенал. Чтобы не сойти с ума, выстраивайте их воронкой.

1. Сначала то, что точно эксплуатируется у нас. Трендовые уязвимости БДУ и списки трендовых от российских вендоров, в первую очередь на периметре и целевых системах. Сроки - часы, обсуждению не подлежит.

2. Затем то, что эксплуатируется в мире. Каталоги эксплуатируемых уязвимостей по международной части стека: Windows, гипервизоры, сетевое железо, открытые компоненты.

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

4. Дальше контекст инфраструктуры. Прогоняем оставшихся кандидатов через доступность для нарушителя, последствия эксплуатации и значимость актива. Здесь работает методика ФСТЭК или логика SSVC.

5. Все остальное - в плановый цикл обновлений.

Порядок первых двух шагов не случаен и отличается от того, что вы прочитаете в переводных руководствах. Для российской инфраструктуры трендовые БДУ идут раньше американского каталога, потому что видят то, чего он не видит, и видят раньше.

Воронка сходится с регуляторными сроками. Приказ ФСТЭК № 117 требует от государственных систем закрывать критические уязвимости за 24 часа, высокие - за 7 дней. Уложиться в сутки можно только по короткому списку, а короткий список получается только приоритизацией. Как связать уровни критичности со сроками и с чьей стороны берутся цифры, разбирали в части про организационные мероприятия.

Отдельно про вендорские скоринги. Tenable VPR, Qualys TruRisk, Rapid7 Active Risk и их российские аналоги делают ровно то же самое: смешивают тяжесть, эксплуатируемость и контекст в один балл. Пользоваться этим удобно, спорить с математикой вендора трудно. Единственное требование, которое стоит предъявлять: вы должны понимать, из чего балл собран, и уметь объяснить его администратору, которому в три часа ночи предстоит перезагружать сервер. Балл, который нельзя объяснить, в спорах с ИТ не работает.

Главная мысль простая. Не пытайтесь патчить все, пытайтесь патчить правильное. CVSS говорит, насколько уязвимость тяжелая. EPSS - насколько вероятна атака, но только там, где ему есть на что смотреть. Каталоги эксплуатируемых уязвимостей - что горит в мире, трендовые БДУ - что горит у нас. Методика ФСТЭК и значимость активов - что опасно именно для вас. Вместе они превращают неподъемные сорок восемь тысяч в список из десятков позиций, с которым уже можно работать.

И держите в голове, что окно закрылось. Mandiant в отчете за 2026 год приводит среднее время до эксплуатации, и оно ушло в минус: около семи дней до выхода патча, тогда как в 2018 году было 63 дня после [28]. GreyNoise насчитала в 2025 году 146 уязвимостей с массовой эксплуатацией против 71 годом ранее, причем всплеск сканирований часто опережает публичное раскрытие примерно на 11 дней [29]. Приоритизация перестала быть способом сэкономить силы. Она стала способом успеть.

А как у вас?

По чему вы приоритизируете уязвимости - все еще по голому CVSS или уже подключили EPSS, каталоги эксплуатируемых уязвимостей, трендовые БДУ? И главный вопрос этой статьи: какая доля вашего парка приходится на отечественное ПО и что ваш процесс приоритизации вообще знает об уязвимостях в нем? Если у вас был случай, когда важную уязвимость не увидел ни один западный каталог, расскажите - это самая полезная часть комментариев.

? Источники и ссылки

Источники главы

1. Jerry Gamblin, “2025 CVE Data Review”: 48 185 опубликованных CVE за 2025 год, из них 3 984 критических и 15 003 высоких. https://jerrygamblin.com/2026/01/01/2025-cve-data-review/ ; VulnCheck, “2026 Exploit Intelligence Report”: около 1% CVE 2025 года эксплуатировались в реальных атаках к концу года. https://www.vulncheck.com/blog/2026-vulncheck-exploit-intelligence-report

2. Verizon, Data Breach Investigations Report 2026: эксплуатация уязвимостей как вектор первичного доступа - 31% взломов против 13% через украденные учетные данные; полное устранение KEV-уязвимостей - 26%, медиана 43 дня (в DBIR 2025 по всему каталогу KEV - 38% и 38 дней). https://www.verizon.com/business/resources/reports/dbir/

3. NVD, CVE-2023-36884 (Windows Search Remote Code Execution Vulnerability): CVSS 3.1 - 7,5, вектор AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H; первоначальная оценка Microsoft при публикации в июле 2023 года - 8,3. https://nvd.nist.gov/vuln/detail/CVE-2023-36884

4. FIRST, CVSS 4.0 Specification (ноябрь 2023). https://www.first.org/cvss/v4.0/

5. VulnCheck, “Critical CVEs, CVSS v4, and the Adoption Gap No One Talks About”: оценку по CVSS 4.0 получили 25,9% CVE, опубликованных в 2025 году; NVD и CISA ADP версию 4.0 почти не публикуют. https://www.vulncheck.com/blog/cvss-severity

6. NIST, обновление политики работы NVD (апрель 2026): обогащение только для уязвимостей из каталога эксплуатируемых, федерального и критического ПО; около 29 тысяч записей переведены в статус “не запланировано”. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth ; разбор последствий и расхождения вендорских и NIST-оценок: https://www.tenable.com/blog/nvd-cuts-cve-enrichment-how-tenable-helps

7. FIRST, EPSS model: сравнение стратегий приоритизации (CVSS 7+ - покрытие 82,2% при точности 3,96%; EPSS 0,1+ - покрытие 63,2% при точности 65,2%). https://www.first.org/epss/model

8. FIRST, “Probability, Percentiles, and Binning”: вероятность 0,10 соответствует примерно 88-му перцентилю. https://www.first.org/epss/articles/prob_percentile_bins

9. EPSS v4 (17 марта 2025): телеметрия вредоносного ПО в признаках модели, данные об активности эксплуатации примерно по 12 тысячам уязвимостей ежемесячно. https://research.empiricalsecurity.com/research/introducing-epss-version-4

10. NIST, Cybersecurity White Paper 41 “Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability” (19 мая 2025). https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.41.pdf

11. CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

12. Динамика каталога KEV: 1 239 записей на конец 2024 года, 1 484 на конец 2025 года (+245 за год), около 1 650 на конец июля 2026 года (по официальному фиду CISA). https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries/ ; https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

13. CISA, Binding Operational Directive 26-04 “Prioritizing Security Updates Based on Risk” (10 июня 2026): заменила BOD 22-01, ввела матрицу сроков устранения в зависимости от риска, минимальный срок - 3 дня. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

14. VulnCheck KEV: более 3 600 записей, добавление в среднем на 27 дней раньше каталога CISA, охват вендоров шире; включение не требует наличия исправления. https://www.vulncheck.com/press/vulncheck-kev-10000

15. Сокращение штата и бюджета CISA в 2025-2026 годах как риск для устойчивости каталога KEV. https://www.nextgov.com/cybersecurity/2025/06/cisa-projected-lose-third-its-workforce-under-trumps-2026-budget/405726/

16. Positive Technologies, раскрытие уязвимостей TrueConf Server (август 2025): BDU:2025-10114 (недостаточный контроль доступа к административным эндпоинтам), BDU:2025-10115 (чтение произвольных файлов), BDU:2025-10116 (выполнение произвольных команд ОС, оценка 9,8); исправления от 27.08.2025; более 7 тысяч установок продукта в России. Разбор: https://avleonov.com/2025/09/30/1587-about-remote-code-execution-trueconf-server-bdu2/ ; БДУ ФСТЭК: https://bdu.fstec.ru/

17. Эксплуатация цепочки уязвимостей TrueConf Server группировкой PhantomCore в атаках на российские организации с сентября 2025 года. https://thehackernews.com/2026/04/phantomcore-exploits-trueconf.html

18. CVE-2026-3502 (TrueConf, проверка целостности обновлений клиента) добавлена в каталог CISA KEV 2 апреля 2026 года. https://cyberpress.org/cisa-adds-trueconf-flaw/

19. Уязвимости российского ПО в публичных базах: 44 записи БДУ по 1С-Битрикс со средним баллом CVSS 7,5 (продукт участвует в публичной программе багбаунти); для Astra Linux и ALT Linux уязвимости приходят преимущественно через открытые компоненты. https://sgrc.cyberosnova.ru/instrumenty/uyazvimosti/bitrix/ ; объем БДУ ФСТЭК - свыше 88 тысяч записей: https://sgrc.cyberosnova.ru/blog/bdu-fstek-rukovodstvo/

20. R-Vision, “Дайджест трендовых уязвимостей. 2025 год”: 216 трендовых уязвимостей добавлено в БДУ за 2025 год, 74 из них отсутствовали в каталоге CISA KEV. https://rvision.ru/expertise/daydzhest-trendovykh-uyazvimostey-2025-god ; раздел наиболее опасных уязвимостей БДУ ФСТЭК. https://bdu.fstec.ru/vul/danger

21. Positive Technologies, методика трендовых уязвимостей: три критерия отнесения (возможность развить атаку до недопустимого события, наличие эксплойта, распространенность продукта в российских компаниях), заявленный срок доставки детекта - не более 12 часов; статистика трендовых за 2023-2025 годы. https://ptsecurity.com/research/knowledge-base/trendovye-uyazvimosti-2023/

22. RED Security SOC, итоги 2025 года и I квартала 2026 года: эксплуатация публично доступных приложений примерно в каждом втором инциденте; доля атак на отрасли, связанные с КИИ. https://habr.com/ru/companies/ru_mts/articles/992144/

23. ГК “Солар”, “Ключевые уязвимости информационных систем российских компаний”: недостатки контроля доступа - 33%, использование ПО с известными уязвимостями - 28%, слабые пароли и SQL-инъекции - по 20%; во внутренней сети слабые и дефолтные пароли - 53%, устаревшее ПО - 42%; уязвимости с выходом во внутреннюю сеть у 78% проверенных компаний. https://rt-solar.ru/analytics/reports/6479/

24. CMU SEI / CISA, Stakeholder-Specific Vulnerability Categorization (SSVC): четыре исхода Act / Attend / Track* / Track. https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc ; версия SSVC 2.1 - точка решения Automatable вместо Utility, дерево Deployer сокращено со 108 до 72 конечных узлов. https://github.com/CERTCC/SSVC/discussions/285

25. Методический документ “Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств”, ФСТЭК России (первая редакция 28.10.2022, действующая редакция от 30.06.2025): формула V = Icvss x Iинфр x (Iat + Iimp), состав показателей, таблицы значений и пороги уровней критичности, примеры расчета в приложении. Полный текст: https://base.garant.ru/412383948/ ; https://sudact.ru/law/metodicheskii-dokument-metodika-otsenki-urovnia-kritichnosti-uiazvimostei_1/ . Редакция 2022 года: формула V = Icvss x Iинфр, пороги 7,0 / 4,5 / 1,5. https://legalacts.ru/doc/metodicheskii-dokument-metodika-otsenki-urovnja-kritichnosti-ujazvimostei-programmnykh-programmno-apparatnykh/

26. НКЦКИ, “Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source” (ALRT-20220415.1 от 15.04.2022, TLP: WHITE): дерево решений из семи узлов, оговорки о тестовой среде, АСУ ТП и мобильных ОС. https://safe-surf.ru/upload/ALRT/ALRT-20220415.1.pdf

27. Cyentia Institute / Kenna Security, серия исследований “Prioritization to Prediction”: известные эксплойты примерно у 5% опубликованных уязвимостей, у 62% вероятность эксплуатации ниже 1%, организации закрывают около 15% открытых уязвимостей в месяц. https://library.cyentia.com/report/report_003467.html

28. Mandiant (Google Threat Intelligence Group), M-Trends 2026: среднее время до эксплуатации - около минус 7 дней относительно выхода исправления (2018 год - 63 дня, 2023 - 5 дней, 2024 - минус 1 день). https://www.helpnetsecurity.com/2026/03/24/mandiant-m-trends-2026-report/

29. GreyNoise, “2025 Mass Internet Exploitation Report”: 146 уязвимостей с массовой эксплуатацией против 71 в 2024 году; медианный разрыв между всплеском активности и публичным раскрытием - 11 дней. https://www.greynoise.io/blog/2025-mass-internet-exploitation-report

---

Навигация по серии: ⬅️ Предыдущая: Гл. 9. Нельзя защитить то, о чем не знаешь · ? Оглавление серии · Следующая: Гл. 11. Что случилось с NVD и почему опираться на один источник уязвимостей больше нельзя ➡️

Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.