10 июня 2026 года CISA выпустила директиву BOD 26-04 Prioritizing Security Updates Based on Risk. Новый документ отменяет BOD 19-02 и BOD 22-01 — директиву, которая с 2021 года задавала для федеральных агентств США единые календарные сроки устранения уязвимостей из каталога Known Exploited Vulnerabilities, KEV. Вместо плоского дедлайна новая модель предлагает определять срок по риску конкретного актива.

Для приоритизации CISA учитывает четыре обстоятельства: доступен ли актив публично, есть ли уязвимость в KEV, можно ли автоматизировать её эксплуатацию и к какому техническому эффекту приводит атака. Таблица сроков, как указывает сама CISA, построена с опорой на SSVC. В наиболее срочном случае уязвимость нужно устранить в течение трёх дней и провести первичный forensic triage; в наименее срочном исправление допускается при очередном плановом обновлении системы.

Наиболее неудобный объект для такого подхода — AI-платформа. В её разных слоях слово «устранить» означает принципиально разные действия. В веб-API это может быть обычный патч; в цепочке ML-зависимостей — мажорное обновление фреймворка; в GPU-рантайме — обновление драйвера или прошивки с окном простоя; в инференс-движке — ожидание решения от мейнтейнера либо замена компонента. Для весов модели патча в привычном смысле может не быть вовсе.

Поэтому одинаковый CVSS не означает одинаковый приоритет, срок и способ обработки. В этой статье восемь публичных CVE из типового AI-стека проходят через дерево решений: для каждой записи разберём доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Также покажем, как получить пороги для принятия решений из опубликованных данных FIRST.

Материал рассчитан на AppSec- и DevSecOps-инженеров, которые ведут бэклог уязвимостей платформы, и на тимлидов, у которых релиз зависит от открытых security-тикетов. Руководителям ИБ будет полезен отдельный раздел о требованиях ФСТЭК. Подход применим и к обычной инфраструктуре без GPU и моделей: в таком случае меняется набор активов, но не логика приоритизации.

Как плоский дедлайн стал отраслевым ориентиром

BOD 22-01 была адресована федеральным гражданским агентствам США, но её логика вышла за пределы госсектора. Поле due date в каталоге KEV показывают сканеры уязвимостей и учитывают при настройке внутренних SLA. Поэтому отмена плоского календарного подхода важна не только для организаций, на которые распространялись директивы CISA: она меняет один из наиболее заметных внешних ориентиров для управления уязвимостями.

BOD 26-04 не предлагает медленнее устранять известные эксплуатируемые уязвимости. Меняется сам принцип: вместо общего дедлайна для всех команда оценивает конкретную ситуацию — где работает уязвимый компонент, доступен ли он атакующему, насколько легко автоматизировать атаку и к чему она приведёт. По этому контексту и выбирают реалистичный срок исправления.

В России риск-ориентированный подход к устранению уязвимостей также закреплён в документах ФСТЭК: методическом документе от 30 июня 2025 года и приказе № 117, устанавливающем сроки устранения. В статье эти требования рассматриваются как отдельная нормативная рамка, а не как прямая копия модели CISA или SSVC.

Откуда взялся календарь

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

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

NVD больше не успевает оценивать все CVE

В апреле 2026 года NIST изменил порядок работы National Vulnerability Database, NVD. Причина — рост потока CVE и накопившийся бэклог неразобранных записей. По данным NIST, с 2020 по 2025 год число поступающих CVE выросло на 263%, а за первый квартал 2026 года оказалось почти на треть выше, чем за тот же период годом ранее. NIST сообщает об изменениях в работе NVD.

С 15 апреля 2026 года NVD в первую очередь обогащает три группы записей:

• уязвимости из каталога CISA Known Exploited Vulnerabilities, KEV;

• уязвимости в ПО, которое используется федеральными органами США;

• уязвимости в критически важном ПО из перечня Executive Order 14028.

Для остальных CVE NVD по-прежнему публикует запись, но может не добавлять сведения, которые обычно нужны для автоматической приоритизации: список затронутых продуктов, сопоставление с CPE, собственную оценку CVSS и другие результаты аналитической обработки. Такие записи получают статус Lowest Priority — not scheduled for immediate enrichment. Старый бэклог — записи, опубликованные до 1 марта 2026 года, — переведён в статус Not Scheduled. NIST также указывает, что теперь обычно не будет добавлять свою оценку severity, если CVSS уже опубликовал CNA.[nist]

Для платформенной команды это меняет практику работы с источниками. Свежая CVE может появиться в NVD без CVSS от NIST, а запись из старого бэклога — надолго остаться без обогащения. Ниже встретятся две уязвимости из AI-стека, для которых собственной оценки NVD нет. У одной из них в карточке прямо указан статус Not Scheduled: NVD не планирует обрабатывать её в ближайшее время.

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

CVSS измеряет тяжесть, а не риск

Вторая проблема связана с самим CVSS. В руководстве FIRST по CVSS 4.0 прямо сказано: базовая оценка CVSS измеряет severity, то есть техническую тяжесть уязвимости, и её нельзя использовать как единственный показатель риска. Базовый балл описывает внутренние свойства дефекта; он не учитывает, есть ли рабочий эксплойт, атакуют ли уязвимость на практике и в каком окружении работает уязвимый продукт. CVSS v4.0 User Guide.

Поэтому в CVSS 4.0 появилась группа метрик Threat. Она позволяет скорректировать базовую оценку с учётом threat intelligence — сведений об эксплуатации уязвимости и доступности технических средств для атаки. FIRST отдельно отмечает, что это должно уменьшить проблему завышенных базовых оценок.

