От балла к факту: как регуляторы меняют подход к приоритизации уязвимостей
За последние двенадцать месяцев регуляторы во всем мире, включая CISA, Евросоюз и ФСТЭК, фактически отказались от использования баллов CVSS в качестве единственного критерия срочности устранения уязвимостей. Новым ориентиром стал признак активной эксплуатации в реальной среде. Анализ открытых данных показывает, что сигнал об атаке приходит от разных вендоров с задержкой от нуля до трех с половиной месяцев, что требует от специалистов изменения стратегий мониторинга и рассылки новостей.
# От теоретической тяжести к реальному риску: новые правила оценки уязвимостей
До последнего времени логика управления безопасностью была предельно простой и формализованной: уязвимость получает балл сложности CVSS (от 0 до 10), и на его основе рассчитывается срок устранения. Критические уязвимости требовали исправления срочно, а остальные — в плановом порядке. Однако эта модель страдала от фундаментального противоречия: высокий балл не означал, что атака уже произошла, а низкий — что её можно игнорировать. Сейчас регуляторы по всему миру делают ставку на факт эксплуатации, игнорируя формальные баллы при выборе приоритетов.
Почему балл CVSS перестал быть универсальным ориентиром
Система CVSS оценивает теоретический ущерб: насколько легко взломать систему и какой доступ получит злоумышленник. Это число удобно для отчетности и составления чек-листов, но оно слепо к реальности. Исследования показывают, что из тысячи критических уязвимостей по баллу лишь около пяти процентов достигают этапа подтвержденной эксплуатации в публичном поле. При этом среди тех, кого реально эксплуатируют, многие классифицировались бы как уязвимости среднего или высокого уровня, если бы мы смотрели только на теорию.
Проблема усугубляется тем, что сроки устранения по баллу часто противоречили скорости появления патчей. Уязвимость, оцененная как критическая, могла оставаться открытой месяцами в ожидании мажорного релиза, в то время как другие, менее опасные теоретически, активно использовались в атаки. Регуляторы пришли к выводу, что шкала тяжести не справляется с задачей ранжирования реальной угрозы, особенно в эпоху, когда искусственный интеллект ускоряет процессы поиска и эксплуатации дыр в ПО.
Глобальный сдвиг: от сроков к признаку эксплуатации
В течение года три ключевых регуляторных блока перешли на новые методики. Директива CISA BOD 26-04, вступившая в силу в июне, убрала жесткие пороги по баллам и установила четыре признака риска, где главным является наличие записи в каталоге эксплуатируемых уязвимостей (KEV). Европейский регламент о киберустойчивости обязывает производителей сообщать об активно эксплуатируемых дырах в течение суток. В России приказ ФСТЭК № 117 также переориентировал подход: отсутствие сведений об атаках дает средний уровень критичности и сроки до четырех недель, тогда как подтверждение факта эксплуатации автоматически поднимает уровень до «критического» со сроком устранения в сутки.
Этот сдвиг означает, что «эксплуатируется» больше не является вопросом степени тяжести кода, а становится бинарным фактом: или атака подтверждена, или нет. При этом само понятие «подтверждена» на практике оказывается оценочным суждением. Например, в случае знаменитой уязвимости Log4Shell американская база CISA отметила эксплуатацию только по двум номерам CVE, в то время как российская БДУ пометила все пять известных записей как связанные с инцидентами. Различия в баллах между базами достигали значений в полтора балла, что демонстрирует субъективность исходных данных.
Асимметрия скорости реакции вендоров
Самым критичным аспектом нового подхода стала зависимость времени обнаружения от политики самого производителя. Если вендор, такой как Microsoft или Apple, оперативно публикует бюллетень безопасности, в котором прямо указывает на факт эксплуатации, то сигнал попадает в каталоги CISA практически мгновенно — задержка составляет около нуля. В таких системах норматив «исправить за сутки» начинает тикать одновременно с моментом публикации исправления.
Другие игроки, например Cisco, VMware, а также сообщества Linux и Apache, подтверждают факты эксплуатации с заметным опозданием — от 13 до более чем 130 дней. В этих случаях нормативы, основанные на времени, начинают работать уже после того, как уязвимость эксплуатировалась публично месяцами. Ядром Linux, например, эксплуатировали уязвимость CVE-2023-0266 как минимум за три месяца до того, как это было официально зафиксировано в базах. Новые правила регулируют реакцию на сигнал, а не скорость его возникновения, что делает прозрачность коммуникации с производителями ПО решающим фактором для безопасности.
Новая стратегия для экспертов и аналитиков
Для специалистов по безопасности и новостных агрегаторов старые правила отбора материалов больше не работают. Важнее не балл CVSS, а задержка между появлением уязвимости и первым публичным сигналом об атаке. Эффективная стратегия требует подписки не на общие отчеты, а на специфические ленты безопасности производителей, которые действительно используются в инфраструктуре. Необходимо искать в бюллетенях вендоров не цифры баллов, а формулировки об обнаружении эксплуатации.
Ситуация осложняется тем, что отсутствие записи в базе не доказывает безопасность, а наличие записи не всегда означает немедленную угрозу для конкретной системы. Однако для приоритизации новостей факт атаки теперь перевешивает теоретическую оценку. В современных лентах новостей серьезность поднимается не по шкале CVSS, а по наличию признаков активной эксплуатации и отсутствию патча. Такой подход позволяет отсеивать информационный шум и фокусироваться на реальных рисках, которые требуют немедленного внимания.
В заключение стоит отметить, что единого реестра опасностей не существует, а скорость реакции различается у всех участников рынка. Единственный способ снизить риски — это переход от пассивного ожидания отчетов к активному мониторингу источников, где информация об эксплуатации появляется раньше всего.