k8scout: визуализация путей атак в Kubernetes

Всем привет!

k8scout решает простую, но интересную задачу: «Допустим, что в кластере есть pod с RCE. К чему это может привести?».

Утилита анализирует возможности компрометированного pod и пытается совершить разные «нехорошие действия».

Например:
🍭 Повышение привилегий до cluster-admin
🍭 Горизонтальное перемещение (exec в другие pod, «кража» их токенов)
🍭 Побег из контейнера (через привилегированные контейнеры, hostPID, hostNetwork, hostPath и т.д.)
🍭 Попытки изменения ресурсов кластера
🍭 Изменение конфигурации webhooks, созданных в кластере и т.д.

Результаты работы представлены в виде интерактивной карты (пример которой можно увидеть в GitHub-репозитории проекта).

Каждая сработка содержит идентификатор MITRE ATT&CK, уровень риска и пошаговый путь того, как это было сделано.

Подробности, по классике, в GitHub-репозитории проекта.

Важно: утилита совершает активные действия, которые могут повлиять на работоспособность кластера. Использовать аккуратно ☺️

AppSec: вопросы для собеседований

Всем привет!

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

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

Например, для практики – «А как бы я ответил на этот вопрос?». Возможно, что при чтении перечня найдётся область, в которой требуется изучение дополнительных материалов и т.д.

Примеры рассматриваемых вопросов:
🍭 Базовые. Объяснить несколько уязвимостей из OWASP Top 10, разница между SAST и SCA и т.д.
🍭 Общие. Точки «встраивания» ИБ в процессы разработки, что и кто делает и т.д.
🍭 Сценарные. Вы нашли X уязвимостей от инструмента Y, что вы будете с ними делать и почему?
🍭 Синтетические. Перед вами пример исходного кода. Есть ли тут уязвимость, какая и чем она опасна, при каких условиях?
🍭 Концептуальные. Как противодействовать brute force атакам, как именно SSL/TLS помогает в защите, разница между шифрованием и хэшированием и т.д.

Помимо безопасной разработки в репозитории есть аналогичные «опросники» и по иным темам: API Security, AI Security, Container Security и не только.

State of MCP Security 2026

Всем привет!

В приложении можно найти небольшой (~ 10 страниц) отчёт, посвященный безопасности MCP-серверов.

«Мы просканировали более 11 000 публично доступных MCP серверов. В отчёте можно найти нюансы, связанные с безопасностью, что мы нашли» - так начинается отчёт.

Примеры статистики из отчёта:
🍭 232 сервера позволяли выполнять произвольный код, запускать команды, десериализировали непроверенные данные и т.д.
🍭 78% из проверенных серверов не использовали dependency pinning
🍭 1617 содержат известные уязвимости. Перечень наиолее часто встречающихся приведён в отчёте
🍭 260 – запускали install scripts на рабочем месте пользователя
🍭 В 31% случаев наблюдались нюансы, связанные с аутентификацией (возможность анонимных вызовов)

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

Кстати, Авторы заметили интересную корреляцию – чем больше у MCP-сервера «звёзд» на GitHub, тем больше у него нюансов с безопасностью.

Secure AI Lifecycle Framework 2.0

Всем привет!

В приложении можно найти документ, в котором описан SAIL – Secure AI Lifecycle Framework 2.0 (~ 50 страниц).

Он представляет из себя практическое руководство о создании и запуске AI-приложений и агентов в «безопасном режиме».

Материал структурирован по разделам:
🍭 Executive Summary. Описание используемого подхода
🍭 Shape of the Agentic Attack Surface. Описание основных ИБ-проблем, с которыми можно столкнуться
🍭 SAIL. Основные разделы framework и их описание

Сам framework разбит на 7 разделов: AI Policy (Plan), AI Discovery (Code/No Code), Agentic Posture (Build), Agentic Red Teaming (Test), Runtime Controls (Deploy), Sandbox (Operate), Govern (Monitor & Retire).

Чтобы им удобнее было пользоваться, для каждого раздела (домена) определён перечень характерных рисков. Всего доступно описание 91 риска.

Описание содержит идентификатор (ID), риск, описание, пример, подверженные активы, способы устранения, соотношения со стандартами.

В завершении материала представлен небольшой пример (use case), который наглядно описывает использование SAIL 2.0.

GuardDog: 3.0

