10 июня 2026 года CISA выпустила директиву BOD 26-04 и отменила плоские дедлайны BOD 22-01, которые с 2021 года задавали единые сроки закрытия уязвимостей. Теперь срок зависит от контекста конкретного актива. Для AI-платформы это меняет всё: слово «устранить» в разных слоях стека означает принципиально разные действия.

Почему плоский дедлайн не работал даже до отмены

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

Проблема в том, что CVSS описывает тяжесть уязвимости абстрактно, а не риск для конкретной системы. Уязвимость с CVSS 9.8 в изолированном сервисе без внешнего доступа и та же оценка в публично доступном API — это разные ситуации с разными реальными приоритетами.

Ситуацию усугубил апрель 2026 года. NIST изменил порядок работы NVD: с 15 апреля база в первую очередь обогащает только три группы записей — уязвимости из каталога KEV, ПО федеральных органов США и критически важное ПО по Executive Order 14028. Для остальных CVE NVD публикует запись, но может не добавлять CVSS, CPE и список затронутых продуктов. Такие записи получают статус Lowest Priority — not scheduled for immediate enrichment.

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

Что предлагает BOD 26-04 вместо дедлайна

Новая директива CISA строит приоритет на четырёх вопросах:

ВопросЧто оцениваем
Доступен ли актив публично?Внешний периметр или внутренняя сеть
Есть ли CVE в каталоге KEV?Подтверждённая эксплуатация в дикой природе
Можно ли автоматизировать атаку?Наличие публичного эксплойта, Metasploit-модуля
Каков технический эффект?RCE, повышение привилегий, утечка данных

Таблица сроков в BOD 26-04 построена с опорой на SSVC (Stakeholder-Specific Vulnerability Categorization). В наиболее срочном случае — устранение за три дня плюс первичный forensic triage. В наименее срочном — исправление при очередном плановом обновлении.

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

Почему AI-стек — самый неудобный объект для любого SLA

В обычном веб-приложении «устранить уязвимость» означает накатить патч. В AI-платформе этот глагол разворачивается по-разному в зависимости от слоя:

  • Веб-API и оркестрация — стандартный патч, часто без простоя.
  • ML-зависимости (PyTorch, TensorFlow, Hugging Face Transformers) — нередко мажорное обновление фреймворка с риском сломать воспроизводимость обучения.
  • GPU-рантайм и драйверы — обновление требует окна простоя; для прошивки GPU это может быть запланированный maintenance.
  • Инференс-движок (Triton, vLLM, TensorRT) — патч зависит от мейнтейнера; альтернатива — замена компонента.
  • Веса модели — патча в классическом смысле не существует; митигация может быть архитектурной или организационной.

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

Как построить дерево решений для CVE в AI-стеке

Ниже — пошаговая логика триажа, применимая к любой CVE в платформе.

Шаг 1. Определить слой и доступность актива.

bash
# Пример: проверить, слушает ли сервис на внешнем интерфейсе
ss -tlnp | grep <port>
# Или через nmap снаружи периметра
nmap -p <port> <external_ip>

Если актив недоступен публично — приоритет автоматически снижается, даже при высоком CVSS.

Шаг 2. Проверить наличие CVE в каталоге KEV.

bash
# Скачать актуальный каталог KEV в JSON
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-XXXX-XXXXX")'

Наличие в KEV — сигнал подтверждённой эксплуатации. Это повышает приоритет независимо от CVSS.

Шаг 3. Оценить автоматизируемость атаки.

Проверьте наличие публичного эксплойта в Exploit-DB, Metasploit или GitHub. Если эксплойт есть и требует минимальной настройки — атака считается автоматизируемой.

Шаг 4. Определить технический эффект и выбрать путь устранения.

plain
RCE в публичном API           → устранить за 3 дня (или изолировать)
Повышение привилегий в GPU-рантайме → запланировать maintenance-окно
Уязвимость в ML-зависимости без KEV → оценить breaking changes, включить в спринт
Проблема в весах модели        → архитектурная митигация, документировать риск