Похожую мысль FIRST формулирует в FAQ по EPSS: CVSS оценивает severity, но высокий балл лишь слабо помогает предсказывать реальную эксплуатацию. Для задач приоритизации недостаточно знать, насколько тяжёлым выглядит сценарий атаки в теории. Нужно понимать, насколько вероятна эксплуатация и какие последствия она вызовет именно в данном контуре. FAQ по EPSS.

В интерфейсе NVD рядом с блоком оценок есть подсказка: CVSS не измеряет риск. Балл стоит учитывать при приоритизации, но срок исправления по нему одному назначать нельзя.

Оценки расходятся и у самих источников

Даже когда CVSS есть, он не всегда одинаков у разных оценщиков. В препринте исследователей Zhang, Massacci и Zhang от 6 июля 2026 года расхождения между оценками NVD и публичных CNA названы широко распространёнными, хотя и неоднородными. Чаще всего авторы фиксируют расхождения в метриках Attack Complexity, User Interaction и метриках влияния.

Авторы проверили, как это влияет на модели приоритизации. Модель, обученная на оценках одного источника, при переносе на данные другого может потерять до 40% точности. Они также ввели термин self-divergence: один и тот же CNA может по-разному оценивать CVE с одинаковым описанием и одинаковым CWE.

Разные оценки не обязательно означают ошибку: оценщик мог учесть сведения, которых нет в публичном описании, или иначе интерпретировать условия эксплуатации. Авторы отмечают, что в некоторых случаях расхождение оправданно и что с 2025 года ситуация постепенно улучшается. При этом работа опубликована как препринт и ещё не прошла рецензирование.

Почему календарь всё ещё живёт

Несмотря на ограничения CVSS, календарные циклы обновлений остаются частью нормальной инженерной практики. Инженер группы Vulnerability Management в Ozon описывал, что полный цикл установки обновлений Windows занимает 30 календарных дней, а для Linux — 90 дней. Эти сроки привязаны к ритму поставщиков обновлений, тестированию и выпуску изменений в продуктивную среду.

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

Однако в платформах с разнородным стеком не каждое исправление укладывается в обычный цикл. Патч веб-сервиса можно выкатить быстро. Обновление ML-фреймворка иногда требует проверки совместимости и повторного обучения или валидации модели. Замена версии GPU-драйвера может потребовать простоя и миграции нагрузок. Для уязвимости в неподдерживаемом инференс-движке либо в артефакте модели готового патча может не существовать.

При этом зрелые команды уже не опираются только на CVSS. В Ozon приоритизация учитывает наличие CVE в KEV, оценку EPSS, статус EOL у ПО, доступность актива и размер поверхности атаки. Открытые риск-тикеты могут блокировать релизы, а эскалация в зависимости от ситуации доходит до CTO.

Где календарь становится обязательным

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

В российском контуре сроки закреплены нормативно. Приказ ФСТЭК России № 117 от 11 апреля 2025 года вступил в силу 1 марта 2026 года. Пункт 38 устанавливает предельные сроки устранения: для критических уязвимостей — не более 24 часов, для высоких — не более семи календарных дней. К тому, что именно регулятор считает устранением и как эти сроки соотносятся с особенностями AI-стека, вернёмся в разделе о ФСТЭК.

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

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

Один балл на пять разных слоёв

AI-платформа плохо укладывается в календарный SLA. Она состоит из компонентов, для которых «устранить уязвимость» означает разные вещи: обновить библиотеку, перейти на новую версию фреймворка, перезагрузить GPU-узлы, заменить неподдерживаемый компонент или отозвать модельный файл. Один и тот же балл CVSS в этих случаях ведёт к разным действиям, срокам и ограничениям.

Веб-API и обвязка

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

CVE-2024-8309 в LangChain — SQL-инъекция через GraphCypherQAChain. В NVD для неё приведены две оценки: 9,8 Critical от NVD и 4,9 Medium от huntr и Protect AI как CNA. Разница — 4,9 балла.

Оценщики расходятся по всем трём группам метрик. NVD считает, что атака идёт по сети, не требует сложных условий и приводит к высоким последствиям для конфиденциальности, целостности и доступности. CNA описывает локальную атаку с высокой сложностью и низким влиянием. Даже CWE указаны разные: CWE-74 у NVD и CWE-89 у CNA. В одной схеме SLA такая CVE попадёт в корзину «исправить за 30 дней», в другой — «закрыть за 90 дней».

У CVE-2024-5184 в EmailGPT сразу три оценки: 9,1 Critical от NVD, 6,5 Medium от Synopsys по CVSS 3.1 и 8,5 High от того же Synopsys по CVSS 4.0. Сама уязвимость не менялась, но переход на новую версию шкалы переносит её в другую SLA-категорию. В трёх записях с двойной оценкой в рамках одной версии CVSS разброс составил от 1,7 до 4,9 балла.

ML-зависимости: патч как мажорный апгрейд

CVE-2025-32434 в PyTorch получила оценку 9,3 Critical по CVSS 4.0 от GitHub как CNA. Уязвимость позволяет выполнить удалённый код через torch.load даже при weights_only=True — параметре, который команды включали именно в целях защиты.

При этом NVD ещё не добавила для записи оценку по CVSS 4.0: в карточке указано NVD assessment not yet provided. По CVSS 3.1 есть оценка NVD — 9,8 Critical. В результате у одной CVE рядом существуют 9,8 от NVD по старой версии шкалы и 9,3 от CNA по новой.

Главная проблема здесь не в расхождении баллов, а в способе исправления. Уязвимы версии PyTorch 2.5.1 и ниже, исправление вышло в 2.6.0. Версии 2.5.2 в ленте релизов PyPI нет. В SECURITY.md PyTorch прямо сказано: исправления безопасности вносятся только в текущий релиз и не переносятся в старые версии.

