DevSecOps Talks

KubeShark: использование LLM в Kubernetes Всем привет! KubeShark – skill для работы с Kubernetes. Основная его задача – генерировать и/или исправлять конфигурации в ресурсах. Основная проблема, которую пытался решить Автор – галлюцинации, которые зачастую случаются при работе LLM с Kubernetes. Для этого он реализовал следующий подход: 🍭 Изучение контекста. Версия кластера, используемый namespace, окружение, тип ресурса 🍭 Анализ failure modes. Поиск наиболее подходящего из 6 сценариев (небезопасная конфигурация, некорректная работа с ресурсами, проблемы с сетью и т.д.) 🍭 Загрузка сценариев. На основании предыдущего шага выбирается набор подходящих инструкций для диагностики 🍭 Формирование рекомендаций. Предложение по тому, как можно решить выявленные проблемы 🍭 Генерация артефактов. Создание манифестов, Helm Charts, политик и т.д., в которых реализовано предложенное исправление 🍭 Проверка. Dry-run, валидация наработок, проверка консистентности В итоге получается древовидная структура, которая содержит большое количество разных проверок, применяемых в зависимости от ситуации. Такой подход, по мнению Автора, сильно сокращает вероятность того, что LLM «добавит что-то от себя». Примеры задач, которые поможет решить KubeShark: создай `deployment` с N репликами, `requests/limits` и `ingress`; проверь конфигурацию на наличие проблем безопасности; создай роль с минимальными привилегиями, для сервиса X, который должен уметь делать Y и т.д. Подробнее про KubeShark можно прочесть в GitHub-репозитории или в официальной документации.

Поиск ИБ-дефектов с LLM: идемпотентность Всем привет! «Может ли LLM найти один и тот же ИБ- дефект дважды?» - именно этот вопрос задала себе команда Snyk. Для того, чтобы ответить на него ребята запустили 300 сканирований. Один и тот же исходный код. Один и тот же prompt. Один и тот же harness. Несколько раз. Что получилось? Ответ можно найти в достаточно объемной статье (~ 29 минут на прочтение). tl;dr – результаты могли отличаться от запуска к запуску. А если хочется деталей, то они есть внутри и «разбиты» на разделы: 🍭 Результат №1. Повторяемость LLM варьируется от конфигурации 🍭 Результат №2. LLM-агенты и SAST нашли разные ИБ-дефекты 🍭 Результат №3. Более дорогие LLM не всегда показывали лучшие результаты Для каждого из описанных выше разделов приводится много статистики, пояснений и уточнений о том, как именно запускались тесты и что именно было найдено. Проводили ли вы у себя подобные исследования и какие были результаты?

Drogonsec: комплексный анализ ПО Всем привет! Drogonsec – open-source сканер, который объединяет в себе сразу несколько типов анализа: Secrets, SAST и SCA. В результате работы формируется единый отчёт, в котором всё структурировано по типам практик. При желании их можно «включать» и «отключать». Secrets анализирует как текущую директорию, так и историю (при необходимости можно отключить) на наличие чувствительных данных. Для SAST поддерживается более 20 языков, среди которых: Python, Java, JS, TS, Golang, Kotlin, C/C++ и не только. Суммарно доступно более 150 правил, которые можно добавлять самостоятельно. SCA по классике – анализ манифестов и определение «подходящих» CVE. При необходимости Drogonsec позволяет выгрузить SBoM-файл. Для формирования рекомендаций по устранению идентифицированных ИБ-дефектов, помимо того, что описано в правилах, можно использовать LLM. Доступно «подключение» как к локальной LLM (Ollama, DeepSeek Coder), так и к внешним (Anthropic, OpenAI, Azure и т.д.). Больше подробностей про Drogonsec можно найти в GitHub-репозитории и в официальной документации на утилиту.

