Agentic AI Threat Landscape

Всем привет!

В статье (~ 25 минут на прочтение) можно найти информацию о способах атак и защиты на агентские AI.

Начинается всё с погружения в контекст – как именно работают AI агенты, и какие могут быть фундаментальные проблемы ИБ с ними связанные.

Далее материал структурирован по разделам:
🍭 Indirect Prompt Injection
🍭 Tool Poisoning
🍭 Memory Poisoning
🍭 Data Exfiltration, Code Execution и 🍭 Expanding Attack Toolkit
🍭 Persistence, Backdoors и не только

Для каждого раздела приводится краткое описание проблематики с диаграммами и примерами, иллюстрирующими технику атаки.

В завершении описаны (очень кратко) описаны способы защиты.

Итого – неплохой обзорный материал для лучшего погружения в тему. Рекомендуем!

Защита Kubernetes с Kyverno и KubeArmor

Всем привет!

В статье Автор рассматривает способы обеспечения безопасности кластера Kubernetes в двух «временных точках».

Первая – контроль того, что запускается. Для этого он предлагает использовать Kyverno. Задача – сократить вероятность того, что будет создано «нечто», что противоречит требованиям ИБ.

Однако, мир не идеален. На все случаи жизни политики не напишешь. Поэтому важна и вторая «временная точка» – защита того, что уже запущено. Для этого Автор предлагает использовать KubeArmor.

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

Далее Автор рассказывает о том, как установить решения и настроить первичные (базовые) политики, чтобы лучше разобраться в том, как это работает.

В завершении – набор общих советов о том, на что стоит обращать внимание для защиты кластера.

Статья вряд ли заинтересует «бывалых», но может быть полезна для тех, кто только начинает разбираться в безопасности Kubernetes.

sk8r: Kubernetes Dashboard Clone!

Всем привет!

Небольшой пятничный пост. Да! sk8r – еще один open-source дашборд для работы с кластерами Kubernetes.

Он может:
🍭 Создавать, просматривать, изменять Kubernetes-ресурсы
🍭 Отображать логи pod’ов в режиме реального времени
🍭 Отображать информацию о метриках за счет интеграции с Prometheus
🍭 Получать доступ к терминалу pod’a

Да, ничего сверхъестественного.

С другой стороны – всё очень лаконично и просто, ничего лишнего для получения «первичной информации» о том, что происходит в кластере.

А каким инструментом пользуетесь вы?

Container Exploration Kit

Всем привет!

Бывают случаи, когда нужно «посмотреть» что-то внутри контейнера и при этом не хочется (или не представляется возможным) его запускать, делать exec и просматривать содержимое.

Одним из возможных решений может оказаться Dive. Из нюансов – он хорош для получения информации о содержании и структуре, анализа слове и изменений, но… он все равно запускает контейнер.

Если надо нечто более простое и с меньшим функционалом, то cek – Container Exploration Kit – может вам пригодиться.

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

Из возможностей можно отметить:
🍭 Просмотр файлов в образе, директории, по определенным шаблонам, слоям
🍭 Чтение содержимого файлов
🍭 Получать перечень доступных tags для контейнера
🍭 Экспортировать образы контейнеров в *.tar-архивы
🍭 Отображать дерево директорий внутри контейнера

И все это в небольшом исполняемом файле. Очень удобно, если надо быстро что-то получить из образа.

Больше подробностей можно прочесть в GitHub-репозитории проекта.

Использование AI агентов для исследования CVE

Всем привет!

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

За основу взят Google’s Agent Development Kit (ADK), который «координирует» весь процесс, состоящий из 4-х шагов.

Шаги представляют из себя:
🍭 Deep Research. Получение максимального количества информации о CVE
🍭 Technology Reconnaissance. Определение технологий, которые могут быть «подвержены» CVE
🍭 Actor-critic Template Generation. Формирование Nuclei Template на базе собранной информации
🍭 Exploitation Analysis. Анализ векторов атак, возможных техник, ущерба и т.д.

На выходе, в идеале, получается Nuclei Template, который можно использовать для проверки того, подвержен ли сервис X уязвимости Y.

