DevSecOps Talks

Управление секретами с Kloak Всем привет! Самым распространенным способом управления секретами является использованием Secret Management решений. Ярким представителем которых является HashiCorp Vault. Концепт такой что все секреты помещаются в единое надежное хранилище и выдаются на основании логики работы Vault’a. А что если хочется чего-то иного? Например, подстановки самого значения секрета в момент установки соединения за счёт использования eBPF? Как раз эту задачу и реализует Kloak. Работает он примерно так: 🍭 Создаётся секрет в Kubernetes Kloak автоматически создаёт shadow secret, в котором указывается placeholder 🍭 Настраивается взаимосвязь pod с Kloak через аннотации 🍭 Webhook мутирует pod заменяя значение оригинального секрета на shadow secret, созданный Kloak 🍭 В момент запуска pod и установки соединения указывается настоящее значение секрета, полученное из связки shadow secret – оригинальный секрет Такая связка позволяет реализовать процесс, в котором приложение не владеет данными о том, какой именно секрет (значение) используется. Однако сам секрет всё равно «материализован» в кластере Kubernetes. Подробнее о Kloak и его возможностях можно узнать в GitHub-репозитории или в официальной документации.

Подпись образов контейнеров Всем привет! Задача контроля целостности становится актуальнее год от года. В том числе при работе с образами контейнеров. В статье можно найти полноценный пример того, как подписывать образы и добавлять к ним аттестации (некоторую метаинформацию, например о результатах сканирования образа). Материал содержит разделы: 🍭 Что такое подпись образов и как она работает 🍭 Что такое аттестации, какие бывают и для чего используются 🍭 Подпись и аттестация образа с использованием Cosign 🍭 Проверка полученных результатов с использованием Kyverno и не только В статье много схем, пояснений, а также команд, которые позволят воспроизвести всё то, что реализует Автор. Материал для начинающих, но в нем хорошо то, что собрано всё необходимое, ничего лишнего и её можно рассматривать в качестве «первичной инструкции». Если вы искали с чего начать изучение вопроса подписи образов, то эта статья то, что нужно!

Agentic Access Model Всем привет! Вопрос управления доступом – задача крайне непростая. Особенно непростой она становится при работе с агентами. Для того, чтобы комплексно подойти к вопросу, ребята из Cloudflare предложили своё видение – Agentic Access Model (AAM). В её основе лежат 5 принципов: 🍭 Учетные данные краткосрочны и ограничены 🍭 Политики применяются именно там, где осуществляется действие или сетевая активность 🍭 Подтверждение действия со стороны человека 🍭 Шаблоны выполняемых задач не должны быть общими 🍭 Осуществляется контроль полномочий Для того, чтобы реализовать эти принципы, Авторы предлагают концепт архитектуры, который состоит из: Identity Broker, Access Engine, Mediation Layer и Trust Ratchet. Каждый элемент и его назначение описывается в статье. Есть пример того, как это можно применять на практике. В итоге получается целостная картина, которая позволяет управлять доступом при работе с агентами и их возможностями при выполнении задач.

Snyk: VulnBench Всем привет! Недавно мы писали про исследование команды Snyk, посвященное тому, насколько хорошо LLM ищут уязвимости в исходном коде и насколько идемпотентные результаты можно получить. Чтобы было проще посмотреть и проанализировать результаты, Snyk подготовил VulnBench. Фактически – та же сама информация, представленная в виде интерактивного сайта, в котором можно углубиться в исследование. Доступны такие разделы как: 🍭 Summary 🍭 Repeatability 🍭 Coverage 🍭 Efficiency 🍭 Findings В каждом из них собрана детальная информация по результатам, предоставленным каждой LLM. В том числе можно посмотреть на то, как именно LLM выносили вердикт и какое обоснование они формировали. Если вас заинтересовала статья, то VulnBench вам точно понравится!

Kubesplaining: анализ безопасности Kubernetes Всем привет! Зачастую информации о некорректной конфигурации может быть недостаточно. Хочется понять, «к каким последствиям это может привести? Можно ли этим воспользоваться?». Именно на эти вопросы может ответить Kubesplaining. Он позволяет построить «карту передвижения» злоумышленника с указанием возможных способов его реализации. Это достигается за счёт анализа: 🍭 Настроек RBAC 🍭 Конфигурации pod, Admission Controller’ов 🍭 Секретов 🍭 Используемых Service Accounts 🍭 Сетевого взаимодействия и не только В итоге формирует интерактивный отчёт, с примером которого можно ознакомиться тут. Подробности – установка, настройка, работа с исключением – всё это есть в GitHub-репозитории проекта.

