В начале года мы уже писали на канале про инструмент seccomp-diff. И сейчас автор данного инструмента (широко известный в узких кругах Mark 'Antitree' Manning) сделал пост у себя в блоге под названием "Seccomp-Diff: Syscall Accountability Tool". И если кратко описать суть данной заметки, то его отлично описывает одна фраз из него: "Setting seccomp profiles is undeniably a great way to harden your container in principle, but in practice, it loads up two guns to shoot at your foot." =)

Действительно очень многие не понимают насколько вообще сложно сформировать полноценный custom seccomp profile и поддерживать его в актуальном состоянии для своего приложения. Что в конечном счете приводит к выстрелу себе в ногу ...

P.S. И напоминаем, что сегодня в 11:00 мы проведем вебинар "Предотвращение Runtime угроз в контейнерах и Kubernetes". Для всех участников мы подготовили очень полезный подарок ;)

В блоге разработчика CNI Calico вышла интересная статья "Calico Whisker & Staged Network Policies: Secure Kubernetes Workloads Without Downtime". Из данной статьи вы узнаете:

1) Про новый тип политик - Staged Network Policy, которые призваны облегчить тестирование сетевых политик, без поспешного использования enforce режима
2) Как компонент Whisker UI позволяет анализировать влияние сетевых политик на трафик
3) О режиме установке Calico for Policy, который позволяет в существующий кластер, на CNI отличном от Calico привнести чисто ее сетевые политики и работать с ними поверх чужого CNI!
4) Что перевод сетевой политики из такого отладочного режима в enforce это просто замена kind: StagedNetworkPolicy на kind: NetworkPolicy от Calico
5) О новом тестовом приложении yaobank (“yet-another-bank”), с которым можно развлекаться и проводить те или иные тесты

Всем хороших выходных!

Почти месяц назад прошел KubeCon + CloudNativeCon Japan 2025 ( все видео) и там было не так много докладов про безопасность, но один с очень говорящим названием всё-таки привлек наше внимание - "Your SBOM Is Lying To You – Let’s Make It Honest" (слайды, видео).

Помимо поднятия проблемы со SBOM (об этом пишут и говорят уже давно), в данном случае авторы также дают и рецепт решения, который по их мнению выглядит следующим образом: SBOMit = SBOM + in-toto (дополнительная аттестационная информация).

Так или иначе мы перешли от фазы "покажи из чего состоит твое ПО", к фазе "а не врешь ли мы мне?".

Сегодняшний пост будет просвещён проекту одного из наших читателей!

Cloud ​(IaC)​ Security (проект на github) это плагин для JetBrains IDEs.

Этот плагин помогает находить различные проблемы в dockerfile, Docker Compose и Kubernetes файлах с упором на проверки безопасности. Как говорит сам автор: "Kubernetes проверки сейчас в активной разработке, но покрыт уже Kubernetes Pod Security Standards Baseline и немного захватил Kubernetes NSA hardening guide."

Все проверки работают прямо в редакторе кода (самый край Shift Left Security) и сразу подсвечивают проблемы если имеются, также есть чуть более расширенная документация по подсвеченным проблемам и функционал по автоматическому исправлению проблем!

Проект бесплатный, разрабатывается уже около года и постоянно получает обновления!
Автор будет очень благодарен за обратную связь ;)

P.S. Если у вас есть проекты по безопасности контейнеров и Kubernetes, то не стесняйтесь нам о них писать и мы с большим удовольствием расскажем о них нашей аудитории. И возможно это привлечет большее внимание к проекту и вдохнет в него новую жизнь)

Давненько мы ничего не писали про наш любимый eBPF =)

И тут для многих не безызвестная организация National Security Agency (NSA) у себя на GitHub выложила проект SeaBee на языке Rust.

SeaBee это акроним для Security Enhanced Architecture for eBPF. Суть проекта обеспечить безопасность проектов, которые используют eBPF объекты для своей работы, то есть это такой механизм самозащиты (подобное есть и у классических антивирусов).

Про атаки на eBPF инструменты мы писали в наших других постах и с ними можно ознакомиться тут и тут.

P.S. Так как наш код Luntry тоже написан на Rust, то будет достаточно просто прикрутить в будущем это и к нам ;)

Сегодня хочется рассказать про один интересный инструмент, который, к сожалению, уже толком не поддерживается, но наталкивает и подсвечивает очень важный момент про уязвимости в OpenSource компонентах.

CVE Half-Day Watcher - это инструмент, который, используя информацию из National Vulnerability Database (NVD), идентифицирует недавно опубликованные CVE со ссылками на GitHub, которые еще не имеют выпущенных патчей! Тоесть инструмент демонстрирует возможность злоумышленников автоматизировано находить такие окна/разрывы и использовать для написания эксплоитов для реальных атак. В качестве примера авторы приводят ситуацию с нашумевшим Log4shell.