Всем привет!

GuardDog – проект от Datadog, который позволяет идентифицировать вредоносные пакеты за счёт анализа исходного кода и метаданных о пакете.

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

Недавно было выпущено ещё одно крупное обновление – GuradDog 3.0!

Из основных изменений можно выделить:
🍭 Отказ от Semgrep в сторону YARA-правил. Почему? Ответ есть в статье 😊
🍭 Новая модель оценки рисков пакетов
🍭 Новый набор правил для идентификации подозрительных пакетов (через определение capabilities и через определение threat indicators)
🍭 Поддержка Nono в качестве «песочницы» при проведении анализа
🍭 Улучшение производительности и не только

Подробнее обо всех изменениях можно прочесть в статье. В ней есть всё, что нужно – причины изменений, описания, комментарии.

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

Использование LLM в SAST

Всем привет!

Статический анализ – один из самых первых видов анализа ПО, который только появился.

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

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

И картина (вроде бы) меняется с появлением LLM: вместо разбора ложных сработок можно сосредоточиться на том, как исправить то, что актуально.

Но так ли всё радужно на самом деле? В небольшой статье Автор представил своё мнение на этот счёт.

Он структурировал мысли по следующим разделам:
🍭 Good. Разметка. Да, тут LLM показывают очень хорошие результаты. Ведь, если упростить, то речь про понимание кода и ответы на вопросы
🍭 Bad. Галлюцинации, (не) всегда идемпотентные результаты, относительные возможности по поиску ИБ-дефектов в исходном коде
🍭 Ugly Costly. Чем больше сработок – тем больше приходится платить. Вопросы «доверия» человека «к машине»

И, по мнению Автора, получается, что стандартные детерминированные подходы увеличивают Recall и могут «поймать всё на свете», а LLM – Precision (понимают, что из этого на самом деле применимо)

А что вы думаете по этому поводу и согласны ли вы с этим списком, что бы вы в него добавили?

Migratowl: анализ обновления зависимостей

Всем привет!

«Если я обновлю зависимость X на иную версию, то сломается ли что-нибудь и если да, то как мне это чинить?» - именно на этот вопрос может ответить Migratowl.

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

Всё это запускается в изолированном контейнере.

В результате пользователь получает информацию:
🍭 Сломало ли обновление что-нибудь?
🍭 Что именно «пошло не так»?
🍭 Описание изменений из changelog
🍭 Предложение по решению проблемы на «обычном» языке

Согласно мнению Авторов утилиты она может быть использована, как дополнение для SCA-решений.

Как минимум, потому что Migratowl не предоставляет информации о CVE, которые есть в пакетах.

Установка, настройка, примеры результатов работы – всё это можно найти в GitHub-репозитории проекта или на сайте.

LFK: Lightning Fast Kubernetes Navigator

Всем привет!

Если вам надоел k9s или вы хотите «что-нибудь» новое, то LFK может вас заинтересовать!

Да, всё так – ещё один TUI для работы с кластером Kubernetes.

Он предлагает следующее:
🍭 Удобная навигация от кластера то метаинформации о существующих ресурсах
🍭 Отображение данных о потребляемых ресурсах
🍭 Vim-style навигация!
🍭 Работа с несколькими кластерами
🍭 Разные возможности по работе с ресурсами: от поиска до создания и изменения
🍭 Возможность персональной настройки и ещё много всего

Детальное описание возможностей LFK представлено в GitHub-репозитории.

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

Какие образы используются в кластере?

Всем привет!

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

В рамках миграции у них возник запрос: «Нужен дашборд, на котором будет отображаться информация о том, какие контейнеры используют образы Chainguard, а какие – нет».

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

Казалось бы, всё просто, но есть нюансы:
🍭 Для самой очевидной проверки ОС внутри контейнера в нём должна быть оболочка, но это не всегда так (например, distroless-образы)
🍭 «Вытаскивать» образ из Kubernetes-манифеста? Не всегда получится, т.к. многие используют digest, а не image:tag
🍭 Использование сканеров, которые анализируют образы и, в том числе, отображают информацию об ОС? Это не всегда происходит корректно, да и для runtime это не всегда подойдёт в моменте

Чтобы решить задачу, Автор начал смотреть в сторону ядра ОС, которое «знает всё».