Шаг 5. Зафиксировать решение в тикете.

Для каждой CVE в бэклоге фиксируйте не только срок, но и обоснование: доступность актива, статус KEV, наличие эксплойта, выбранный путь устранения. Это нужно и для внутреннего аудита, и для требований ФСТЭК.

Где ломается риск-ориентированный триаж

NVD без CVSS. Свежая CVE может появиться в базе без оценки и без списка затронутых продуктов. Статус Not Scheduled означает, что NVD не планирует обрабатывать запись в ближайшее время. Команде придётся самостоятельно выяснять, какие версии затронуты, — через advisory мейнтейнера, GitHub Security Advisories или OSV.

ML-зависимости с транзитивными конфликтами. Обновление PyTorch ради одной CVE может потянуть за собой несовместимые версии CUDA, cuDNN и библиотек квантизации. Перед патчем стоит прогнать матрицу совместимости.

Инференс-движки с долгим циклом релизов. vLLM и Triton выпускают патчи не по расписанию. Если CVE критична, а патча нет — рассмотрите сетевую изоляцию компонента как временную меру.

Веса модели как поверхность атаки. Для уязвимостей, связанных с десериализацией весов (например, pickle-based форматы), патча не существует. Митигация — переход на безопасные форматы (SafeTensors) или валидация источника весов перед загрузкой.

Что попробовать дальше

  • Подключить OSV.dev как дополнительный источник для ML-зависимостей: база охватывает PyPI, Conda и другие экосистемы, где NVD часто запаздывает.
  • Настроить автоматическую проверку новых CVE по каталогу KEV через GitHub Actions или CI-пайплайн — это даст сигнал раньше, чем сканер обновит свои базы.
  • Изучить дерево решений SSVC на сайте FIRST: там опубликованы пороги и примеры разбора, которые можно адаптировать под свой стек.
  • Для команд под требованиями ФСТЭК — сверить внутренние SLA с приказом № 117 и методическим документом от 30 июня 2025 года: риск-ориентированная логика там закреплена отдельно от модели CISA.

FAQ

Отменяет ли BOD 26-04 обязательство быстро закрывать критические уязвимости?

Нет. Директива не предлагает устранять уязвимости медленнее. Меняется принцип: вместо единого дедлайна для всех срок определяется по контексту — доступность актива, наличие в KEV, автоматизируемость атаки и технический эффект. В наиболее срочном случае срок остаётся три дня.

Применима ли логика BOD 26-04 к российским компаниям?

Напрямую — нет, директива адресована федеральным агентствам США. Но риск-ориентированный подход закреплён в документах ФСТЭК: методическом документе от 30 июня 2025 года и приказе № 117. Логика триажа совпадает, нормативная база — отдельная.

Что делать, если CVE в NVD без CVSS и без списка затронутых версий?

Идти напрямую к источнику: advisory мейнтейнера пакета, GitHub Security Advisories, база OSV.dev. Статус Not Scheduled в NVD не означает, что уязвимость неопасна, — он означает только то, что NVD не планирует её обрабатывать в ближайшее время.

Как приоритизировать уязвимость в весах модели, если патча не существует?

Оценить вектор доступа: кто и как загружает веса, есть ли валидация источника. Как митигация — переход на формат SafeTensors вместо pickle-based сериализации и ограничение источников загрузки. Риск документируется и принимается явно, а не замалчивается.

Чем SSVC отличается от CVSS для целей триажа?

CVSS описывает абстрактную тяжесть уязвимости вне контекста. SSVC (Stakeholder-Specific Vulnerability Categorization) учитывает конкретную ситуацию: где работает компонент, кто может его атаковать и к каким последствиям приведёт успешная атака. FIRST публикует дерево решений и пороги — их можно адаптировать под свой стек без лицензионных ограничений.

Источники