Задача – есть поток новостей об уязвимостях, из него надо отбирать те, что заслуживают внимания сегодня. Значит, нужно правило, по которому одна уязвимость важнее другой. Казалось, что правило давно есть и его достаточно применить в рамках новостей, используя формулу. Оказалось, что само это правило как раз сейчас переосмысливают, причём у всех регуляторов.

Как именно эти правила меняются и что из этого следует для отбора важности новостей попробуем разобраться. Замеры сделаны на открытых данных CISA KEV, NVD, EPSS и БДУ ФСТЭК.

Откуда берутся уязвимости

Дыры находят исследователи, сами вендоры, программы вознаграждений и, случается, атакующие раньше всех. Номер CVE присваивают не в одном месте. Только за прошлый год номера выдали 364 организации, от крупных вендоров до площадок, регистрирующих уязвимости плагинов. Дальше запись расходится по базам. Американская NVD добавляет оценку опасности, европейская и российская ведут свои каталоги со своей нумерацией. Охват, скорость и сама оценка у них разные, единого реестра «вот это опасно, а это нет» не существует, к сожалению.

Логика поменялась схожим образом у всех регуляторов

Раньше срок устранения назначали по баллу CVSS. Балл считают из свойств самой уязвимости, а именно как до неё добраться (доступ по сети, права, действие пользователя) и что она даёт атакующему: чтение данных, их изменение, отказ системы. Получается число от нуля до десяти и класс опасности. И регламент был такой – критическое закрыть за столько-то дней, высокое за столько-то.

Удобство очевидное. Одно число, одна шкала, легко записать в требования и проверить исполнение. И как раз это правило идеально подходило для отбора новостей для агрегатора. Следствие менее очевидное. В формуле нет ни слова о том, атакуют ли уязвимость в реальности и как устроена конкретно ваша инфраструктура.

За последний год от этой схемы отказались три регулятора подряд

Директива CISA BOD 26-04 от 10 июня 2026 года убрала пороги по баллу и поставила четыре признака, главный из которых это наличие записи в каталоге эксплуатируемых.
Статья 14 европейского регламента о киберустойчивости действует с 11 сентября 2026 года и обязывает производителя сообщать об активно эксплуатируемой уязвимости в течение суток.
Приказ ФСТЭК № 117 от 11 апреля 2025 года вступил в силу 1 марта 2026 года и сделал обязательными сроки по методике, где пометка об атаках поднимает уровень критичности.

А с 15 апреля 2026 года NIST размечает не всё подряд, а в первую очередь то, что уже попало в каталог эксплуатируемых, используется в федеральных системах или отнесено к критическому ПО. Балл перестали ставить всем ровно тогда, когда по нему перестали назначать сроки.

Кратко – регуляторы перешли от серьёзности уязвимостей к эксплуатации уязвимостей

Почему балл перестал работать и при чём тут ИИ

Балл не справлялся с главной задачей – он не выбирает опасное. До подтверждённой эксплуатации доходят пять уязвимостей из тысячи, и балл эту пятёрку не угадывает. А из тысячи критических уязвимостей туда не попадут 988, а среди попавших большинство не критические.

Критическая уязвимость по CVSS не значит эксплуатируемая (по крайней мере публично)

Сроки устранения балл не упорядочивает тоже. Среди тех, кого начали эксплуатировать, критические подтверждают в медиане через 21 день, высокие же через 6. Шкала, которой назначали срочность, ранжирует ровно наоборот. Если кратко, то соответствия между «нужно скорее закрыть уязвимость патчем» и «можно дождаться следующего мажорного релиза» балл CVSS не давал.

Регуляторы, кстати, объясняют перемену иначе. В директиве написано, что применение атакующими искусственного интеллекта может ещё сузить окно для защитника ~~(ну конечно, до ИИ проблемы же не было)~~. Это проверяемо, только считать надо порогом, а не медианой. Медиана по свежей выборке короче просто потому, что длинные сроки у молодых записей ещё не наступили.

Число уязвимостей, которые начинают эксплуатировать в первый месяц после публикации, из года в год держится около сотни, а в пересчёте на объём даже падает. Независимый каталог VulnCheck на своих данных приходит к тому же.