Исследования рынков DevSecOps и MLSecOps Привет, друзья! Предлагаем вашему вниманию целых три (!) исследования, которые мы запустили: 🍗Исследование рынка безопасной разработки и DevSecOps 🍗Исследование рынка средств контейнеризации 🍗Исследование рынка безопасности ИИ-систем (MLSecOps) Они направлены на выявление реального положения дел в DevSecOps и MLSecOps, как наиболее хайповых и быстрорастущих направлениях в российском ИТ. Предлагаем вам пройти все эти опросы и, конечно же, отвечать нужно честно - так статистика получится релевантной. Среди всех участников каждого опроса 18 сентября в 14:00 проведём розыгрыш уникального мерча, где определим 3х случайных победителей! В поле «Уникальный идентификатор» нужно указать ник в Telegram, электронную почту или номер телефона. Эти данные понадобятся только для связи с победителями, или если потребуется уточнить ответы.

Насколько хорошо LLM генерируют рекомендации по устранению ИБ-дефектов? Всем привет! Практика создания исправлений для ИБ-дефектов с использованием LLM становится всё более и более распространённой. Но можно ли им полностью доверять? Изменяют ли предлагаемые ими обновления поведение приложения? Могут ли они, исправляя одни ИБ-дефекты, добавлять другие? Ответам на эти вопросы посвящена статья от Off-by-1 Labs (ИБ-команды 1Password). Получилась следующая статистика для 6480 обновлений, подготовленных современными моделями: 🍭 Полностью устраняли ИБ-дефекты и сохраняли логику работы приложения: 26% 🍭 Полностью устраняли ИБ-дефект, но меняли логику работы приложения: 20,1%. Пример изменения логики: изменение allow list на deny list 🍭 Не устраняли ИБ-дефекты полностью и/или добавляли новые: 53,9% Для формирования выборки использовались 6 «свежих» CVE, большинство из которых представляло собой RCE. Каждая модель сгенерировала по 540 обновлений для каждой CVE: разные конфигурации, разные prompts. После этого команда оценила результаты по «пятибальной» шкале: S1 – всё отлично, S5 – ИБ-дефект не устранён, появился новый. Общий итог описан выше. Больше подробностей (статистики, описаний) можно найти в статье. Кстати, в завершении команда приводит набор рекомендаций о том, как можно повысить качество генерируемых исправлений для ИБ-дефектов: всё так, human-in-the-loop в качестве «финального решения» 😅 P.S. Инструментарий, наборы данных и детальное описание статьи выложены для всеобщего рассмотрения. Найти их можно тут, тут и тут соответственно.

VulnReach: композиционный анализ с учётом достижимости Всем привет! VulnReach – open-source проект, который комбинирует практики композиционного анализа, taint-анализа и анализ данных во время эксплуатации ПО. На основе этих данных формируется RBoM – Runtime Bill Of Materials. Всё это необходимо для того, чтобы понять, какая именно уязвимость достижима и может быть эксплуатируема, а какая – нет. Для подтверждения своего «мнения», VulnReach предоставляет информацию о пути выполнения программы, который привёл к уязвимому методу. На текущий момент поддерживается Python. Для Java, JavaScript реализован анализ call graphs, но функциональность всё ещё является экспериментальной. В дальнейшем планируется добавление Golang, C# и PHP. Подробнее о проекте можно прочесть в GitHub-репозитории или на официальном сайте. Кстати, в репозитории есть скриншоты, чтобы лучше ознакомиться с тем, как именно VulnReach «выглядит» и какую информацию он предоставляет.

JavaScript Analysis for Pentesters Всем привет! В статье можно найти достаточно объёмное и подробное руководство о том, на что обращать внимание при анализе JavaScript-приложений. Статья написана с точки зрения «атакующего», но может быть полезна и тем, кто «защищает». Материал разбит на части: 🍭 Static Analysis 🍭 Dynamic Analysis 🍭 (De) obfustation 🍭 Bypass Code Protection и не только В каждом разделе приводится много теории, примеров и пояснений. Есть даже небольшая «лабораторная работа» по анализу обфусцированного кода. Кстати, помимо этой, у Автора можно найти ещё много интересных статей, посвященных информационно безопасности приложений. Рекомендуем!

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.