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

С 2021 года федеральные агентства США жили по простому правилу: уязвимость попала в каталог Known Exploited Vulnerabilities — устраняй в фиксированный срок, одинаковый для всех. 10 июня 2026 года CISA выпустила директиву BOD 26-04 Prioritizing Security Updates Based on Risk, которая отменяет BOD 19-02 и BOD 22-01. Календарный SLA уходит в прошлое: теперь срок исправления определяется риском конкретного актива, а не формальным признаком попадания в список. Для ИБ-команд это означает перестройку процессов триажа. Особенно болезненно она проходит в AI-платформах, где одинаковый CVSS совсем не означает одинаковый приоритет, срок и способ обработки.

Подробности

Новая модель CISA опирается на четыре обстоятельства: доступен ли актив публично, есть ли уязвимость в KEV, можно ли автоматизировать её эксплуатацию и к какому техническому эффекту приводит атака. Таблица сроков, как указывает сама CISA, построена с опорой на SSVC (Stakeholder-Specific Vulnerability Categorization). В наиболее срочном случае уязвимость нужно устранить в течение трёх дней и провести первичный forensic triage; в наименее срочном исправление допускается при очередном плановом обновлении системы. Главная сложность — сам термин «устранить». В AI-платформе он означает принципиально разные действия в зависимости от слоя. В веб-API это может быть обычный патч. В цепочке ML-зависимостей — мажорное обновление фреймворка с риском сломать совместимость. В GPU-рантайме — обновление драйвера или прошивки с окном простоя. В инференс-движке — либо ожидание решения от мейнтейнера, либо замена компонента. А для весов модели патча в привычном смысле может не быть вовсе. Именно поэтому одинаковый CVSS не равен одинаковому приоритету. В исходном разборе восемь публичных CVE из типового AI-стека проходят через дерево решений: для каждой записи анализируются доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Отдельно показано, как получить пороги для принятия решений из опубликованных данных FIRST. Материал ориентирован на AppSec- и DevSecOps-инженеров, ведущих бэклог уязвимостей платформы, и на тимлидов, у которых релиз зависит от открытых security-тикетов. Руководителям ИБ будет полезен раздел о требованиях ФСТЭК.

Что делать

Пересмотрите внутренний SLA: привяжите сроки не к факту наличия CVE, а к риск-профилю актива по логике, близкой к SSVC. Определите для каждого слоя AI-платформы, что конкретно означает «устранение»: патч, мажорное обновление зависимости, обновление драйвера или замена компонента. Для слоёв, где исправление недоступно, заранее пропишите компенсирующие меры — сетевую изоляцию, ограничение доступа, мониторинг эксплуатации. Отдельно проверьте соответствие процессов требованиям ФСТЭК, если они применимы к вашей организации. Итог: календарный SLA уступил место риск-ориентированному подходу, и для AI-платформ это не формальность, а необходимость — без понимания слоёв и путей устранения приоритизация превращается в формальный тикет-менеджмент.

Источник: Хабр — Информационная безопасность