Изменился общий объём, да. Поток новых записей вырос почти вдвое, и список критических перестал быть планом работ просто потому, что стал слишком длинным. Долю полезного сигнала в потоке все труднее выявить. Виноват ли в росте количества искусственный интеллект, здесь уже не измерялось. Регуляторы безусловно правы в решении и, возможно, неточны в обосновании

Сигнал об эксплуатации без чётких границ

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

В регламенте «эксплуатируется» звучит как «Да» или «Нет», на деле это оценочное суждение, и базы судят по-разному. Нагляднее всего на Log4j. У библиотеки пять известных номеров. Два из них, включая Log4Shell, попали в американский каталог эксплуатируемых. По трём остальным CISA пишет, что признаков эксплуатации не наблюдает. Российский банк данных пометил связь с инцидентами у всех пяти. Заодно разошлись и баллы. У одной и той же уязвимости NVD дала 5,9 и средний уровень, БДУ 7,5 и высокий. Случай не единичный, пометка об инцидентах стоит в банке у 3 501 уязвимости с номером CVE, и по 887 из них CISA явно указывает, что эксплуатации не видит.

Вторая особенность даже поважнее. Сигнал приходит у всех по-разному, и зависит это не от атакующих, а от того, принято ли у производителя писать об атаках

Когда подтверждают эксплуатацию, зависит от производителя

У Microsoft, Fortinet и Apple медиана срока от публикации до подтверждения нулевая, они пишут об эксплуатации в своём бюллетене, и каталог принимает запись в тот же день. У Cisco и VMware это 13 дней, у Linux и Apache от 106 до 135, потому что подтверждение приходит от третьих лиц и когда придёт. Месяцы здесь означают месяцы неведения, а не спокойное время. Уязвимость CVE-2023-0266 в ядре Linux эксплуатировали как нулевой день за три месяца до записи в каталоге.

Можно даже сделать промежуточный субъективный вывод. Норматив «устранить за сутки» у Microsoft ускоряет защиту по-настоящему, сигнал приходит вместе с исправлением. У ядра Linux тот же норматив начинает тикать тогда, когда всё уже произошло. Новые правила регулируют скорость реакции на сигнал эксплуатации, а не скорость появления самого этого сигнала.

Российский контур

В России к той же модели пришли раньше и оформили жёстче. Уровень критичности по методике ФСТЭК считается из балла, важности системы и коэффициента эксплуатации. В примере самой методики уязвимость без сведений об атаках получает средний уровень и четыре недели, с пометкой об атаках получает критический уровень и сутки. Один такой признак меняет срок в 28 раз. Приказ № 117 сделал эти сроки обязательными для государственных систем и потребовал сообщать регулятору об уязвимостях, которых в банке нет.

Дальше математика, которая объясняет, зачем в методике есть понижающие поправки. За последнее полугодие банк опубликовал 8 660 записей, 51% из них критического или высокого уровня. Это около 36 записей в каждый рабочий день под срок «сутки или неделя». Без поправки на важность системы норматив физически невыполним.

Для отечественного ПО внешних источников очевидно нет. Из 1 756 записей, где все производители российские, номера CVE нет у 92%, и ни американский каталог, ни прогнозные модели понятное дело о них не знают. При этом есть и обратная сложность. Обновление само по себе уже может быть риском, поэтому НКЦКИ предлагал отдельный алгоритм решения об установке обновлений.

Что с этим делать

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

Сигнал №1 это бюллетень безопасности вендора, он выходит раньше любого каталога. У Microsoft это ежемесячный набор бюллетеней с признаком, обнаружена ли эксплуатация, и он же отдаётся машиночитаемо. У Fortinet, Cisco и Apple свои разделы с лентами, каталог CISA выкладывается одним файлом, БДУ отдаётся выгрузкой.

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

И общее правило. Отсутствие записи в базе ничего не доказывает, а её наличие не значит, что спешить надо со всем вендором сразу.

Как приоритизировать новости об уязвимостях вместо балла CVSS