Поэтому закрыть CVE-2025-32434 означает обновить PyTorch до новой минорной ветки. Для многих ML-систем это уже не обычное обновление зависимости, а проект: нужно проверить совместимость пакетов, контейнеров, CUDA-стека, пайплайнов обучения и инференса, а иногда — воспроизводимость результатов модели.

Срок, отсчитываемый от публикации CVE, тоже может вводить в заблуждение. PyTorch 2.5.1 вышел 29 октября 2024 года, версия 2.6.0 — 29 января 2025 года, а CVE опубликована 18 апреля 2025 года. Исправление существовало 79 дней до публикации записи. Команда, которая регулярно обновляла PyTorch, могла закрыть проблему ещё до появления CVE. Команда с жёстко закреплённой версией получила требование выполнить мажорный апгрейд в сжатый срок.

Масштаб этой зависимости хорошо показывает доклад Patrick Smyth из Chainguard на PyTorch Conference 2024. В официальном образе PyTorch он насчитал одну Critical-, пять High-, 40 Medium- и более 50 Low-уязвимостей. По его оценке, около 2% CVE в типовом ML-развёртывании возникают в коде самой команды, а остальное приходит из upstream-зависимостей и базовых образов.

Темп релизов делает закреплённые версии отдельным фактором риска. У vLLM за 204 дня вышли 24 релиза в 14 минорных ветках: новая минорная версия появлялась примерно раз в две недели. LTS-веток у проекта нет, а патчи выпускаются только для актуальной минорной линии. У PyTorch за двадцать с половиной месяцев вышли восемь минорных веток и 11 релизов с учётом патч-релизов. Если зафиксировать версию инференс-движка на квартал, к концу периода можно отстать на шесть или семь минорных релизов — там же обычно и находятся исправления безопасности.

GPU-рантайм и прошивки

CVE-2025-23266, также известная как NVIDIAScape, имеет оценку 9,0 Critical по CVSS 3.1 от NVIDIA как CNA. Уязвимость в NVIDIA Container Toolkit позволяет выйти из контейнера на хост. OCI-хук запускает nvidia-ctk с правами root и наследует переменные окружения из контейнерного образа, включая LD_PRELOAD. Для эксплуатации достаточно трёх строк в Dockerfile. Описание эксплойта NVIDIAScape.

Результат — root-доступ на хосте и потенциальный доступ к моделям, данным и нагрузкам соседних арендаторов. Для этой уязвимости публичная доступность хоста не главный критерий. Wiz отдельно подчёркивает: атакуемый узел не обязан быть доступен из интернета. Достаточно, чтобы атакующий мог запустить контейнер на разделяемой GPU-инфраструктуре. Разбор NVIDIAScape от Wiz.

У CVE-2025-23266 нет оценки NVD: карточка помечена статусом Not Scheduled. Исправления есть — NVIDIA Container Toolkit 1.17.8 и новее, GPU Operator 25.3.1 и новее. Но обновление GPU Operator на работающем кластере обычно требует отдельной операции: согласования окна, миграции или остановки нагрузок, проверки совместимости драйверов и перезапуска узлов. В качестве временной меры NVIDIA предлагает отключить CUDA compatibility library hook через параметр disable-cuda-compat-lib-hook = true в /etc/nvidia-container-toolkit/config.toml.

Ещё ниже по стеку меняется сам вид исправления. CVE-2023-4969, LeftoverLocals, позволяет одному GPU-ядру прочитать данные из local memory, оставшиеся после выполнения другого ядра, в том числе принадлежащего другому пользователю или приложению. В NVD уязвимость оценена в 6,5 Medium.

В календарной модели она может оказаться среди задач «закрыть в течение 90 дней». Для мультитенантной AI-платформы это нарушение изоляции между арендаторами. Исправление требует обновить прошивку ускорителя и драйвер, а это уже операция на уровне оборудования. Сканер контейнерных образов её не увидит и не закроет. Среди затронутых устройств — AMD Instinct MI300X, MI250, MI210, Radeon Pro W7600 и другие GPU.

Инференс-движок без патча

CVE-2025-30165 в vLLM получила 8,0 балла по CVSS 3.1 и относится к CWE-502 — небезопасной десериализации. В карточке NVD указано, что исправление потребовало бы слишком масштабной переработки кода, поэтому мейнтейнеры не планируют выпускать патч. Вместо этого они советуют разворачивать vLLM только в изолированной, контролируемой сети.

Команда не сможет закрыть такую уязвимость обычным обновлением. Если внутренний SLA требует устранить High-уязвимость за 60 дней, выполнять требование придётся компенсирующими мерами: ограничить сетевой доступ к сервису, изолировать его от недоверенных систем, запретить обработку недоверенных входных данных или заменить vLLM другим компонентом.

Мейнтейнеры vLLM указывают, что старый путь исполнения уступил место V1, который стал режимом по умолчанию с версии 0.8.0. Но в релиз-нотах проекта сказано, что это верно только для поддерживаемых сценариев. Для моделей и функций с признаком SupportsV0Only старый путь всё ещё может использоваться. Поэтому эксплуатанту нужно проверять, какой путь фактически работает в его конфигурации.

CVE-2023-48022 в Ray известна по кампании ShadowRay. NVD присвоила ей 9,8 Critical и отметила запись тегом disputed. Позиция вендора сводится к тому, что Ray предназначен для строго контролируемой сети и не должен работать в открытом окружении. Токен-аутентификация появилась как опция начиная с версии 2.52.0.

