CISA заменила фиксированные сроки патчей на оценку риска: что это значит для уязвимостей нейросетей

CISA отменила сразу две прежние директивы, BOD 19-02 и BOD 22-01. Последняя с 2021 года задавала федеральным агентствам США единые календарные дедлайны для устранения уязвимостей из каталога KEV (Known Exploited Vulnerabilities, реестр уже эксплуатируемых уязвимостей). Новая директива BOD 26-04 вводит риск-ориентированный подход: срок исправления зависит не от абстрактной «критичности», а от четырёх конкретных параметров актива. Для российских организаций этот сдвиг тоже актуален: ФСТЭК в методическом документе от 30 июня 2025 года и приказе № 117 закрепил аналогичную логику, хотя и с собственной нормативной рамкой.

Какую задачу решает эта инструкция?

Если вы ведёте бэклог (очередь нерешённых задач) уязвимостей ИИ-платформы или обычной инфраструктуры, вы получите конкретное дерево решений: как оценить каждую уязвимость по четырём параметрам CISA и назначить реалистичный срок устранения вместо одинакового дедлайна для всего списка. Подход одинаково применим к платформе с GPU и моделями и к классической серверной инфраструктуре без них.

Что понадобится

• Доступ к каталогу CISA KEV и базе NVD (National Vulnerability Database, национальная база уязвимостей США) для проверки статуса каждой записи
• Текст директивы BOD 26-04 и таблица сроков, построенная на методологии SSVC (Stakeholder-Specific Vulnerability Categorization, система приоритизации уязвимостей по контексту организации)
• Реестр активов вашей платформы с разметкой по слоям: веб-API, ML-зависимости (библиотеки машинного обучения), GPU-рантайм (среда выполнения на видеокартах), инференс-движок (компонент, который выполняет запросы к модели), веса модели
• Опубликованные пороги FIRST для принятия решений
• Время: первичная разметка бэклога из 30-50 записей займёт 2-4 часа, дальше процесс ускоряется

Как перейти от календарного SLA к риск-ориентированному триажу?

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

2. Для каждой уязвимости ответьте на четыре вопроса CISA:

3. Доступен ли актив публично (из интернета)?
4. Есть ли уязвимость в каталоге KEV?
5. Можно ли автоматизировать её эксплуатацию?

6. К какому техническому эффекту приводит атака (утечка данных, выполнение кода, отказ в обслуживании)?

7. Определите срок по таблице BOD 26-04. В самом срочном случае (публичный доступ, запись в KEV, автоматизируемая атака, критический эффект) уязвимость нужно устранить за три дня и провести первичный forensic triage (экспресс-расследование инцидента). В наименее срочном случае исправление допускается при очередном плановом обновлении системы.

8. Проверьте статус записи в NVD. С апреля 2026 года NIST изменил порядок обработки: NVD в первую очередь обогащает записи из KEV, из ПО федеральных органов и из перечня критически важного ПО. Остальные записи могут не получить оценку CVSS от NIST, список затронутых продуктов и сопоставление с CPE (стандартный идентификатор продукта). Такие записи получают статус «Lowest Priority». Старый бэклог записей до 1 марта 2026 года переведён в статус «Not Scheduled». Если у вашей уязвимости один из этих статусов, выясняйте затронутые версии и компенсирующие меры самостоятельно.

9. Не полагайтесь на один CVSS. Базовая оценка CVSS (Common Vulnerability Scoring System, система оценки уязвимостей) измеряет техническую тяжесть, а не риск для конкретной системы. По данным NIST, с 2020 по 2025 год число поступающих CVE выросло на 263%, а за первый квартал 2026 года оказалось почти на треть выше, чем за тот же период годом ранее. NIST при этом обычно не добавляет собственную оценку, если CVSS уже опубликовал CNA (организация, назначающая идентификаторы уязвимостей). Одинаковый балл CVSS для двух уязвимостей в разных слоях ИИ-платформы не означает одинаковый приоритет, срок и способ обработки.

10. Учитывайте российские требования отдельно. Методический документ ФСТЭК от 30 июня 2025 года и приказ № 117 устанавливают собственные сроки устранения. Это отдельная нормативная рамка, а не калька с модели CISA или SSVC. Проверьте, под какие требования попадает ваша инфраструктура, и ведите два параллельных трека сроков, если это необходимо.

11. Получите пороги из данных FIRST. Опубликованные данные FIRST позволяют выстроить границы для принятия решений: при каких комбинациях параметров уязвимость попадает в категорию «немедленно», а при каких допускает плановое исправление.

12. Пересмотрите бэклог с новой разметкой. Пройдите текущий список открытых уязвимостей через дерево решений. Часть записей получит более жёсткие сроки, чем раньше (публично доступный API с уязвимостью из KEV). Часть, наоборот, перейдёт в плановый цикл (внутренний компонент без признаков эксплуатации).

Что делать с этим прямо сейчас, по ролям

Автору Дзена и контент-специалисту. Если вы используете ИИ-платформу для генерации контента, уточните у провайдера, как он управляет уязвимостями. Публично доступный API без регулярных обновлений безопасности создаёт риск утечки ваших промптов и данных.

Маркетологу и руководителю. Переход на риск-ориентированный триаж означает, что команда безопасности перестанет «тушить всё подряд» и начнёт работать по приоритетам. Это ускоряет релизы, но требует прозрачной карты активов. Если ваш продукт использует ИИ-компоненты, запросите у технической команды разметку по слоям.

DevSecOps-инженеру и тимлиду. Начните с карты слоёв и прогоните текущий бэклог через четыре вопроса CISA. Отдельно выделите записи, где NVD не даёт обогащённых данных: для них нужен собственный источник информации о затронутых версиях.

Руководителю ИБ в российской организации. Сопоставьте сроки из приказа ФСТЭК № 117 с результатами триажа по SSVC. Ведите два трека: один по российским нормативным требованиям, второй по фактическому риску. Где сроки расходятся, берите более жёсткий.

Директива BOD 26-04 не про то, чтобы медленнее закрывать дыры. Она про то, чтобы закрывать их в правильном порядке, с учётом того, где именно сидит проблема и насколько она доступна атакующему. Для ИИ-платформ, где «устранить» в каждом слое означает принципиально разное действие, это не абстрактное улучшение процесса, а единственный способ не захлебнуться в бэклоге, который растёт быстрее, чем NVD успевает его разметить.