Так что в полку 1day, 0day пополнение - 0,5day =)

Кто внимательно смотрит наши выступления на конференциях про такое уже точно слышали - вот и публичный инструмент есть. И тот знает что в наше время защищаться только от известных уязвимостей (1day) уже недостаточно.

В своих предыдущих постах мы уже писали про уязвимости в NVIDIA Container Toolkit (1,2,3). А также в рамках своего блога делали большую статью "Ломаем ваши видеокарты: распаковка эксплойта для CVE-2024-0132 под NVIDIA Container Toolkit" на эту же тему.

И сейчас те же исследователи из Wiz опубликовали статью "NVIDIAScape - Critical NVIDIA AI Vulnerability: A Three-Line Container Escape in NVIDIA Container Toolkit (CVE-2025-23266)" с деталями своего эксплоита с Pwn2Own.

Эксплоит представляет из себя специально подготовленный контейнер, где dockerfile всего 3 строчки, с so библиотекой в виде payload. А проблема связана с обработкой переменных окружения в nvidia-ctk.

Всем, хороших выходных!

22 июля (вторник) в 14:00 наша команда Luntry в лице Дмитрия Евдокимова примет участие в вебинаре «Container Security: современное развитие».

В очень крутой компании коллег из Swordfish Security, ПСБ Банк мы обсудим насущные вопросы по контейнерной безопасности со стороны интегратора, разработчика средства защиты и заказчика.

Будет интересно и полезно:
- CISO и CIO
- Архитекторы и инженеры DevOps
- Руководители разработки приложений

Зарегистрироваться можно тут.

Начнем эту неделю с публикации всех материалов нашего вебинара «Предотвращение Runtime угроз в контейнерах и Kubernetes»! Из слайдов и выступления вы узнаете:
- чем отличается детектирование, реагирование и предотвращение
- что общего и разного у AppArmor, SeLinux, seccomp
- как NetworkPolicy относится к теме предотвращения
- что такое Linux Security Module (LSM) и при чем тут eBPF
- как Luntry помогает предотвращать Runtime угрозы.

Недавно из одного репоста довелось узнать про такую новую метрику как LEV (Likely Exploited Vulnerabilities, вероятно эксплуатируемые уязвимости). Если совсем кратко и не дублировать пост и текст самого документа NIST CSWP 41: "Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability", то она призвана повысить эффективность и экономичность усилий по устранению уязвимостей. При этом она не отменяет Exploit Prediction Scoring System (EPSS) и Known Exploited Vulnerabilities (KEV), а дополняет и использует первую метрику в процессе вычисления (даже инструмент уже есть).

И тут бы хотелось развенчать 3 утопичные мысли/плана:
1) закрывать абсолютно все уязвимости
2) закрывать только самое критичные уязвимости
3) закрывать только известные уязвимости

Реальность намного суровее и все сталкиваются с количественными и временными ограничениями, доступными ресурсами, кадрами, бюджетами, точностью инструментов, возможностями и мастерством атакующих, наличие 0day и 0,5day уязвимостей. Так или иначе любой из этих планов рушится на том или ином аспекте. А нам нужно систему делать безопасной (на деле, а не на бумаге).

Поэтому намного выгоднее вкладываться не в закрытие конкретной уязвимости (это лишь частный случай), а в закрытие целого класса, вектора через харденинги, митигейшены. У контейнеров в Kubernetes как мы недавно обсуждали таких механизмов предостаточно.

31 июля в рамках Kubernetes Community Day наша команда Luntry поучаствует в программе с докладом "Ретроспектива уязвимостей Kubernetes" от Сергея Канибора и в круглом столе на тему "Что в K8s можно закрыть security by design, а что наложенной безопасностью?" с Дмитрием Евдокимовым.

Продолжаем нести светлое, прекрасное, безопасное в этот Мир)

Если вам по каким либо причинам нужны все JSON схемы для всех версий объектов во всех версиях Kubernetes, то данный проект это все в себе и содержит!

Это может быть полезно, на пример, при написании своего собственного валидатора Kubernetes ресурсов ;) А такие инструменты как Kubeconform и Kubeval, как раз этот проект и используют у себя под капотом.

Единственное помните, что это позволяет проверить только соответствие OpenAPI Schema, но не гарантирует соответствие Server Side Field Validation! Ресурс на корректность в Kubernetes проверяется в 2-х местах.

Сегодня хочется с вами поделиться порталом KEVIntel, который содержит информацию из различных источников об уже эсплуатируемых уязвимостях.

В глаза, конечно, сразу бросается цифра 0,7%.
Это процент уязвимостей что были замечены в атаках за все время по отношению ко всем уязвимостям в базе CVE.

Обязательно рекомендуем посмотреть страничку с общей статистикой - там много интересного.

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

В пятницу как обычно хочется чего-то легко, непринуждённого и у нас есть сегодня такой контент.

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