Здесь расходятся не оценки, а представления о допустимой модели эксплуатации. В реестре уязвимость выглядит как Critical CVE в рабочем компоненте и попадает под жёсткий SLA. Вендор считает, что риск снимается правильной сетевой изоляцией: Ray изначально рассчитан на работу только в контролируемом окружении. Среди восьми записей из этого разбора только для этой CVE CISA SSVC указывает automatable = yes — атаку можно автоматизировать полностью.

В этом слое важна и граница самой CVE. Oligo описала паттерн ShadowMQ: небезопасная связка ZeroMQ recv_pyobj() и pickle попала в несколько проектов через переиспользование эталонной реализации. Паттерн обнаружили в инференс-серверах Meta, NVIDIA, Microsoft, vLLM, SGLang и Modular. В SGLang уязвимый файл начинается с комментария Adapted from vLLM. Разбор ShadowMQ от Oligo.

На ноябрь 2025 года статусы проектов различались:

Если для компонента нет CVE, сканер его обычно не заметит, а в таблице SLA для него не найдётся строки. Так устроен процесс, который опирается только на реестр уязвимостей.

Похожая ситуация возникает у цепочки из трёх уязвимостей NVIDIA Triton: CVE-2025-23319, CVE-2025-23320 и CVE-2025-23334. Вместе они позволяют неаутентифицированному удалённому атакующему захватить сервер. Описание цепочки в NVIDIA Triton.

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

У CVE-2025-23319 NVIDIA PSIRT поставила 8,1 High и указала CWE-805, а NVD — 9,8 Critical и CWE-787. Векторы расходятся только по Attack Complexity. Между внутренним отчётом и публикацией патча прошло 81 день, детали координированного раскрытия задокументированы.

Веса модели вне CVE

Модельный файл может не иметь ни номера версии, ни вендора, ни CVE. При этом его загрузка способна привести к выполнению кода. В SECURITY.md PyTorch это сформулировано прямо: модель PyTorch следует считать программой, а запуск недоверенной модели эквивалентен запуску недоверенного кода.

Там же есть раздел Issues That Are Not Security Vulnerabilities. В него входят:

• сбои и выход за границы буфера при некорректных аргументах;

• отказ в обслуживании через потребление ресурсов;

• отравление локального кеша.

Для проекта это обычные баги, а не CVE. Следовательно, процесс управления уязвимостями, который получает входящие данные только из фидов CVE, этот класс рисков не увидит. В документации PyTorch прямо сказано, что рекомендации из раздела Using PyTorch Securely не относятся к уязвимостям самого PyTorch.

Проблема не теоретическая. В феврале 2024 года JFrog обнаружила около сотни моделей, загруженных пользователями на Hugging Face и содержащих вредоносную нагрузку. Чаще всего это был pickle с методом __reduce_, который запускал код при загрузке; одна из моделей открывала reverse shell на жёстко заданный адрес. Разбор вредоносных моделей от JFrog.

В феврале 2025 года ReversingLabs описала технику nullifAI. В ней намеренно повреждённый формат pickle и архив 7z вместо ZIP обходили проверку Picklescan, хотя более терпимый десериализатор Python всё равно обрабатывал файл. Hugging Face удалила обнаруженные вредоносные модели менее чем за сутки, но это реакция после публикации и загрузки артефакта, а не гарантия, что опасный файл не попадёт в контур. Разбор nullifAI от ReversingLabs.

Positive Technologies также разбирала сканеры ML-моделей и способы обхода их проверок. Средства обнаружения помогают отсеивать часть опасных файлов, но решение о доверии к конкретной модели остаётся на стороне команды. Сканирование ML-моделей и обходы проверок.

Над этим слоем находится ещё один класс рисков без номера версии и CVE: prompt injection. OWASP в LLM01:2025 пишет, что из-за стохастической природы моделей пока не существует гарантированного способа полностью предотвратить такие атаки. RAG и дообучение модели снижают риск лишь частично.

В MITRE ATLAS на 11 августа 2026 года перечислены 16 тактик, 178 техник и 37 мер противодействия. Эти меры представляют собой организационные и архитектурные контроли: изоляцию инструментов, ограничения прав, проверку входных данных, фильтрацию вывода, журналирование и мониторинг.

Что показывают пять слоёв

В таблице семь строк: шесть CVE и один класс находок без CVE. GPU-рантайм и прошивки ускорителей показаны отдельно, как и инференс-движок и кластерный фреймворк.

LeftoverLocals с оценкой 6,5 Medium показывает обе проблемы календарного подхода. По баллу она выглядит задачей для обычного цикла обновлений. В SSVC она также не поднимается высоко: automatable = no, а статус эксплуатации — poc. Но на мультитенантной GPU-платформе это всё равно нарушение изоляции между клиентами.

Балл характеризует уязвимость, но не способ её устранения. Для веб-сервиса достаточно обновить зависимость, для GPU-кластера может понадобиться обновление драйверов и остановка узлов, а для некоторых компонентов патча не будет вовсе. Поэтому в дерево решений стоит добавить ещё один вопрос: есть ли для этой уязвимости применимое исправление и успеет ли команда внедрить его в установленный срок.

Вопросы дерева и таблица порогов

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

В SSVC уязвимость не получает итоговый приоритет в виде одного числа. Вместо этого команда последовательно отвечает на несколько вопросов и по их сочетанию выбирает действие.

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

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

Календарный SLA сразу назначает срок. SSVC сначала раскладывает ситуацию по нескольким признакам, а затем определяет, какой уровень реакции нужен. Срок становится следствием этого решения.

За последний год собрать данные для такого дерева стало проще. С 17 июня 2026 года NVD публикует SSVC-метаданные в API версии 2.0.3, используя данные CISA-ADP. Обновление охватило около 95% записей. NIST называет это Computed SSVC Score: запись показывает, по каким признакам определён её приоритет. NVD.