XSS Laboratories Всем привет! XSS Laboratories – open-source проект, в котором неожиданно! собраны лабораторные работы, обучающие тому, что такое XSS и какие они бывают. Всего доступно 9 лабораторных: 🍭 Introduction to XSS Basics 🍭 Stored XSS Attacks 🍭 DOM-based XSS 🍭 Advanced XSS Techniques 🍭 Edit/View Functionality XSS и не только Итого – 5 Reflected, 3 Stored и 1 DOM XSS. Если нет желания запускать локально, то лабораторные можно посмотреть вот тут. Приятного изучения и практики!

Awesome: LLM4Cybersecurity Всем привет! Сегодня хотим рассказать вам про ещё одну Awesome-подборку. В ней собрана информация о возможных способах применения и возможностях LLM, применительно к информационной безопасности. Awesome разбит на разделы: 🍭 LLM Assisted Defense 🍭 Vulnerability Detection 🍭 Program/Vulnerability Repair 🍭 FUZZ 🍭 Insecure Code Generation и не только Для каждого раздела собраны ссылки на релевантные материалы по теме. В среднем получается около 50 ссылок на каждую. Внутри можно найти материалы в том числе по безопасной разработке: использование LLM для поиска ИБ-дефектов, для устранения или для подтверждения возможности эксплуатации того, что было найдено.

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 можно найти тут ☺️

Luxury Yacht: GUI для управления кластерами Kubernetes Всем привет! «Я попробовал разные GUI для Kubernetes, но не смог найти то, что нужно именно мне, поэтому сделал своё» - комментарий Автора о причине создания Luxury Yacht. Как и большинство подобных решений она позволяет: 🍭 Получать сводную информацию по кластеру (утилизация ресурсов, количество узлов, последние events, данные о ресурсах и т.д.) 🍭 Управление несколькими кластерами их единого UI с возможностью «переключения» 🍭 Получение информации и поиск интересующих ресурсов Возможность делать diff конфигураций 🍭 Делать port-forward, exec 🍭 Редактировать yaml- файлы не покидая UI и не только Так в чём же разница? Автор выделяет несколько возможностей: максимально удобный просмотр логов, построение «карты взаимодействия/связности» ресурсов, возможность расположения объектов «под себя», управление узлами (cordon, drain, delete) и не только. Выглядит Luxury Yacht достаточно приятно и ненагруженно. Посмотреть можно вот тут и в GitHub-репозитории проекта. Довелось ли вам использовать этот GUI и что вы о нём думаете?

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», т.к. проект активно развивается

Nomos: контроль действий AI-агентов Всем привет! Использование AI-агентов постепенно становится общей практикой. При этом недоверие к ним всё равно остаётся – «а что если он сделает что-то не то?». Чтобы несколько повысить уровень безопасности при работе с ними можно посмотреть на open-source проект Nomos. Он представляет из себя нечто вроде «межсетевого экрана», который «стоит» между агентами и целевой системой. Это нужно для того, чтобы: 🍭 Контролировать чтение чувствительной информации (секретов) 🍭 Влиять на потенциально опасные команды (rm -rf, kubectl delete, git push и т.д.) 🍭 Сканировать MCP-ответы на наличие потенциальных инъекций 🍭 Собирать свидетельства аудита (audit traces) и не только «Из коробки» Nomos предоставляет несколько политик контроля. Их можно изменять и расширять по усмотрению пользователя. Подробнее об архитектуре, запуске, настройке и результатах работы Nomos можно узнать в GitHub-репозитории проекта.

Создание 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.

VulnHunter: анализ исходного кода с AI-агентами Всем привет! Недавно команда Capital One передала свой проект – VulnHunter – в open-source. Согласно описанию, в отличие от «традиционных» SAST, полагающихся на определённые шаблоны/правила, VulnHunter «размышляет как злоумышленник», что возможно за счет использования AI. Он позволяет определять то, что на самом деле эксплуатируемо, анализирует пути атаки и предоставляет свидетельства, подтверждающие наличие уязвимости. Для этого используется 3 основных skill: 🍭 Hunt. Поиск «опасных конструкций» в исходном коде. После их выявления запускается многоступенчатый процесс, в результате которого пользователь получает только то, что на самом деле значимо 🍭 Fix. Создание эксплойта, тестов, подготовка исправления, повторный запуск тестов и, если всё хорошо, оформление PR 🍭 Verify. Read-only агент, задача которого – убедиться в том, что устранение уязвимости было осуществлено Можно использовать разные модели, но лучше всего VulnHunter работает с Claude Opus. Выглядит достаточно интересно, но как работает «по факту» - вопрос. Возможно, что кто-то уже сталкивался с решением, как оно вам?

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 Весь путь, пройденный Автором, описан максимально детально: все команды, конфигурационные файлы, ссылки на инструментарий, важные уточнения (опыт, полученный на ошибках) – всё это есть в статье. Если вы думали реализовать нечто подобное, то статья точно может быть вам полезной!

