Docker выпустил свой официальный набор skills для работы со своими решениями:
- Dockerfile & Build
- Docker Compose
- Docker Sandboxes
- Docker Agent
- Cross-Product

В общем если вы активно работаете с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться.

Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, какие доступы ему нужны.

Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime.

Но формат не ограничен агентами: им можно описывать потребности обычных сервисов!

По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру.

Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория.

P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года.

k8s-aibom - это оператор для сбора AI Bill of Materials в Kubernetes.

В AI-проектах уже недостаточно знать только версии контейнеров и пакетов. Важно понимать, какие AI-модели, фреймворки и компоненты реально используются в кластере, где они запущены и от чего зависят. Что и как он идентифицирует можно почитать тут.

Команда Google Cloud представила k8s-aibom — инструмент с открытым исходным кодом, который помогает автоматически собирать AIBOM.
Что инструмент дает:
- инвентаризацию AI-компонентов в кластере;
- понимание, какие модели и ML-фреймворки используются;
- повышение прозрачности AI-нагрузок;
- помощь в анализе рисков, уязвимостей и соответствия требованиям безопасности;
- более удобный контроль AI-софта в production-средах.

Со временем окружение быстро усложняется, а ручной учет компонентов становится практически невозможным. По сути, k8s-aibom — это попытка сделать для AI-компонентов то же, что SBOM (только в формате OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM)) делает для обычного программного обеспечения: дать структурированное представление о составе системы, чтобы защитить цепочку поставки (supply chain), борьба с shadow AI.

Исследователи Palo Alto Networks показали интересный сценарий атаки на SPIFFE/SPIRE в Kubernetes. Если атакующий получает root на ноде, он может подменить cgroup метаданные процесса и заставить SPIRE Agent выдать ему SVID другого workload.

В результате злоумышленник получает возможность использовать криптографическую идентичность скомпрометированного workload и обращаться к сервисам, доверяющим этой identity. При этом сама криптография SPIFFE не ломается — проблема в том, что после компрометации ноды рушится доверие к данным, на которых основана workload attestation.

Для проверки таких сценариев Palo Alto Networks выпустили открытый инструмент Spooffe, который автоматизирует тестирование подмены cgroup и получения чужих SVID. Хорошее напоминание о том, что SPIFFE/SPIRE не изолирует workload от полностью скомпрометированной ноды и root доступ нужно учитывать в threat model.

Сегодня в центре нашего внимания свежий вайтпейпер "Kubernetes Misconfigurations in the Wild: Taxonomy, Evolution, and Automated Repair with Large Language Models"

Где авторы исследуют два вопроса:
1) какие ошибки конфигурации чаще всего возникают на практике;
2) насколько хорошо LLM могут автоматически их исправлять.

Для этого они анализируют обсуждения разработчиков на Stack Overflow, Helm-чарты и результаты нескольких инструментов статического анализа.

По первому моменту они сделали таксономию из 5 основных разделов (ее можно видеть на скриншоте).

А по второму итоговый вывод в том, что LLM лучше использовать не как полностью автономную сущность, а как генератор исправления, работающий внутри конвейера с детерминированной валидацией. Тоесть гибрид LLM + schema/policy validation выглядит значительно надёжнее (98–99% корректных исправлений), чем “чистая” генерация исправлений, но до безопасного автопилота ещё далеко. Все смотрелось только в статике, итоговые исправления не запускались на практике, да и явно что в выборке по Stack Overflow и Helm-чартам далеко не все классы проблем присутствуют.

Сегодня мы также хотим поделиться с вами нашим большим внутренним праздником)

Наше решение Luntry получило сертификат ФСТЭК! Мы с 2021 года занимаемся безопасностью контейнеров и Kubernetes, и стараемся каждый год двигать нашу индустрию вперед (решением, этим каналом, нашей конференцией БеКон) и данное событие является еще одним таким шагом.

Это был трудный и долгий путь, где вся наша команда вложила много сил и времени.

Подробности можно почитать тут - а мы праздновать =)

P.S. Больше технических деталей в докладе «ФСТЭК и контейнеры: от заявки до сертификата» с БеКон 2026

NCC Group рассказали, как с помощью LLM-assisted pipeline нашли две уязвимости в etcd. В результате исследования обнаружили CVE-2026-59818 — обход проверки отозванных сертификатов на gRPC listener, и CVE-2026-73499 — обход RBAC в Watch API, позволяющий получать события по ключам за пределами выданных прав.

Интересно здесь не только сами уязвимости, но и подход к их поиску. LLM анализировал структурированный граф кода, сравнивал связанные execution paths и искал различия в применении security controls, после чего найденные гипотезы проверялись на реальных инстансах etcd.

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

В 2014 году Google явил миру оркестратор Kubernetes, чтобы управлять множеством контейнеров на множестве хостов, и который сегодня стал стандартом де-факто в индустрии.

