Открытая LLM Mythos: чеклист кибербезопасности для CSO и CIO в 2026

Андрей Отинов -

Что именно изменилось?

По сообщениям отраслевых аналитиков, крупные разработчики собираются выпустить открытую версию модели уровня Mythos в течение ближайших 3‑6 месяцев The Guardian, 2026. Mythos — это крупномасштабный языковой генератор, способный писать, отлаживать и эксплуатировать код на уровне старших инженеров. В открытом виде модель станет доступна всем — от исследователей до киберпреступников.

Источник: AI Cybersecurity After Mythos: The Jagged Frontier

Параллельно наблюдается резкий рост атак в криптовалютном секторе: за последние полгода количество взломов выросло примерно на 100 % исходный пост. Эксперты связывают рост с растущей доступностью автоматизированных эксплойтов, и по их прогнозам аналогичная тенденция распространится на корпоративные сети, финансовые сервисы и инфраструктуру государственных учреждений Uptycs, 2026.

Как это влияет на затраты, время и риски бизнеса?

Что меняется Почему важно бизнесу Что проверить
Открытый доступ к высококвалифицированному коду‑генератору Возможность автоматизированного поиска уязвимостей в ваших продуктах без привлечения дорогих внешних консультантов. Потенциальный рост количества успешных атак — приоритетный риск для репутации и финансов. Наличие систем контроля исходного кода (SAST/DAST) и их готовность к масштабным сканированиям.
Увеличение количества «бот‑хакеров» Привлечение недорогих сервисов‑посредников (например, платных API‑провайдеров) ускорит подготовку эксплойтов до уровня «человек‑день». Сокращается окно реагирования. Среднее время обнаружения (MTTD) и реагирования (MTTR) на инциденты в текущих процессах.
Неравномерный доступ к модели в разных юрисдикциях В России могут возникнуть ограничения на импорт сторонних API, что заставит злоумышленников ставить локальные копии. Это повышает риск «домашних» атак, где защита менее формализована. Возможность размещения собственного изолированного экземпляра модели (on‑prem) и наличие политик изоляции.
Рост стоимости реагирования Требуется расширять команды Red/Blue‑Team, проводить частые учения и обновлять правила обнаружения. Дополнительные расходы могут выйти за рамки текущих бюджетов. Планируемый бюджет на кибербезопасность — соответствует ли он росту нагрузки, вызванному новыми угрозами?

Что необходимо проверить перед реакцией?

  1. Инвентаризация критически важных активов – список приложений, API и данных, где ошибка в коде может привести к финансовым потерям.
  2. Состояние текущих средств обнаружения – актуальность сигнатур, покрытие AI‑генерируемых атак в SIEM / EDR.
  3. Политика доступа к внешним моделям – есть ли ограничения на скачивание и запуск открытых LLM, где хранятся их артефакты.
  4. Контроль поставщиков – проверка, используют ли ваши партнеры открытые модели и как они их интегрируют в свои продукты.
  5. Готовность к быстрой регулятивной реакции – наличие процедур для закрытия уязвимостей в течение 24 ч (согласно рекомендациям NIST 2022, адаптированным к AI‑угрозам).

Где могут возникнуть сбои или неопределённости?

  • Недостаток опыта реагирования: большинство CSO/CIO знакомы с традиционными эксплойтами, но не с автоматизированными скриптами, генерируемыми LLM. Отсутствие квалифицированных аналитиков приводит к ложным срабатываниям и перегрузке SOC.
  • Ошибки в настройке собственных AI‑ассистентов: если ваша компания уже использует генеративные модели для разработки, их конфигурация может стать «двойным режиссером» – помогать, но и раскрывать детали кода внешним злоумышленникам.
  • Юридические ограничения: в России могут возникнуть ограничения на импорт открытых моделей, а их локальное развёртывание потребует лицензий, соответствия ФСТЭК. Неправильная юридическая оценка увеличит время реагирования.
  • Сбои в цепочке поставок: если модель будет распространяться через публичные репозитории, злоумышленники могут внедрять «троянские» версии. Без проверок подписи и хэшей можно получить поддельный инструмент.

Что сделать уже на этой неделе (чеклист)

  • [ ] Составить таблицу топ‑5 бизнес‑приложений, где любой новый уязвимый кусок кода может привести к финансовой потере > 10 млн ₽.
  • [ ] Проверить, какие правила IDS/IPS сейчас блокируют запросы к «open‑ai‑style» endpoint‑ам; добавить базовые сигнатуры, найденные в отчётах Eye Security, 2026.
  • [ ] Создать «модель‑белый список» для внешних LLM: какие версии можно запускать в изолированных контейнерах, а какие – запрещены.
  • [ ] Организовать 2‑часовое внутреннее обучение для аналитиков SOC о типичных запросах, генерируемых LLM‑моделью (например, «write a buffer‑overflow exploit for OpenSSL 1.1.1»).
  • [ ] Заказать у юридического отдела предварительный аудит рисков использования открытых AI‑моделей в рамках текущих российских нормативов.

Источники

Темы журнала

Что почитать дальше