Триаж уязвимостей в AI: почему календарные дедлайны перестали работать
Внедрение риск-ориентированной модели устранения уязвимостей вместо фиксированного календарного SLA становится императивом для операторов ИИ-платформ. Стандартные оценки тяжести уязвимостей (CVSS) перестали быть надежным ориентиром из-за роста бэклога в базах данных и отсутствия оценки риска для специфических слоёв ИИ, таких как GPU-драйверы и весовые матрицы моделей.
# Триаж уязвимостей в AI-платформе: почему календарный SLA сломался и что ставить вместо него
10 июня 2026 года Агентство по кибербезопасности и инфраструктуре США (CISA) выпустило директиву BOD 26-04 «Приоритизация обновлений безопасности на основе риска». Этот документ формально отменяет действовавшую с 2021 года директиву BOD 22-01, которая диктовала федеральным агентствам США единые календарные сроки устранения уязвимостей из каталога Known Exploited Vulnerabilities (KEV). Вместо плоского дедлайна для всех, новая модель предлагает определять сроки на основе конкретной оценки риска актива. Для CISA приоритетность формируется на основе четырех факторов: публичной доступности актива, наличия уязвимости в списке KEV, возможности автоматизировать её эксплуатацию и потенциального технического эффекта атаки.
Для традиционной инфраструктуры это был бы логичный эволюционный шаг. Однако для AI-платформ переход на риск-ориентированный подход сопряжен с фундаментальными сложностями. В экосистеме искусственного интеллекта слово «устранить» в разных слоях означает принципиально разные действия: от простого патча веб-API до смены GPU-прошивки или полного ожидания решения от авторов модели. Одинаковый балл угрозы здесь не гарантирует одинаковый приоритет.
Конец эпохи автоматического расчёта
Долгое время индустрия опиралась на простую схему: оценка критичности CVSS диктовала срок исправления. Критические CVE требовали закрытия за дни, высокие — за недели, остальные ждали планового цикла. Эта схема обеспечивала формализм в отчётности и договорных SLA, но столкнулась с двумя системными проблемами.
С 15 апреля 2026 года Национальный реестр уязвимостей (NVD) пересмотрел приоритеты обработки. Из-за резкого роста потока CVE (выросший на 263% с 2020 года) NVD сосредоточился на обогащении записей, связанных с KEV и критически важным ПО. Для остальных уязвимостей база отходит от обязательного добавления оценок CVSS и сопоставления с CPE, присваивая им статус Lowest Priority. Это означает, что для новой и существующей уязвимости может просто отсутствовать официальная оценка тяжести, вынуждая команды проводить собственное расследование.
Кроме того, сама метрика CVSS, согласно руководствам FIRST для версии 4.0, измеряет *тяжесть* (severity), а не *риск*. Она описывает внутренние свойства дефекта, игнорируя наличие эксплойтов, доступность атаки и контекст эксплуатации. В CVSS 4.0 появилась группа метрик *Threat*, призванная скорректировать оценку, но данные остаются фрагментированными. Разногласия между оценками разных источников (например, расхождение на 4,9 балла для CVE-2024-8309 в LangChain) делают невозможным использование единственного числа как триггера для срочных действий.
Сложность слоёв ИИ: когда «обновить» невозможно
AI-платформа представляет собой стек из пяти ключевых слоёв, каждый из которых реагирует на угрозы по-своему. Попытка применить к ним линейный календарный дедлайн приводит к техническим противоречиям.
1. Веб-API и обвязка: Здесь действуют привычные правила. CVE-2024-8309 в LangChain демонстрирует проблему оценок, где разные эксперты дают разный балл (Critical 9.8 против Medium 4.9), что вносит путаницу в сроки. Однако патч здесь применим стандартным способом. 2. ML-зависимости: Уязвимость CVE-2025-32434 в PyTorch демонстрирует парадокс «патча как мажорного апгрейда». Для устранения риска необходимо перейти с версии 2.5.1 на 2.6.0. В ML-системах такое обновление часто требует проверки совместимости целого стека, повторного обучения моделей или валидации результатов, что занимает недели или месяцы. 3. GPU-рантайм и прошивки: Уязвимость NVIDIAScape (CVE-2025-23266) с оценкой 9.0 Critical позволяет злоумышленнику выйти из контейнера на хост. Исправление требует обновления драйверов или прошивок GPU, что неизбежно создаёт окно простоя для кластера. Временные меры, такие как отключение хуков совместимости CUDA, лишь замедляют проблему, а не решают её. 4. Инференс-движки: Для движков вроде vLLM ситуация может быть критичной. Уязвимость CVE-2025-30165 (оценка 8.0) связана с небезопасной десериализацией. Мейнтейнеры не планируют выпускать патч из-за масштаба необходимых изменений в коде, рекомендуя вместо этого изоляцию сервиса. Требование устранить уязвимость «в срок» в данном случае требует принятия компенсирующих мер, а не обновления. 5. Модельные веса: Этот слой наиболее уникален. Уязвимости здесь (например, интоксикация данных) могут не иметь традиционного патча. Исправление часто требует переобучения модели с нуля или отката к проверенной версии, что может быть невозможно при наличии новых зависимостей или отсутствии сохранённых весов.
Практический подход к триажу
Отказ от календарного SLA не означает снижение требований к безопасности. Напротив, он требует перехода от реактивной модели к аналитической. Вместо автоматического назначения дедлайна по CVSS, команды должны использовать дерево решений, учитывающее факторы CISA:
* Доступность: Публичен ли компонент или доступен только внутри приватной сети? * Эксплуатация: Существует ли работающий эксплойт и может ли атака быть автоматизирована? * Эффект: Приведёт ли атака к утечке данных, нарушению изоляции или просто логическому сбоям? * Реализуемость: Есть ли готовый патч? Требуется ли смена фреймворка или простои оборудования?
В российском контексте требования ФСТЭК (Приказ № 117) также предписывают риск-ориентированный подход, устанавливая предельные сроки для критических и высоких уязвимостей. Для AI-инфраструктуры это означает необходимость гибкости: если устранение требует смены прошивки GPU, срок должен пересматриваться, а не оставаться фиксированным.
Замена односторонней зависимости «CVSS → дедлайн» на комплексную оценку контекста — единственный способ поддерживать безопасность ИИ-платформ без блокирования инноваций или остановки вычислений. Инженерам необходимо научиться работать с неопределённостью данных NVD и самостоятельно оценивать реальную угрозу для конкретного актива, учитывая специфические ограничения стека искусственного интеллекта.