В итоге получилось следующее: получение информации о pid контейнера, извлечение информации о нём с узла, анализ принадлежности образа к нужной версии ОС.

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

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

«Утилиту», созданную Автором для решения задачи можно найти вот в этом GitHub-репозитории.

Да, статья написана для Chainguard, но их можно «заменить» на любые иные образы. Сам подход останется прежним.

Насколько пригоден Opus 4.6 для поиска уязвимостей?

Всем привет!

Команда ZeroPath провела небольшое исследование. Они проанализировали 435 известных уязвимостей в С, у каждой из которых есть свои CVE, с использованием Opus 4.6.

Команда использовала разные «наборы» prompt и инструментов для поиска. Результаты, в зависимости от выбранного набора, различались, хоть и не сильно.

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

Далее команда определила свой подход: на вход LLM было передано 2 набора функций – уязвимые и исправленные (patched). После того, как модель дала свои «ответы» команда проверяла насколько она правильно определила (не) уязвимые функции.

Итог получился такой: с хорошими prompt и правильно подобранными инструментами, модель нашла 28,5% уязвимостей.

Но были и некоторые нюансы: большое количество ложных срабатываний, (не) всегда консистентные результаты.

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

Kobe: Kubernetes-кластер «по запросу»

Всем привет!

Допустим, для целей тестирования новой версии ПО требуется Kubernetes-кластер.

Можно постоянно «держать их под рукой», но это не всегда целесообразно.

Иногда нужен «эфемерный кластер», который существует только на время тестирования.

Эту задачу поможет решить Kobe – open-source проект, который предоставляет такие вот кластеры «по запросу».

Состоит он из нескольких ключевых компонентов:
🍭 Operator. Запускается в host-кластере и контролирует ClusterPool, ClusterInstance, ClusterLease. Т.е. все компоненты, которые помогают контролировать предоставленные кластеры, их количество, доступность и т.д.
🍭 HTTP API. Обработка запросов на создание временных кластеров
🍭 Pool Manager. Управление созданными кластерами: создание, временное предоставление, удаление

В качестве pools – тех самых кластеров – могут выступать разные сущности.

Например, k3s (вариант по умолчанию), k0s, CAPI и не только.

Подробности о возможности Kobe можно посмотреть в GitHub-репозитории и в официальной документации проекта.

Важно (!): проект достаточно молодой и могут быть некоторые нюансы, связанные с его работоспособностью

Безопасная разработка: Rust

Всем привет!

Мы неоднократно писали про материалы от Trail of Bits и их Security Handbook.

Ресурс продолжает развиваться и недавно команда выпустила раздел, посвященный безопасности Rust.

Он содержит разделы:
🍭 Security Overview. Общая информация о нюансах безопасности, характерных для Rust
🍭 Dynamic Analysis. Набор рекомендаций, как осуществлять динамический анализ, какие утилиты использовать
🍭 Static Analysis. Аналогично динамическому, но только для анализа исходных текстов
🍭 Supply Chain Security. Описание работы с пакетами и возможностей
cargo, которые могут пригодиться

Это далеко не всё, что есть в разделе посвящённом Rust. Как обычно, никакой воды, всё по делу, много примеров и рекомендаций.

Рекомендуем к ознакомлению!

AI-проекты для анализа ПО

Всем привет!

По ссылке можно найти статью от Semgrep, в которой команда сравнивает разные AI-проекты, которые помогают искать уязвимости в ПО.

Всего рассматривается 3 «типа»:
🍭 Skill Boosting. Добавление skills к LLM, чтобы они «рассуждали», как исследователь безопасности ПО при его анализе
🍭 SAST с LLM. Использование результатов работы SAST «на вход» LLM для дальнейшей работы
🍭 Генерация exploit’ов. Использование AI-проектов в качестве «помощника» при генерации «доказательств актуальности уязвимости» за счёт генерации exploit’ов

Для каждого «типа» Автор приводит несколько open-source инструментов, которыми можно воспользоваться, их краткое описание.

Чтобы было проще подобрать инструмент «под себя», их разделили на «логические» блоки: для исследователей уязвимостей; для тех, кто часто работает с C/C++; для оптимизации процесса разметки и т.д.

Возможно, вы уже что-то из этого используете или планируете. Делитесь своим опытом в комментариях! ☺️

LLM Inference в Kubernetes

Всем привет!

