БДУ ФСТЭК май 2026: agent hijacking и dependency confusion попали в реестр угроз

ФСТЭК в мае обновил Банк данных угроз безопасности информации. Обновления БДУ выходят регулярно, но это - не очередной патч с парой дополнительных CVE. В реестр попали два класса угроз, которые раньше существовали в практике, но не были формально закреплены как типовые векторы для российских информационных систем: атаки на LLM-агентов (agent hijacking) и dependency confusion применительно к отечественным репозиториям пакетов.

Для нас это прямой повод провести gap-анализ: что из новых угроз БДУ уже закрыто у наших клиентов, что закрыто частично, а где дыра. Записываем, что нашли.

Что именно добавили

БДУ теперь содержит два новых идентификатора угроз, которые относятся к нашей практике.

Первый - угроза перехвата управления LLM-агентом (формулировка в реестре звучит примерно как «угроза навязывания недоверенных инструкций автономному агенту через обрабатываемые данные»). Это та же механика, которую мы разбирали в марте при threat model хелпдеск-агента: вредоносные инструкции в пользовательском вводе или во внешних данных, которые агент обрабатывает как часть контекста. Теперь этому вектору есть идентификатор в БДУ, что значит: при аудите КИИ-объекта с LLM-агентами аудитор формально обязан его проверить.

Второй - угроза подмены зависимостей через неоднозначность имён пакетов в корпоративных репозиториях (dependency confusion). Здесь акцент именно на отечественных репозиториях: Nexus с зеркалами Гит-репозиториев отечественного ПО, GitFlic Packages, внутренние PyPI-зеркала. Вектор известен с 2021 года на международной сцене, но в БДУ он долго не попадал - видимо, регулятор считал его «западной» проблемой. Теперь нет: несколько публичных инцидентов с российскими внутренними реестрами в 2025-2026 годах изменили позицию.

Gap-анализ: что есть, чего нет

Мы прошлись по нескольким клиентам, у которых либо уже эксплуатируются LLM-агенты, либо есть внутренние репозитории зависимостей с отечественным ПО. Общая картина оказалась предсказуемой - и при этом не радостной.

По agent hijacking:

• OPA-guardrails или аналогичный policy layer - есть у двух клиентов из пяти. Это те, где мы сами выстраивали защиту агентов после прошлогодних инцидентов.
• Изоляция пользовательского ввода от системного промпта - сделана везде, но с разным качеством. У одного клиента «изоляция» - это просто префикс «User said:» перед вводом. Это не изоляция, это декорация.
• Логирование попыток tool-call с отклонением - есть у одного клиента из пяти. Остальные логируют только успешные вызовы.
• Документированный threat model агента - нет ни у кого, кроме проекта, который мы разбирали в марте.

По dependency confusion:

• Явный приоритет внутреннего репозитория над публичным в настройках pip/npm/maven - есть у трёх клиентов из четырёх, у которых мы смотрели конфиги. Но у одного из трёх настройка есть только в CI-пайплайне; на developer-машинах - нет, и разработчики ставят пакеты с дефолтными настройками.
• Проверка на подозрительные совпадения имён при добавлении новой зависимости - нет нигде. Это ручной процесс, который никто не делает систематически.
• SBOM с фиксацией источника каждого пакета (не просто имя и версия, но и откуда скачан) - есть у двух клиентов, которые уже перестроились под требования ФСТЭК к SBOM.

Что делаем

На основе gap-анализа формируем план по двум трекам.

Трек агентской безопасности. Для каждого клиента с LLM-агентом в продакшне - провести threat model по обновлённому чеклисту, который теперь явно включает новый идентификатор БДУ. Формат: рабочая сессия с командой, два-три часа, результат - список tool-call политик и приоритетный backlog по их реализации. Там, где агент использует сторонние инструменты (почта, JIRA, AD), первым делом идёт жёсткая фиксация допустимых параметров на уровне policy, а не надежда на то, что модель «сама не согласится» на вредоносный вызов.

Трек supply chain. Здесь работа разбивается на три шага: проверка конфигов менеджеров пакетов на всех окружениях (включая developer-машины, не только CI), проверка что внутренний репозиторий явно объявлен как единственный источник для внутренних имён пакетов, и добавление проверки источника в SBOM-пайплайн. По последнему пункту - у Syft есть поддержка метаданных об источнике в формате CycloneDX, это не требует смены инструмента, только конфигурирования.

Полного закрытия этих векторов за один спринт не выйдет - особенно там, где нет ни OPA, ни нормального threat model. Но приоритизировать работу теперь проще: БДУ ФСТЭК - это прямой аргумент в разговоре с CISO о том, почему это нужно делать не «когда-нибудь», а в ближайший квартал.

Если у вас в инфраструктуре есть LLM-агенты или внутренние репозитории с отечественным ПО - разобраться с gap-анализом под новые угрозы БДУ можно в рамках аудита.