Значит, для перехода на дерево не нужен отдельный пайплайн обогащения. В большинстве случаев достаточно прочитать SSVC-поля из ответа NVD API вместе с CVSS и сведениями о затронутых версиях.

Определения точек решения и исходные файлы деревьев доступны в репозитории CERT/CC. Машиночитаемая версия дерева CISA находится в файле CISA-Coordinator.json.

Какое дерево нужно эксплуатанту

В SSVC несколько деревьев, потому что производитель, эксплуатант и координатор инцидентов отвечают на разные вопросы.

Платформенная команда действует как deployer: она решает, что делать с уязвимостью в собственной инфраструктуре. Для этого нужно знать, где работает компонент, кто может до него добраться, изолирован ли сервис, допустима ли остановка и сколько времени займёт обновление.

Дерево CISA рассчитано прежде всего на координатора. В нём не хватает части эксплуатационного контекста, зато данные для него публикуются в открытых источниках через Vulnrichment. Его можно взять за основу и дополнить признаками, которые важны для конкретной платформы. SSVC: роли и деревья решений.

Пять вопросов для платформы

До дерева нужно проверить, есть ли у находки CVE. Если записи нет, она не попадёт в NVD, KEV и автоматический SLA-бэклог. Так часто бывает с модельными файлами, небезопасными шаблонами, заимствованным кодом и другими AI-рисками.

После этого остаются пять вопросов.

Первые четыре вопроса взяты из BOD 26-04: есть ли CVE в KEV, доступен ли актив из публичной сети, можно ли автоматизировать эксплуатацию и какой технический эффект даёт атака. Значения automatable и technicalImpact уже есть в данных NVD API рядом с CVSS и описанием CVE.

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

Пятый вопрос добавлен для AI-платформы: существует ли применимое исправление. В исходном дереве CISA такой оси нет.

В таблице выше патч отсутствует для части случаев. В других он требует мажорного обновления фреймворка, обновления GPU-драйвера или прошивки ускорителя. Для весов модели патча нет в принципе. Если этого не учитывать, дерево может потребовать устранить CVE, для которой у команды нет готового способа исправления.

Этот принцип знаком и классическому AppSec. В описании VK Security Gate сказано, что калькулятор критичности учитывает не только CVSS, но и вероятность эксплуатации в ближайшие 30 дней, возможность автоматизировать атаку и вызов методов зависимости в коде приложения.

Возможность автоматизировать атаку соответствует оси automatable. Проверка вызовов помогает установить достижимость: библиотека может присутствовать в контейнерном образе, но приложение не обращается к уязвимому коду. Этот признак понадобится дальше, когда оценка CVE перейдёт к оценке конкретного развёртывания.

В этом дереве шесть исходов вместо четырёх у CISA. Два добавлены для ситуаций, которые не укладываются в стандартную схему: 

• митигация под подпись — когда дерево требует устранить уязвимость, но патча нет и команда вынуждена выбрать компенсирующие меры, зафиксировав принятое решение; 

• «вне очереди CVE» — для находок без номера, включая отравленные веса моделей, небезопасные форматы сериализации и уязвимые паттерны кода, для которых нет записи в базе.

Вопрос о применимом исправлении возникает перед каждым исходом, который требует устранения. Без него дерево повторит проблему календарного SLA: назначит срок для действия, которое невозможно выполнить. Для работы с деревом нужно уточнить ещё несколько понятий.

Что считать доверенным контуром. Это сеть, к которой нет доступа ни у пользователя платформы, ни у соседнего тенанта. Для мультитенантного оборудования ответ на четвёртый вопрос всегда «да»: сосед по ускорителю и есть внешняя сторона. Иначе ось воспроизведёт ситуацию, о которой Wiz предупреждает в разборе NVIDIAScape. Это правило относится к уязвимостям, которые эксплуатируются через соседство на ускорителе, а не ко всему, что на нём запущено.

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

Чью оценку брать при расхождении. Значения automatable и technicalImpact берутся из Vulnrichment — той же программы CISA, на полях которой построена директива. Это исключает ситуацию, когда NVD и CNA по-разному оценивают технический эффект одной записи.

Соблазн свести две метрики к одному композитному баллу возникает постоянно. FIRST выделяет такой подход в списке неправильных способов применения EPSS: «Применение некорректной статистики, также известное как «отмывание оценок». Не умножайте показатель EPSS на порядковую оценку, например CVSS, и не считайте, что результат даёт комбинированную оценку риска».

В FAQ по EPSS та же мысль сформулирована ещё короче: «Умножение EPSS на оценку CVSS не вычисляет произведение вероятности и тяжести и никогда не даёт осмысленного результата: получается число, которое <…> не имеет интерпретируемого значения». У метрик разные типы шкал: CVSS — порядковая оценка, полученная экспертным сравнением векторов, а EPSS — вероятность.

Откуда берутся пороги

EPSS принципиально не задаёт готовых уровней. В FAQ авторы прямо указывают, что EPSS «не определяет диапазоны оценок с метками вроде “критический”, “высокий” или “средний” <…> и намеренно оставляет это решение на усмотрение специалиста». Популярный порог в 10% в том же документе сопровождается оговоркой: он «не имеет особого статуса с точки зрения EPSS» и находится примерно на 95-м перцентиле распределения.

Порог команда назначает сама, исходя из своей месячной ёмкости.

Операционное руководство FIRST предлагает готовые соответствия между привычными категориями и вероятностными порогами. За последние 12 месяцев опубликовано порядка 61 тысячи записей CVE, чуть больше 10% из них получили категорию Critical. Если текущий порог действия — CVSS Critical, эквивалентный объём работ даст примерно 90-й перцентиль EPSS, то есть вероятность от 4%. Если порог — High и выше, а это верхние примерно 48% всех опубликованных записей, эквивалент составит около 0,8%. Порог в 50% исключает из очереди 98,8% всего опубликованного потока, а порог в 90% оставляет верхние 0,2%.