Для каждого этапа вышеописанного процесса используются различные модели.

Т.е., в зависимости от решаемой задачи, выбирается «оптимальный инструмент».

Больше подробностей, включая краткое описание того, как это используется, можно найти в статье.

Multi-Cluster Scaling: опыт Kedify

Всем привет!

Зачастую, кластер Kubernetes существует в единственном числе недолгое время. Рано или поздно кластеров становится несколько.

Например, из-за технических (сокращение задержки), организационных (отдельный кластер под определённую команду) или регуляторных (сокращение «области действия» требований) причин.

И тут начинается самое весёлое: всё, что было сделано для того «первого» кластера надо отмасштабировать на остальные. И не только отмасштабировать, но и централизованно управлять всем этим, что приводит к «двойной работе».

В статье от Kedify описан подход, который использовала команда, чтобы решить эту задачу. Если кратко, то всё просто: создание единого «мозга», который всем управляет. Но дьявол в деталях!

Ребята используют один KEDA-кластер, который анализирует метрики и взаимодействует с Member-кластерами через kube-apiserver.

Member-кластеры, в свою очередь, создают необходимые нагрузки и всё это с минимально-необходимыми правами.

Для того, чтобы KEDA-кластер мог управлять Member-кластерами команда сделала свой CRD - DistributedScaledObject.

Он определяет, на каких Member-кластерах можно создавать ресурсы, что делать в случае их недоступности, как собирать информацию о «здоровье» и т.д.

В итоге получается конструкция, которая позволяет управлять несколькими кластерами Kubernetes «на масштабе» и может работать в случае недоступности некоторых Member-кластеров.

Больше информации, как обычно, можно найти в статье.

Docker Time Machine

Пятница! Самое время для совершения путешествий во времени! И Docker Time Machine (DTM) может в этом помочь.

Эта утилита автоматизирует процесс анализа различных версий (тэгов) одного и того же образа контейнера.

Может работать как с реестром (скачивается только meta-информация об образе), так и с git-репозиторием (для каждого commit создается образ и осуществляется сравнение).

DTM позволяет:
🍭 Осуществлять «послойный» анализ образов
🍭 Идентифицировать изменения в размере образов
🍭 Найти самый «толстый» образ из доступных
🍭 Найти самый «худой» образ из доступных

Результаты работы утилиты «упаковываются» в JSON, CSV, MD или в лаконичный HTML, наглядно отображающий то, как менялся образ.

Подробности о возможностях Docker Time Machine, об использовании и примеры результатов можно найти в GitHub-репозитории проекта.

K8sQuest: интерактивное обучение по Kubernetes

Всем привет!

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

K8sQuest предоставляет интерактивный интерфейс (терминал), подсказки, пошаговые инструкции о том, как проходить задания, возможность «сброса» уровней, если застряли и, конечно же, achievements! Куда без них!

Задания разделены по «мирам»:
🍭 Core Kubernetes Basics
🍭 Deployments & Scaling
🍭 Networking & Services
🍭 Storage & Stateful Apps
🍭 Security & Production Ops

Каждый мир имеет свой набор заданий, количество получаемого «опыта» и уровень сложности. Всего заданий – 50 штук.

Подробнее о заданиях можно и о том, что вас ожидает можно прочесть в GitHub-репозитории проекта.

И, что самое классное – устанавливается всё локально, не нужно никаких «облаков»!

Superuser Gateway: опыт Uber

Всем привет!

Управление привилегированным доступом – задача крайне важная. Одна ошибка и ты ошибся. При этом, результаты могут быть достаточно «неприятные».

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

Но у такого процесса много недостатков, как минимум, связанных с ошибками человеческого фактора.

Чтобы сократить вероятность того, что «что-то пойдет не так», команда Uber сделала Superuser Gateway.

С его использованием процесс стал иным:
🍭 Инженер запрашивает выполнение команды с использованием CLI
🍭 Вместо «прямого выполнения» создается PR в определённом репозитории
🍭 Осуществляются проверки, включая review со стороны другого инженера
🍭 Как только PR согласован, он выполняется с использованием средств автоматизации