AI-проекты для анализа ПО Всем привет! По ссылке можно найти статью от Semgrep, в которой команда сравнивает разные AI-проекты, которые помогают искать уязвимости в ПО. Всего рассматривается 3 «типа»: 🍭 Skill Boosting. Добавление skills к LLM, чтобы они «рассуждали», как исследователь безопасности ПО при его анализе 🍭 SAST с LLM. Использование результатов работы SAST «на вход» LLM для дальнейшей работы 🍭 Генерация exploit’ов. Использование AI-проектов в качестве «помощника» при генерации «доказательств актуальности уязвимости» за счёт генерации exploit’ов Для каждого «типа» Автор приводит несколько open-source инструментов, которыми можно воспользоваться, их краткое описание. Чтобы было проще подобрать инструмент «под себя», их разделили на «логические» блоки: для исследователей уязвимостей; для тех, кто часто работает с C/C++; для оптимизации процесса разметки и т.д. Возможно, вы уже что-то из этого используете или планируете. Делитесь своим опытом в комментариях! ☺️

Безопасная разработка: Rust Всем привет! Мы неоднократно писали про материалы от Trail of Bits и их Security Handbook. Ресурс продолжает развиваться и недавно команда выпустила раздел, посвященный безопасности Rust. Он содержит разделы: 🍭 Security Overview. Общая информация о нюансах безопасности, характерных для Rust 🍭 Dynamic Analysis. Набор рекомендаций, как осуществлять динамический анализ, какие утилиты использовать 🍭 Static Analysis. Аналогично динамическому, но только для анализа исходных текстов 🍭 Supply Chain Security. Описание работы с пакетами и возможностей cargo, которые могут пригодиться Это далеко не всё, что есть в разделе посвящённом Rust. Как обычно, никакой воды, всё по делу, много примеров и рекомендаций. Рекомендуем к ознакомлению!

Kobe: Kubernetes-кластер «по запросу» Всем привет! Допустим, для целей тестирования новой версии ПО требуется Kubernetes-кластер. Можно постоянно «держать их под рукой», но это не всегда целесообразно. Иногда нужен «эфемерный кластер», который существует только на время тестирования. Эту задачу поможет решить Kobe – open-source проект, который предоставляет такие вот кластеры «по запросу». Состоит он из нескольких ключевых компонентов: 🍭 Operator. Запускается в host-кластере и контролирует ClusterPool, ClusterInstance, ClusterLease. Т.е. все компоненты, которые помогают контролировать предоставленные кластеры, их количество, доступность и т.д. 🍭 HTTP API. Обработка запросов на создание временных кластеров 🍭 Pool Manager. Управление созданными кластерами: создание, временное предоставление, удаление В качестве pools – тех самых кластеров – могут выступать разные сущности. Например, k3s (вариант по умолчанию), k0s, CAPI и не только. Подробности о возможности Kobe можно посмотреть в GitHub-репозитории и в официальной документации проекта. Важно (!): проект достаточно молодой и могут быть некоторые нюансы, связанные с его работоспособностью

