CISA отменила календарные сроки устранения уязвимостей одной директивой

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 (Stakeholder-Specific Vulnerability Categorization, методика приоритизации уязвимостей под конкретного пользователя). В самом срочном случае исправить уязвимость нужно за три дня и провести первичный forensic triage (быстрый осмотр системы на следы компромисса); в самом несрочном — допускается при очередном плановом обновлении.

Почему ИИ-платформа выбивается из этой логики

Сложнее всего применить такой подход к ИИ-платформе: в её слоях слово «устранить» означает разные действия. В веб-API это обычно патч. В цепочке ML-зависимостей — мажорное обновление фреймворка. В GPU-рантайме — обновление драйвера или прошивки с окном простоя. В инференс-движке — либо ожидание решения от мейнтейнера, либо замена компонента. Для весов модели патча в привычном смысле может не быть вовсе.

Отсюда следует, что одинаковый CVSS (Common Vulnerability Scoring System, шкала оценки критичности уязвимостей) не означает одинаковый приоритет, срок и способ обработки. В материале восемь публичных CVE из типового ИИ-стека проходят через дерево решений: для каждой записи разбираются доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Также показано, как получить пороги для принятия решений из опубликованных данных FIRST.

Материал рассчитан на AppSec- и DevSecOps-инженеров, которые ведут бэклог уязвимостей платформы, и на тимлидов, у которых релиз зависит от открытых security-тикетов. Руководителям ИБ будет полезен отдельный раздел о требованиях ФСТЭК. Подход применим и к обычной инфраструктуре без GPU и моделей: меняется набор активов, но не логика приоритизации.