Полезно держать рядом и базовые ставки. В каталог KEV попадает около 0,5% опубликованных записей. Активность эксплуатации в 30-дневном окне наблюдается примерно у 2–3% записей. FIRST на разных страницах приводит для этого показателя разные значения; здесь использована формулировка из операционного руководства. Телеметрия партнёров EPSS преимущественно западная, доля российских сенсоров не раскрывается.

Расчёт ниже производный: это арифметика на основе опубликованных долей, а не измеренные значения.

Между первой и последней строкой — разница в 240 раз. Переход с High и выше на Critical сужает поток в 4,6 раза, а порог 50% — ещё в 8,8 раза относительно Critical. Одна и та же формулировка «мы исправляем критичные уязвимости» может описывать объёмы, различающиеся на два порядка.

Cyentia Institute и Kenna Security проверили это на выборке примерно из 300 организаций, преимущественно североамериканских. Типичная организация ежемесячно устраняет около 10% открытых уязвимостей независимо от размера инфраструктуры. Лог-лог-регрессия объясняет 93% разброса. По данным за 2022 год медианная месячная скорость устранения составляла 15,5%, а у компаний из нижнего квартиля — 6,6%. Применимость этих показателей к российским командам не подтверждена.

Возьмём в качестве ёмкости устранение 10% открытого бэклога в месяц. Тогда входящий поток уровня Critical удастся закрывать только при бэклоге не меньше 5 340 записей. Весь месячный ресурс уйдёт на Critical, а на остальные 89,5% потока ресурсов не останется. 61 тысяча — это глобальный поток публикаций, строка показывает предельный масштаб для отрасли.

Для набора из 100 записей с вероятностью эксплуатации 5% у каждой вероятность того, что хотя бы одна будет эксплуатирована в течение 30 дней, равна 1 - 0{,}95^{100} = 0{,}994. Ожидаемое число эксплуатируемых уязвимостей в таком наборе — пять. Низкая оценка отдельной записи не означает низкий риск всего набора. Формула и обе цифры взяты из операционного руководства FIRST.

Релизный гейт

Перед решением балл локализуют тремя проверками, которые FIRST называет Presence, Reachability и Consequence: присутствует ли уязвимый компонент в сборке, достижим ли уязвимый путь из вашего кода и к каким последствиям приведёт эксплуатация именно в вашей среде. Первая проверка исключает компоненты из образа, которые не используются. Вторая учитывает достижимость: поэтому AppSec-платформы обычно понижают критичность срабатываний на код в тестах и моках.

Исход дерева переводится в решение по релизу. Схема ниже — предлагаемая, её нужно адаптировать к собственному регламенту.

Сроки для трёх верхних исходов сверяют с приказом № 117 в системах, на которые он распространяется. Для остальных исходов сроки определяет внутренний регламент. Уровень критичности рассчитывают по методике от 30 июня 2025 года: запись с оценкой 9,3 по CVSS может получить другой уровень по формуле V.

Для второй строки таблицы есть опора и в американском комплаенсе. FedRAMP в уведомлении NTC-0014 от 16 июня 2026 года прямо разрешает провайдеру «применять меры митигации к уязвимости, пока она не перестанет быть автоматизируемой или доступной из интернета и поэтому не потребует полного устранения». Там же появилось правило VER-EVA-AIA — «считать уязвимость автоматизируемой»: провайдер обязан по умолчанию исходить из того, что эксплуатацию можно автоматизировать, пока не докажет обратное. Это требование относится к американскому комплаенсу, а российские сроки устанавливаются отдельно. Однако формулировку «митигация до состояния, при котором полное устранение не требуется» можно использовать для второй строки таблицы.

Для слоя весов модели дерево даёт исход, но не определяет метрику закрытия. В классическом VM критерий прост, Ozon формулирует его так: «если в свежих результатах сканирования уязвимость не обнаружена, то, скорее всего, уязвимость была устранена». Для файла модели этот критерий не подходит. Сканер артефактов и сканер уязвимостей проверяют разные свойства, а техника nullifAI показывает, что сканер артефактов тоже можно обойти.

То есть дерево даёт шесть исходов вместо одной даты. Порог назначает команда, а у популярного значения в 10% нет особого статуса. Митигация под подпись остаётся допустимым исходом: приказ № 117 рассматривает компенсирующие меры наряду с устранением.

Восемь записей CVE по дереву

В подборке восемь записей NVD, на которых выше разобраны разные слои. Цепочка Triton представлена одной записью, весов моделей в подборке нет по определению, поскольку для них не назначают CVE. Раскладка условная и приведена для примера: веб-API и инференс-эндпойнт доступны извне через балансировщик, GPU-рантайм и кластерный фреймворк работают во внутренней сети, а ускорители совместно используют несколько тенантов. В другой архитектуре ответы на четвёртый и пятый вопросы будут другими.

Значения первых трёх колонок взяты из поля ssvcV203 в ответе NVD API, если оно опубликовано. Ответы на четвёртый и пятый вопросы команда определяет по своей архитектуре. Значение poc при отсутствии наблюдаемой активности и записи в KEV считается ответом «нет» на первый вопрос. Если у записи нет поля ssvcV203, ответ определяют по её описанию и фиксируют в тикете вместе с обоснованием.

Колонка эксплуатации в ответах NVD API даёт для всех восьми записей один операционный вывод: подтверждённой активной эксплуатации нет ни у одной. В трёх случаях указано poc, в четырёх — none; у записи PyTorch нет ни строки в KEV, ни зафиксированной активности. Календарный SLA, основанный на балле, отправил бы шесть из восьми записей в категорию «критично, 24 часа», поскольку их оценка составляет 9,0 и выше. По дереву в эту категорию не попадает ни одна запись.