Superuser Gateway состоит из нескольких компонентов: CLI-утилиты, git-репозитория, набора CI-jobs и сервиса, который имеет «право» выполнять команды.

Подробнее о том, как устроен сервис, какие проверки реализованы и как это «выглядит» можно узнать в статье.

Gateway API Benchmarks

Всем привет!

Вопрос замены Ingress NGINX на нечто иное становится важнее день ото дня. Недавно был выпущен его финальный релиз, а в скором времени проект перейдёт в статус Archive.

Одной из возможных замен является Gateway API. Но какую реализацию выбрать?

Возможно, что вот это сравнение сможет вам помочь.

В нем Авторы сравнивают реализации:
🍭 Agentgateway
🍭 Envoy Gateway
🍭 Istio
🍭 Kong
🍭 Traefik
🍭 Nginx (да, он все еще попал в сравнение)

Помимо общих результатов сравнения, для каждого из «участников» приводятся некоторые нюансы, на которые стоит обратить внимание.

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

P.S. По прямой ссылке доступна первая версия. К результатам второй версии можно попасть через ссылку, доступную в репозитории.

SecScore: оценка безопасности сборки

Всем привет!

SecScore – open-source утилита, которая позволяет описать правила (не) прохождения сборки, основываясь на критериях.

Да, по факту это некий аналог Security/Quality Gate.

Работает это примерно так:
🍭 Вы определяется «оценку», по достижении которой сборка считается «неудачной» (например, 100)
🍭 Для разных уровней критичности определяются свои веса (например, High – 20, Medium – 7 и т.д.)
🍭 Кроме этого, можно указать «Hard Fails» - т.е. нечто, чего попросту не должно быть. Да, даже если «оценка» не достигнута
🍭 Дополнительно можно указать условия. Например, реагировать только на новые ИБ-дефекты

По результатам работы, в том числе, создается комментарий в PR. В нём отображается информация о «принятом решении» и причины, на основании которых оно было сделано.

Больше подробностей о SecScore можно прочесть в GitHub-репозитории проекта.

Безопасное использование пакетных менеджеров

Всем привет!

В марте 2026 года ENISA выпустила руководство «Technical Advisory for Secure Use of Package Managers», (~ 28 страниц), которое можно найти в приложении.

В нём приводятся практики, позволяющие повысить уровень информационной безопасности при работе с пакетными менеджерами.

Материал структурирован по разделам:
🍭 Solution architecture and data flows. Общее описание принципов работы пакетных менеджеров
🍭 Security risks in package consumption. Основная проблематика, с которой можно столкнуться (уязвимости, атаки на цепочку поставок и т.д.)
🍭 Best practices – secure package consumption. Рекомендации по безопасному использованию пакетных менеджеров

Материал описывает общие рекомендации (т.е. отдельных рекомендаций для «конкретного» пакетного менеджера нет).

Всё довольно лаконично, понятно и достаточно подробно описано для того, чтобы реализовать это у себя.

Останется только понять «как именно» это можно сделать. Но здесь уникального ответа нет – каждый найдет свой собственный путь.

Trajan: анализ безопасности CI/CD

Всем привет!

Trajan – open-source утилита от Praetorian, которая позволяет анализировать настройки CI/CD и идентифицировать в них ИБ-дефекты.

«Из коробки» доступна следующая функциональность:
🍭 32 плагина для идентификации небезопасных настроек
🍭 24 плагина для идентификации атак
🍭 Несколько «режимов работы»: enumerate, scan и attack
🍭 Наличие графического web-интерфейса

На текущий момент поддерживается GitHub Actions, GitLab CI, Azure DevOps и Jenkins.

Количество плагинов для идентификации небезопасных настроек и атак варьируется в зависимости от рассматриваемой CI-системы.

Больше подробностей про проект можно найти в GitHub-репозитории или вот в этой статье от Авторов Trajan.

Поиск вредоносных contributors в open-source: опыт DataDog

Всем привет!

DataDog – компания, которая много сил вкладывает в развитие open-source. Включая собственные разработки, которые ребята дают миру.