Статья описывает опыт Автора, в которой он разворачивает LLM-модель локально, в своём кластере Kubernetes.

Для этого он использует следующие технологии: vLLM, KEDA, GAIE, llm-d, Karpenter и не только.

После небольшого взгляда на концептуальную архитектуру предлагаемого решения начинается самое интересное – реализация.

Автор описывает разделы:
🍭 Использование Karpenter для управления GPU-узлами
🍭 О чём важно помнить при работе с GPU в Kubernetes
🍭 Настройка Ingress и TLS с Istio и Cert Manager
🍭 Установка и настройка модели (qwen-3.6-27B-fp8)
🍭 Конфигурация автоматического масштабирования с использованием Keda и не только
🍭 Настройка мониторинга, контроль использования GPU

Весь путь, пройденный Автором, описан максимально детально: все команды, конфигурационные файлы, ссылки на инструментарий, важные уточнения (опыт, полученный на ошибках) – всё это есть в статье.

Если вы думали реализовать нечто подобное, то статья точно может быть вам полезной!

VulnHunter: анализ исходного кода с AI-агентами

Всем привет!

Недавно команда Capital One передала свой проект – VulnHunter – в open-source.

Согласно описанию, в отличие от «традиционных» SAST, полагающихся на определённые шаблоны/правила, VulnHunter «размышляет как злоумышленник», что возможно за счет использования AI.

Он позволяет определять то, что на самом деле эксплуатируемо, анализирует пути атаки и предоставляет свидетельства, подтверждающие наличие уязвимости.

Для этого используется 3 основных skill:
🍭 Hunt. Поиск «опасных конструкций» в исходном коде. После их выявления запускается многоступенчатый процесс, в результате которого пользователь получает только то, что на самом деле значимо
🍭 Fix. Создание эксплойта, тестов, подготовка исправления, повторный запуск тестов и, если всё хорошо, оформление PR
🍭 Verify. Read-only агент, задача которого – убедиться в том, что устранение уязвимости было осуществлено

Можно использовать разные модели, но лучше всего VulnHunter работает с Claude Opus.

Выглядит достаточно интересно, но как работает «по факту» - вопрос.

Возможно, что кто-то уже сталкивался с решением, как оно вам?

Создание OSS Kubernetes Console с MCP

Всем привет!

Решений, которые анализируют кластеры Kubernetes и запускаемые в них контейнеры на предмет ИБ-дефектов, очень много.

Многие из них дают очень хорошие результаты. Нюанс в наличие контекста.

Т.е. покажи не то, что «нашёл сканер», а то, «что это значит для моей инсталляции».

И вот тут как раз возникает много вопросов. Например, как сделать из этого нескончаемого потока сигналов что-то осмысленное.

С этими мыслями Автор статьи предлагает своё видение ответа на этот вопрос – OSS Kubernetes Console с MCP.

Он собирает следующий набор инструментов:
🍭 Falco для анализа запущенных контейнеров
🍭 Trivy для поиска уязвимостей в образах контейнеров
🍭 Kyverno в качестве Policy Engine
🍭 Kubescape для анализа конфигурации кластера

Результаты от всех решений «собираются вместе» и анализируются, обладая общим контекстом.

Важно(!): для анализа используется Claude Code (на случай, если вы захотите попробовать предлагаемый концепт)

Это позволяет превратить «В контейнере запущен shell» в нечто вроде «В Kubernetes-ресурсе, созданном из образа с известными уязвимостями, запущен shell. Конфигурация ресурса не соответствует принятым в компании политикам».

Подробности предлагаемого Автором подхода можно найти в статье или в GitHub-репозитории.

Кстати, в GitHub-репозитории можно найти несколько skills, созданных Автором: от triage до remediation.

Nomos: контроль действий AI-агентов

Всем привет!

Использование AI-агентов постепенно становится общей практикой. При этом недоверие к ним всё равно остаётся – «а что если он сделает что-то не то?».

Чтобы несколько повысить уровень безопасности при работе с ними можно посмотреть на open-source проект Nomos.

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

Это нужно для того, чтобы:
🍭 Контролировать чтение чувствительной информации (секретов)
🍭 Влиять на потенциально опасные команды (rm -rf, kubectl delete, git push и т.д.)
🍭 Сканировать MCP-ответы на наличие потенциальных инъекций
🍭 Собирать свидетельства аудита (audit traces) и не только