Сегодняшний проект Neko это self-hosted виртуальный браузер (и не только), который запущен в Docker и использует WebRTC.

Все это к тому же о чем мы писали в контексте Virtual Desktop Infrastructure (VDI) систем!

P.S. Нет машины - нет поверхности атаки ;)

Исследователь Mark 'Antitree' Manning продолжает делиться с сообществом полезными инструментами в области Container Security. В наших прошлых постах (1, 2) мы рассказывали о его заметках и докладе, касательно использования Seccomp профилей в Kubernetes, однако автор решил пойти дальше и представил ресурс https://seccompare.com.

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

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

Более подробно о ресурсе автор рассказал в своей заметке – Introducing Seccompare.com: Seccomp Diffs For Containers.

Если вы по какой-либо причине задумывались и задавались вопросом как обстоят дела с постквантовой криптографией (PQC) в экосистеме Kubernetes, то статья "Post-Quantum Cryptography in Kubernetes" в официальном блоге Kubernetes как раз для вас ;)

В тексте рассказывается, что Kubernetes версии 1.33 уже по умолчанию поддерживает гибридный постквантовый обмен ключами (X25519MLKEM768) благодаря интеграции Go 1.24.

При этом важно понимать и подводные камни, такие как несоответствие версий Go, приводящее к деградации, и проблеме с размерами пакетов Client Hello.

Но PQC для цифровых подписей и иерархий сертификатов все еще находится на ранних стадиях разработки и внедрения общего использования.

1−2 августа 2025 в Перми в рамках конференции Ural Digital Weekend наша команда Luntry в лице Анатолия Карпенко представит доклад " Готовим сервис к безопасной работе в Kubernetes: рекомендации для разработчиков (и не только)".

В докладе рассмотрим нюансы подготовки приложения и окружения для работы в проде. На примерах разберем, что безопасность приложения начинается в IDE разработчика и не заканчивается передачей в отдел эксплуатации/DevOps/клиенту.

В 2023 году в рамках этой же конференции мы делали доклад “Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков”.

В общем продолжаем рассказывать для разработчиков про безопасность контейнеров в Kubernetes.

Сегодня хотим рассказать об инструменте fake-nvidia, который позволяет сэмулировать видеокарту и "пробросить" её в контейнер. Драйвер подгружается как модуль ядра, в результате чего мы получаем фейковую NVIDIA Tesla T4 прямо в контейнере.

Инструмент может быть полезен для воспроизведения, отладки (или поиске новых багов) в Nvidia Container Toolkit, например CVE-2024-0132 или свежей CVE-2025-23266. Не всегда есть возможность использовать дорогостоящие GPU (или их просто может не быть в наличии), однако такой инструмент без проблем решит эту проблему.

Если вы думаете, что тема совместимости образов контейнеров крутиться чисто вокруг Open Container Initiative (OCI), то это было так до недавнего времени, а сейчас еще появилась такая штука как Node Feature Discovery (NFD). Подробнее об этом можно узнать из статьи "Image Compatibility In Cloud Native Environments".

А если кратко, то данный проект призван помочь определить совместимость образа с конкретной конфигурацией хостовой ОС. Ведь Nodes в кластере могут отличаться друг от друга:
- Драйверами
- Библиотеками и специализированным ПО
- Фичами ядра

Цели данной спецификации совместимости:
- Определение структурированного способа выражения совместимости в манифестах образов OCI.
- Поддержка спецификации совместимости наряду с образами контейнеров в реестрах образов.
- Разрешение автоматической проверки совместимости перед планированием контейнеров.

В первую очередь это будет полезно для отраслей телекоммуникации, высокопроизводительных вычислений (HPC) и искусственного интеллекта (AI).

P.S. Сегодня можно c нашей командой пообщаться лично на Kubernetes Community Day или смотрите в онлайне ;)

Сегодня хотим продолжить освещать тематику eBPF, а именно расскажем про новый C2 агент – RingReaper, который работает полностью (ну почти) на вызовах io_uring и обходит классические EDR.

RingReaper заменяет такие вызовы, как read, write, recv, send, connect и другие, асинхронными операциями ввода-вывода (io_uring_prep_*), снижая риск перехватов и трассировки событий, которые обычно стандартизированы для продуктов безопасности.

Однако, некоторые функции RingReaper по-прежнему полагаются на традиционные системные вызовы, такие как чтение каталогов (opendir, readdir) или разрешение символических ссылок (readlink), поскольку io_uring пока не полностью поддерживает эти типы операций. Тем не менее, во время тестов автора эти вызовы не вызывали оповещений на тестируемых EDR именно потому, что они выходили за пределы контролируемых сетевых путей ввода-вывода.

Более подробно о своем инструменте и подходе автор рассказал в статье Red Team Tactics: Evading EDR on Linux with io_uring