Соотношение «шесть против нуля» получилось только в этой витринной подборке. Записи специально выбраны так, чтобы показать случаи, где высокий балл не превращается в столь же срочное выполнимое действие. В реальном бэклоге большинство уязвимостей закрывается патчем в ближайшем релизе, поэтому расхождение будет не таким заметным. Оценить его для своей инфраструктуры поможет второй шаг из раздела о внедрении.

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

У LangChain в строке NVD указаны CVSS 9,8 и полный технический эффект, а в Vulnrichment — technicalImpact=partial. Правило «берём Vulnrichment» переводит запись из категории «24 часа» в плановый цикл. Такое решение принимают один раз в регламенте, после чего оно применяется ко всем записям с расхождением оценок.

Запись, ради которой введена пятая ось, действительно попадает в соответствующую ветку. vLLM со статусом WONTFIX уходит в «митигацию под подпись»: срок составляет семь дней, а релиз проходит. Дерево не требует закрыть патчем уязвимость, для которой проект не планирует выпускать исправление.

С LeftoverLocals ситуация сложнее. При оценке 6,5 запись получает исход «плановый апгрейд», который по календарю может выглядеть мягче, чем срок в 90 дней. Однако «плановый апгрейд» требует постоянно поддерживать компенсирующую меру: отказаться от совместного размещения тенантов на одном ускорителе. Срок в 90 дней, напротив, оставляет тенантов на одном ускорителе до его истечения.

Отравленный вес модели в таблицу не попадает. У него нет записи CVE, поэтому дерево направляет его в ветку «вне очереди CVE». Решение принимают по самому артефакту: учитывают формат сериализации, песочницу при загрузке и доверие к источнику.

Восемь записей разошлись по четырём исходам из шести. Срочных две, плановых пять, одна ушла в митигацию. А по баллу все восемь были бы в одной корзине.

Где дерево врёт

Самое слабое место дерева — слой весов моделей и всё, что находится рядом с ним.

Первые две оси опираются на сигнал об эксплуатации. Для нишевого ML-софта такого сигнала обычно нет. EPSS обучается на телеметрии партнёров-сенсоров, но для записей в vLLM, Triton, Ray или форматов сериализации весов такая телеметрия почти не встречается. FIRST формулирует это прямо: «Оценённая вероятность, близкая к нулю, — это прогноз, а не пробел в данных». Для платформенной команды различие между «предсказан нуль» и «данных нет» не меняет операционного решения.

В разобранной подборке из восьми записей NVD значение automatable=yes есть только у одной — у оспариваемой вендором CVE-2023-48022 в Ray. Но до этого узла она не доходит: ветка автоматизируемости открывается только при подтверждённой эксплуатации. Подтверждённой эксплуатации нет ни у одной из восьми записей, включая уязвимость со статусом WONTFIX и запись, для которой доступность из интернета нерелевантна по прямому указанию исследователей.

СайберОК в декабре 2025 года опубликовала проверку предсказательной силы EPSS на собственных данных и выложила репозиторий расчётов: «Давайте совместим оба ритуала и посмотрим, насколько лучше эксперты СайберОК могли бы контролировать поверхность атак, если бы слепо верили в магию EPSS. Спойлер: контролировали бы не очень». За 2025 год в KEV добавили 245 записей. По расчётам СайберОК, на снимке каталога от 29 декабря 2025 года значение EPSS нашлось для 203 из них — примерно для 83%. Полнота отбора при разных порогах составила 53,9%, 31,8% и 22,4%.

Вывод автора состоит из двух частей: EPSS для него — «отличный „ускоритель сортировки“, но плохой „турникет на входе“». О рассматриваемом случае он говорит ещё короче: «У них нет CVE → нет EPSS → нет магии».

Пятая ось вытаскивает записи, которые проваливаются и через календарный SLA, и через оценку вероятности: WONTFIX в продовом компоненте и прошивку ускорителя, которую в облаке обновляет не ваша команда. Находки без номера CVE отсекает нулевой вопрос — до пятой оси они не доходят. Без пятой оси дерево воспроизводит ту же слепую зону, что и SLA на основе балла, только быстрее.

V = Icvss × Iinfr × (Iat + Iimp)

Российский контур и расчёт ФСТЭК

Российский регулятор прошёл путь, похожий на CISA, и сделал это раньше.

30 июня 2025 года ФСТЭК утвердила новую методику оценки уровня критичности уязвимостей. Формула стала четырёхфакторной:

V = Icvss \times Iinfr \times (Iat + Iimp)

Множитель Iinfr складывается из типа компонента, его влияния на функционирование системы и доступности из интернета. Два новых множителя описывают возможность эксплуатации и последствия её успешного выполнения. Предыдущая методика от 28 октября 2022 года использовала произведение только двух показателей и таких множителей не включала.

В этой же методике Iat соответствует статусу эксплуатации в дереве, Iimp — техническому эффекту, а компонент периметра внутри Iinfr — доступности за пределами доверенного контура. Регулятор пришёл к тем же трём осям самостоятельно и почти на год раньше американской директивы: методика утверждена 30 июня 2025 года, а BOD 26-04 опубликована 10 июня 2026 года. Критический уровень по методике начинается при V > 8{,}0.