«Из коробки» Nomos предоставляет несколько политик контроля. Их можно изменять и расширять по усмотрению пользователя.

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

OpenAnt: поиск Иб-дефектов в ПО с использованием LLM

Всем привет!

OpenAnt – ещё один представитель класса решений, которые используют LLM для того, чтобы искать ИБ-дефекты в ПО и сокращать количество «шума».

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

Работает он примерно так:
🍭 Анализирует кодовую базу
🍭 Строит графы вызовов (call graphs)
🍭 Пытается выявить участки кода, доступные «извне»
🍭 Анализирует source/sink с использованием LLM
🍭 Пытается проверить сработки путём их эксплуатации

«Из коробки» реализована поддержка Anthropic, OpenAI и Google. В планах у ребят реализация поддержки большего количества моделей.

На текущий момент поддерживаются языки: Go, Python, JS/TS (beta), C/C++ (beta), PHP (beta), Ruby (beta), Zig (beta) и Swift (beta).

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

Важно (!): некоторая функциональность OpenAnt всё ещё находится в стадии «beta», т.к. проект активно развивается

Luxury Yacht: GUI для управления кластерами Kubernetes

Всем привет!

«Я попробовал разные GUI для Kubernetes, но не смог найти то, что нужно именно мне, поэтому сделал своё» - комментарий Автора о причине создания Luxury Yacht.

Как и большинство подобных решений она позволяет:
🍭 Получать сводную информацию по кластеру (утилизация ресурсов, количество узлов, последние events, данные о ресурсах и т.д.)
🍭 Управление несколькими кластерами их единого UI с возможностью «переключения»
🍭 Получение информации и поиск интересующих ресурсов
Возможность делать diff конфигураций
🍭 Делать port-forward,
exec
🍭 Редактировать yaml- файлы не покидая UI и не только

Так в чём же разница?

Автор выделяет несколько возможностей: максимально удобный просмотр логов, построение «карты взаимодействия/связности» ресурсов, возможность расположения объектов «под себя», управление узлами (cordon, drain, delete) и не только.

Выглядит Luxury Yacht достаточно приятно и ненагруженно. Посмотреть можно вот тут и в GitHub-репозитории проекта.

Довелось ли вам использовать этот GUI и что вы о нём думаете?

Deployah: «быстрый» deploy в Kubernetes

Всем привет!

Deployah – open-source утилита, которая упрощает процесс разворачивания приложений в кластере Kubernetes.

«Внутри» она содержит всё необходимое: helm, kubectl, kind. За счёт этого требуется всего лишь создать небольшой конфигурационный файл – deployah.yaml, а дальше она сама сделает всё необходимое.

Работает это примерно так:
🍭 Анализ конфигурации. Поиск ошибок и неточностей, чтобы устранить их заранее
🍭 Адаптация конфигурации. Выбор требуемой среды для разворачивания, подстановка необходимых переменных
🍭 Запуск. Создание Helm Values, установка Helm Release в выбранном кластере

Сама спецификация требует заполнения трех обязательных полей - apiVersion, project и components.

Для управления кластерами, в которых будут созданы ресурсы, используется ещё один конфигурационный файл - deployah.platform.yaml.

В нём необходимо указать основные параметры. Например, nodeSelector, securityContext, storageClass и т.д.

Используя эту информацию и данные о конфигурации запускаемого приложения Deployah как раз и создаст необходимые Values для установки Helm Chart.

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

P.S. А если вам интересно "а зачем оно вообще надо", то ответ Автора, раскрывающий мотивацию создания Deployah можно найти тут ☺️

Awesome: LLM4Cybersecurity

Всем привет!

Сегодня хотим рассказать вам про ещё одну Awesome-подборку.

В ней собрана информация о возможных способах применения и возможностях LLM, применительно к информационной безопасности.

Awesome разбит на разделы:
🍭 LLM Assisted Defense
🍭 Vulnerability Detection
🍭 Program/Vulnerability Repair
🍭 FUZZ
🍭 Insecure Code Generation и не только

Для каждого раздела собраны ссылки на релевантные материалы по теме. В среднем получается около 50 ссылок на каждую.

Внутри можно найти материалы в том числе по безопасной разработке: использование LLM для поиска ИБ-дефектов, для устранения или для подтверждения возможности эксплуатации того, что было найдено.