# Календарный SLA по уязвимостям умер: как перестроить триаж в AI-стеке
Каноническая страница: https://plainews.ru/posts/triage-uyazvimostey-ai-platformy-ssvc
Опубликовано: 2026-09-24T11:01:46.661Z

CISA отменила плоские SLA по уязвимостям. Как перейти на риск-ориентированный триаж в AI-стеке: GPU, ML-зависимости, инференс и требования ФСТЭК.
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) или валидация источника весов перед загрузкой.

> **Важно.** Статус записи в NVD показывает очерёдность обработки, а не реальную опасность уязвимости для вашей инфраструктуры. Не используйте отсутствие CVSS как аргумент для снижения приоритета.

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

- Подключить 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 публикует дерево решений и пороги — их можно адаптировать под свой стек без лицензионных ограничений.

## Источники

- Habr AI: Триаж уязвимостей в AI-платформе: почему календарный SLA сломался и что ставить вместо него