Значение Icvss методика берёт из БДУ — Банка данных угроз безопасности информации ФСТЭК — как оценку вендора по базовым метрикам CVSS 3.1. Если её нет, пункт 13 предписывает: «специалист самостоятельно определяет версию CVSS, по которой производится оценка». Для зарубежных ML-зависимостей это означает, что специалист сам выбирает версию шкалы для расчёта. В БДУ на 10 августа 2026 года содержится 92 434 уязвимости и 227 угроз, тогда как в мировой базе накоплено более 308 тысяч записей. БДУ охватывает примерно треть общего числа CVE.

Сроки устанавливает другой документ. Приказ ФСТЭК № 117 издан 11 апреля 2025 года и вступил в силу 1 марта 2026 года. Он заменил приказ № 17 от 2013 года, который устанавливал требования к защите информации в государственных информационных системах. Пункт 38 требует: «Устранение уязвимостей <…> или исключение возможности их использования за счёт применения компенсирующих мер должно проводиться». Для критического уровня установлен срок не более 24 часов, для высокого — не более 7 календарных дней. Для среднего и низкого уровней сроки определяет внутренний регламент.

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

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

Если сведений об уязвимости нет в БДУ, приказ отводит не более пяти рабочих дней на их направление во ФСТЭК.

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

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

Сводка по пяти системам

На входе в дерево используются KEV и поле ssvcV203. EPSS помогает назначить порог внутри выбранной корзины, а CVSS остаётся Icvss в российском расчёте.

Границы расчёта

Расчёт упирается в свойства доступных источников в трёх местах.

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

Записи без оценки NVD. Они вообще не входят в расчёт доли Critical. Все пять корзин занижены на неизвестную величину, и чем больше в инвентаре свежих AI-компонентов, тем сильнее это занижение.

География телеметрии. Доли популяции 48%, 10,5%, 1,2% и 0,2% рассчитаны по глобальной популяции записей и телеметрии партнёров EPSS. FIRST предупреждает об этом прямо: оценки отражают «глобальную наблюдаемую популяцию, а не вашу конкретную среду».

Три шага для внедрения

1. Разметить инвентарь по слоям из первой таблицы. Для каждого слоя определить, что означает закрыть уязвимость.

2. Прочитать поле ssvcV203 из ответа NVD API для текущего бэклога и посчитать фактическое распределение по исходам. Это выгрузка через API с пагинацией, на которую уйдёт примерно один день.

3. Назначить порог исходя из собственной месячной ёмкости: посчитать, сколько записей команда действительно закрывает за месяц, и выбрать порог, который даёт сопоставимый объём.

Как считали

Числа в таблице порогов производные. Входные данные — порядка 61 тысячи CVE за 12 месяцев и доля категории Critical чуть выше 10%. Оба значения, а также доли популяции 48%, 1,2% и 0,2% взяты из операционного руководства FIRST. Базовая ставка KEV около 0,5% приведена в FAQ по EPSS. Ёмкость «одна из десяти в месяц» взята из третьего тома Prioritization to Prediction Cyentia Institute и Kenna Security. Годовые объёмы равномерно делятся на 12.

Расчёт перестаёт работать при двух допущениях.

Поток CVE внутри года неравномерен. По данным NIST, число поданных записей в первом квартале 2026 года почти на треть превышало показатель того же квартала 2025 года. Поэтому равномерное деление на 12 занижает объём второй половины года.

Ёмкость «одна из десяти в месяц» измерена на классической ИТ-инфраструктуре. Для слоёв, где закрытие требует мажорного апгрейда или обновления прошивки ускорителя, она заведомо ниже.

Версии и даты

• Спецификация и руководство CVSS 4.0, Document Version 1.2.

• Директива BOD 26-04 от 10 июня 2026 года.

• Методика ФСТЭК от 30 июня 2025 года.

• Приказ № 117 от 11 апреля 2025 года, действует с 1 марта 2026 года.

• EPSS версии 5, схема SSVC в NVD API v2.0.3, данные БДУ на 10 августа 2026 года.

Определения точек принятия решения и машиночитаемое дерево опубликованы в репозитории CERT/CC. Поле ssvcV203 возвращает NVD API.

Что остаётся от срока

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

Изменился способ выполнения требования. Приказ № 117 позволяет уложиться в 24 часа компенсирующей мерой: регулятор прямо разделяет устранение уязвимости и соблюдение срока. По анализу выживаемости из Verizon DBIR 2026 на седьмой день открытыми остаются 60–70% уязвимостей из KEV. Выборка международная и охватывает более 13 тысяч организаций. Эта доля не зависит от года, размера или зрелости организации.

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

Заключение

AI-платформа не сводится к одному приложению и одному списку зависимостей. В ней одновременно работают веб-интерфейсы, API, инференс-сервисы, кластерные компоненты, GPU-рантайм, драйверы, прошивки, модели и артефакты, для которых CVE может вообще не существовать. Один балл CVSS и календарный SLA не различают эти слои, их доступность извне, реальную эксплуатацию, достижимость уязвимого пути и возможность установить исправление.

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

Такой подход не отменяет CVSS, EPSS, KEV и регуляторные сроки. CVSS остаётся оценкой свойств уязвимости и участвует в расчёте ФСТЭК. EPSS помогает управлять объёмом очереди внутри выбранного класса, но не заменяет решение о том, что включать в очередь. KEV и ssvcV203 дают входные сигналы для дерева. Приказ № 117 сохраняет обязательные сроки, одновременно разрешая уложиться в них компенсирующей мерой.

У дерева есть слепые зоны. Для нишевых ML-компонентов и весов моделей может не быть ни CVE, ни EPSS, ни телеметрии эксплуатации. Поэтому решение по таким находкам нужно принимать на уровне артефакта: проверять формат сериализации, происхождение весов, условия загрузки, изоляцию и возможность совместного размещения. Уязвимость без номера нельзя считать безопасной только потому, что она не попала в NVD, KEV или БДУ.

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