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

23.09.2026 13:26:57 | Хабр

Хабы: Блог компании VK Tech, Искусственный интеллект, Информационная безопасность, DevOps, Облачные вычисления

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 и моделей: в таком случае меняется набор активов, но не логика приоритизации.

Подробнее

Читайте также