Насколько пригоден Opus 4.6 для поиска уязвимостей? Всем привет! Команда ZeroPath провела небольшое исследование. Они проанализировали 435 известных уязвимостей в С, у каждой из которых есть свои CVE, с использованием Opus 4.6. Команда использовала разные «наборы» prompt и инструментов для поиска. Результаты, в зависимости от выбранного набора, различались, хоть и не сильно. Набор данных, над которым проводился анализ, был взят из вот этого исследования и опубликован (его можно найти по ссылке). Далее команда определила свой подход: на вход LLM было передано 2 набора функций – уязвимые и исправленные (patched). После того, как модель дала свои «ответы» команда проверяла насколько она правильно определила (не) уязвимые функции. Итог получился такой: с хорошими prompt и правильно подобранными инструментами, модель нашла 28,5% уязвимостей. Но были и некоторые нюансы: большое количество ложных срабатываний, (не) всегда консистентные результаты. Подробные результаты с цифрами, комментариями, нюансами и выводами, сформированными по результатам исследования, представлены в статье.

Какие образы используются в кластере? Всем привет! Одна компания начала миграцию своих базовых образов на наработки от Chainguard (минималистичные образы, в которых содержится минимальное количество уязвимостей). В рамках миграции у них возник запрос: «Нужен дашборд, на котором будет отображаться информация о том, какие контейнеры используют образы Chainguard, а какие – нет». Это помогло бы команде отслеживать статус миграции. Решению этой задачи посвящена статья. Казалось бы, всё просто, но есть нюансы: 🍭 Для самой очевидной проверки ОС внутри контейнера в нём должна быть оболочка, но это не всегда так (например, distroless-образы) 🍭 «Вытаскивать» образ из Kubernetes-манифеста? Не всегда получится, т.к. многие используют digest, а не image:tag 🍭 Использование сканеров, которые анализируют образы и, в том числе, отображают информацию об ОС? Это не всегда происходит корректно, да и для runtime это не всегда подойдёт в моменте Чтобы решить задачу, Автор начал смотреть в сторону ядра ОС, которое «знает всё». В итоге получилось следующее: получение информации о pid контейнера, извлечение информации о нём с узла, анализ принадлежности образа к нужной версии ОС. Вся собранная информация передаётся в Grafana, в которой отображается информация о % операционных систем, используемых в базовых образах. Больше деталей о реализации и о характерных для неё нюансах можно узнать в статье. «Утилиту», созданную Автором для решения задачи можно найти вот в этом GitHub-репозитории. Да, статья написана для Chainguard, но их можно «заменить» на любые иные образы. Сам подход останется прежним.

LFK: Lightning Fast Kubernetes Navigator Всем привет! Если вам надоел k9s или вы хотите «что-нибудь» новое, то LFK может вас заинтересовать! Да, всё так – ещё один TUI для работы с кластером Kubernetes. Он предлагает следующее: 🍭 Удобная навигация от кластера то метаинформации о существующих ресурсах 🍭 Отображение данных о потребляемых ресурсах 🍭 Vim-style навигация! 🍭 Работа с несколькими кластерами 🍭 Разные возможности по работе с ресурсами: от поиска до создания и изменения 🍭 Возможность персональной настройки и ещё много всего Детальное описание возможностей LFK представлено в GitHub-репозитории. Помимо этого там очень-очень-очень много скриншотов и небольших демо, которые наглядно демонстрируют утилиту и её возможности.

Migratowl: анализ обновления зависимостей Всем привет! «Если я обновлю зависимость X на иную версию, то сломается ли что-нибудь и если да, то как мне это чинить?» - именно на этот вопрос может ответить Migratowl. Её принцип работы следующий: клонирует репозиторий, анализирует манифесты, устанавливает зависимости и анализирует результаты сборки с использованием LLM. Всё это запускается в изолированном контейнере. В результате пользователь получает информацию: 🍭 Сломало ли обновление что-нибудь? 🍭 Что именно «пошло не так»? 🍭 Описание изменений из changelog 🍭 Предложение по решению проблемы на «обычном» языке Согласно мнению Авторов утилиты она может быть использована, как дополнение для SCA-решений. Как минимум, потому что Migratowl не предоставляет информации о CVE, которые есть в пакетах. Установка, настройка, примеры результатов работы – всё это можно найти в GitHub-репозитории проекта или на сайте.

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