И уже в 2026 году Google явил миру оркестратор ax (agent executor), чтобы управлять множеством автономных агентов в кластере Kubernetes. Станет ли он стандартом де-факто в индустрии покажет лишь время.

AX — это инфраструктура для запуска ИИ нагрузок и работает это дело по верх k8s и Agent Substrate. В его основе три сущности (YAML):
1) Task — задача в изолированной среде: образ контейнера, команда, переменные окружения, запросы и лимиты вычислительных ресурсов.
2) Workspace — рабочее окружение: Git-репозитории, MCP-серверы и пакеты навыков. Можно задать цель обычным языком, например «подготовить Go toolchain», и агент займётся настройкой окружения перед запуском основной команды.
3) Model — конфигурация провайдера и модели, параметры генерации и ссылки на Kubernetes Secrets с учётными данными.

Когда агентов становится много, недостаточно просто отправлять запросы к LLM. Нужно воспроизводимо готовить окружения, ограничивать ресурсы, изолировать выполнение и разбираться, почему конкретная задача зависла. AX пытается вынести эту инфраструктурную работу в отдельный слой.

Kubernetes продолжает переход на cgroup v2, а поддержка cgroup v1 постепенно уходит в прошлое. Начиная с Kubernetes 1.35, kubelet по умолчанию отказывается запускаться на узлах с cgroup v1, а в версии 1.38 поддержку старого механизма планируют удалить.

Переход на cgroup v2 даёт единую иерархию управления ресурсами, улучшает изоляцию и открывает доступ к новым возможностям, включая Memory QoS, метрики PSI и более точное управление ресурсами Pod. Кроме того, контроллер устройств в cgroup v2 реализован через cgroup BPF, что важно для инструментов на базе eBPF.

При миграции стоит проверить версии ядра Linux, containerd или CRI-O, настройки cgroup driver и совместимость инструментов мониторинга, которые напрямую читают файловую систему cgroups. Для новых кластеров рекомендуется сразу использовать cgroup v2, а для существующих — заранее спланировать миграцию. Об этом и не только довольно подробно рассказывают в заметке из официального блого Kubernetes – The Shift to cgroup v2 in Kubernetes: What You Need to Know.

Завтра в рамках отраслевого форума по информационной безопасности ITSEC 2026 наша команда представит 2 доклада:

1) Как не завалить SIEM в высоконагруженных кластерах Kubernetes

Кластера Kubernetes генерирует большой поток событий, что на уровне Runtime, что на уровне Kubernetes Audit Log. И если эту задачу решать в лоб, то либо складывается агент и хост вместе с ним, либо улетучивается вся лицензия на SIEM вместе с дисковым хранилищем. Как быть и что делать рассмотрим в данном докладе.

2) Защита AI-инфраструктур

Когда говорят про безопасность AI, чаще все обсуждают как безопасно его обучать или как с помощью него защищаться или защищаться от его действий. И в этой картине выпадает очень важный момент - момент инфраструктуры, где AI находится и функционирует. А эта среда очень специфичная со своими моделями угроз и нарушителей, требующая особого подхода. В рамках доклада мы и поговорим про специфику безопасности AI-инфраструктур.

Microsoft также не проходит мимо темы изоляции/ограничения AI-агентов.

Microsoft eXecution Container (MXC) — это SDK (Rust, .NET и Node.js) для запуска не доверенного кода в песочнице с явно заданными правами в Windows, Linux, macOS.

MXC позволяет приложению задать границы выполнения:
- Файлы: какие пути доступны только для чтения, какие — для записи, а какие запрещены.
- Сеть: ограничения исходящих соединений, настройки прокси и, в зависимости от backend, фильтрация хостов.
- Интерфейс: ограничения доступа к буферу обмена, дисплею и GU`I — там, где `backend это поддерживает.
- Выполнение: запуск команд и управление жизненным циклом изолированной среды.

И пусть вас не путает слово Container в названии (как нас сначала)! Это не имеет ничего общего с OCI образами и нашими любимыми контейнерами). Для каждой ОС тут свой backend изоляции:
- Windows — уровень BaseContainer backend ProcessContainer;
- macOS — Seatbelt;
- Linux — Bubblewrap.

Приложение передаёт команду, тип среды и политику доступа, а MXC проверяет запрос и запускает нагрузку через выбранный механизм изоляции.

В прошлом году мы уже рассказывали про Zeroday Cloud от WIZ. В этом году мероприятие повторяется.

Скоуп и расценки расширяются. Так например, за успешный эксплойт в gVisor или Firecracker у исследователей есть шанс получить $200,000, а в NGINX – $300,000.

Результаты будут представлены в лайве на Black Hat Europe 9-10 декабря. Выплаты в этом ивенте существенно выше, по сравнению с существующим расценками в багбаунти для этих продуктов.