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

10 июня 2026 года CISA (Агентство по кибербезопасности и защите инфраструктуры США) выпустила директиву BOD 26-04. Она отменяет прежние BOD 19-02 и BOD 22-01 — те самые, что с 2021 года задавали жёсткие календарные сроки для устранения уязвимостей из каталога Known Exploited Vulnerabilities (KEV). Новая модель вместо плоского дедлайна предлагает определять срок по риску конкретного актива.

Для приоритизации CISA использует четыре фактора: публичный ли доступ к активу, есть ли уязвимость в KEV, можно ли автоматизировать эксплуатацию и к какому техническому эффекту приводит атака. Таблица сроков опирается на SSVC (Stakeholder-Specific Vulnerability Categorization). В самом срочном случае — устранить за три дня и провести первичный forensic triage, в самом лёгком — можно подождать очередного планового обновления системы.

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

В статье разбирают восемь публичных CVE из типового AI-стека, проводя каждую через дерево решений: доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Также показывают, как получить пороги для принятия решений из данных FIRST. Материал будет полезен AppSec- и DevSecOps-инженерам, тимлидам и руководителям ИБ (есть отдельный раздел про требования ФСТЭК). Подход подходит и для обычной инфраструктуры — просто меняется набор активов.