Когда «идешь в public» - будь готов к тому, что тебя могут «исследовать» и пытаться атаковать. DataDog – не исключение.

Supply chain атаки особенно популярны в наше время: от «воздействия» на название PR до различного вида инъекций, в результате чего может быть украдена информация, подменён артефакт и т.д.

Недавно мы писали о BewAIre – наработке Компании, которая позволяет определить, является ли PR вредоносным или нет.

Ребята пошли дальше и теперь направляют результаты работы BewAIre в свой SIEM для последующего реагирования со стороны их SIRT-команды.

И именно это помогло им найти несколько атак на их open-source проекты.

Случилось примерно следующее:
🍭 BewAIre указал на то, что один из PR в IaC Scanner (который, кстати, open-source) может быть вредоносным
🍭 Команда отреагировала и выяснила, что злоумышленник пытался внедрить вредоносный код в название файла
🍭 Инъекция заключалась в том, чтобы скачать подконтрольный злоумышленнику файл и выполнить его
🍭 На этом приключение не закончилось. Спустя несколько часов было открыто несколько issues, в описании которых содержался prompt injection

Хорошие новости в том, что подход DataDog показал свою результативность на практике и действия злоумышленника удалось предотвратить.

Что было в том prompt injection и что за файл надо было скачать и запустить – обо всём этом и не только можно прочесть в статье.

Timeline, анализ действий злоумышленника, используемые им подходы, рекомендации по повышению уровня безопасности – всё на месте!

Рекомендуем!

Изучаем Istio: the Hard Way

Всем привет!

Если вы хотели притронуться к технологии Service Mesh и руки всё никак не могли дойти, то, возможно, эта статья сможет вам помочь.

В ней Автор на примере Istio разбирает что это такое, как это работает и как настраивается.

Статья содержит разделы
🍭 Описание «лаборатории» (все материалы можно найти в этом репозитории)
🍭 Краткое описание логики работы Istio
Управление трафиком (VirtualServices, DestinationRules, Subsets)
🍭 Реализация ZeroTrust-концепта с использованием mTLS
🍭 Балансировка нагрузки и не только

Краткое описание того, что происходит приводится в статье.

Если нужно больше информации (например, для самостоятельного воспроизведения), то её можно найти в GitHub-репозитории.

The Agentic Coding Security Report

Всем привет!

В приложении можно найти небольшой отчёт (~ 14 страниц) от DryRun Security – The Agentic Coding Security Report.

В нём отражена точка зрения на вопрос: «AI-агенты всё чаще и чаще используются для разработки ПО. Но как это влияет на уровень информационной безопасности?».

Для этого команда «поставила задачу» трём агентам – Claude, Codex и Gemini – по разработке ПО с последующей его «доработкой» через PR.

По завершению «работы» итоговые варианты программного обеспечения были проанализированы на наличие ИБ-дефектов.

Если кратко, то:
🍭 87% PR содержали ИБ-дефекты
🍭 Большинство ИБ-дефектов были «Высокого» уровня критичности
🍭 Разные агенты допускали идентичные ошибки (Broken Access Control, TOCTOU, XSS, User Enumeration и т.д.)
🍭 Codex показал лучшие результаты ☺️

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

Атака на цепочку поставки: LiteLLM

Всем привет!

Атака на Trivy – вероятно самая обсуждаемая тема нескольких последних недель.

Но не ей единой. Компрометации подверглась и LiteLLM.

47 000 скачиваний уязвимых версий (1.82.7, 1.82.8) за 46 минут.

Вредоносное ПО делает следующее:
🍭 Сбор чувствительных данных (SSH-ключи, информация из конфигурационных файлов, shell-история и т.д.)
🍭 Собранные данные зашифровываются и передаются на https://models.litellm.cloud
🍭 Кроме этого, если присутствует Kubernetes Service Account Token, то вредоносное ПО пытается получить доступ о всех секретах кластера и создать pod и сделать некоторый mount на узел кластера

Подробнее об атаке на LiteLLM можно прочесть в статьях: первая посвящена общему анализу и хронологии событий, вторая – описанию вредоносного ПО.