DevSecOps Talks

Prempti: Falco для AI Coding Agents Всем привет! Falco – крайне известный инструмент в мире защиты сред контейнеризации. Он позволяет анализировать поведение контейнеров. Теперь с его помощью можно узнать больше о том, какие действия на самом деле реализуют AI Coding Agents. Именно это и делает Prempti, использующая Falco «под капотом». Она позволяет: 🍭 Перехватывать запросы к инструментам в режиме реального времени (shell-команды, работа с файлами, анализ вызова MCP) 🍭 Принимать решения о том, что делать – разрешить, запретить, уточнить 🍭 Получать полный audit trail о том, что происходило при работе агента 🍭 Добавлять собственные правила для анализа (аналогичные правилам Falco) Работает она просто: в случае, когда coding agent пытается использовать tool, Prempti перехватывает вызов перед его выполнением, анализирует и выдаёт вердикт. Кстати, она может работать как в enforce, так и в monitor режимах. Подробнее об утилите можно прочесть в GitHub-репозитории. Важно(!): проект находится в стадии активной разработки, поэтому что-то может (не) работать, а что-то может сильно меняться от релиза к релизу.

Kubernetes RBAC Generator Всем привет! Аудит прав доступа – вечная головная боль. В каких-то системах он происходит менее «сложно», в каких-то – более. Отчасти это связано с гибкой ролевой моделью и её возможностями. Kubernetes в этом плане очень непрост, ведь роль можно создать на любой ресурс, любое действие, да ещё и контролировать границы. Чтобы упростить задачу их создания, была придумана Audicia. Если просто, то она генерирует роли с минимальными привилегиями на основе анализа журналов событий. При помощи неё можно: 🍭 Генерировать роли с минимальными правами, необходимыми ресурсу 🍭 Делать это постоянно, т.к. она работает в качестве operator’a, который присутствует в кластере 🍭 Использовать GitOps-подходы за счет использования сгенерированных CRD 🍭 Выявлять drift в настройках RBAC и не только Сама по себе Audicia ничего не меняет в кластере, а только генерирует манифесты для ролей. Не требует доступа к секретам и иной чувствительной информации. Если вам интересно узнать, как именно она работает, то можно обратиться к GitHub-репозиторию проекта или официальной документации.

MCP Hardening Guide Всем привет! Сегодня хотим предложить вам чтение на выходной! Статью, в которой собраны рекомендации о настройках безопасности при использовании MCP (~ 16 минут). Авторы рассматривают 6 основных разделов: 🍭 Network Isolation 🍭 Dependency and Supply Chain Security 🍭 Secrets Management at Runtime 🍭 TLS Configuration Hardening 🍭 Runtime Behavioral Monitoring 🍭 Pre-deployment Security Gate Для каждого раздела приводится краткое описание, небольшие примеры и перечень требований, по которым можно сделать самопроверку (verification checklist).

Kubernetes: CPU Req/Lim на практике! Всем привет! Управление ресурсами в Kubernetes – одна из основополагающих функций, которая была в нём чуть ли не с самого начала. Однако, спустя годы, всё равно появляются вопросы и разногласия о том, как это делать и что лучше (не) использовать. Ещё одно мнение по этому поводу можно найти в статье. Она хороша для погружения в тему: лаконичные пояснения, примеры, немного математики и кода. В ней Автор описывает: 🍭 Как работает распределение ресурсов CPU (дада, те самые cgroups, про которые мы писали недавно) 🍭 Как работает CPU Sharing в Kubernetes 🍭 Что «скрывают» за собой CPU Requests и Limits 🍭 Как, когда и почему появляется CPU Throttling И в завершении Автор ещё раз рассуждает на тему – нужны ли (и, если да, то когда) CPU Limits или же без них лучше? Тема достаточно неоднозначная и стоит всегда учитывать контекст. Например, как быть с нагрузками, чувствительным к задержкам или управляющим слоем SDS, который может сильно деградировать при нехватке процессорного времени? А что вы думаете по этому поводу?

Git-pkgs proxy: защита от атак на цепочку поставок Всем привет! Одной из причин почему атаки на цепочку поставки ПО актуальны, является неконтролируемое обновление пакетов на «новые версии». И уже в этих «новых версиях» может быть много чего интересного. Да, пакетные индексы работают над тем, чтобы удалять такие вредоносные пакеты… Но это случается не сразу и может занимать дни, а то и недели. В текущих реалиях, когда time-to-exploit радикально сокращается благодаря ИИ, это может быть очень критичным. Для того, чтобы хоть как-то систематизировать и контролировать процесс обновлений, можно обратить своё внимание на проект git-pkgs proxy. Суть крайне простая: он представляет из себя proxy, который не даёт обновиться на новую версию пакета в течение X дней. Например, если lodash обновилась до версии 4.18.0, то в вашей сборке всё ещё будет использоваться версия 4.17.21 в течение 3-х дней. Временной интервал можно настраивать, о чём (и не только) подробно расписано в GitHub-репозитории проекта. Утилита работает более чем с 20-ю индексами, среди которых npm, PyPi, Conda, Maven, Debian, Helm и не только. Да, не все они «полностью» готовы, но Автор собирается развивать проект. А как вы работаете с проблемой отсутствия контроля обновления зависимостей?

🛍 Территория мерча БеКон 2026 ОТКРЫТА! 🔥 Забирай фирменный мерч БеКона — собирай пак уже сейчас! 👕 Что в коллекции: Уже знакомые и полюбившиеся позиции + новые лимитированные дропы! 📏 Размеры: от S до 5XL — найдётся на каждого! 📦 Как это работает: Выбираешь товары на сайте и оформляешь заказ. Оплачиваешь онлайн — всё просто и безопасно. Забираешь мерч лично на конференции 2 июня 2026. 📍 Пункт выдачи: г. Москва, ул. Большая Почтовая, д. 40, стр. 7 (локация БеКон 2026) 🎫 Как получить: подойди к стойке выдачи, назови номер заказа — и забирай свой пак! 🤝 Не можешь лично? Передай номер заказа другу или коллеге — доверенность не нужна. ⚠️ Важно знать: • Отмена заказа: бесплатно — строго до 12:00 1 июня 2026 (письмо на bekon@luntry.ru). • Возврат: после получения на конференции возврат не предусмотрен — проверяй размер и комплектацию при выдаче • Брак: если обнаружил дефект — пиши на bekon@luntry.ru до 5 июня включительно, организуем замену 🗓 2 июня 2026 | Москва, Лофт ГОЭЛРО 👉 Собрать свой пак

Cgroups: что это такое и зачем они нужны? Всем привет! Если упростить, то cgroups - механизм ядра Linux, который позволяет управлять вычислительными ресурсами. Казалось бы, всё просто! Но это не совсем так. Если вам хочется более подробно ознакомиться с тем, что это такое и как это устроено, то рекомендуем ознакомиться со статьей (она достаточно объёмная). В ней Автор рассказывает о: 🍭 Том, что такое cgroups и как они устроены 🍭 Том, как происходит управление cgoup’ами, что такое controllers 🍭 Наследовании cgroups и их иерархической структуре 🍭 Недостатках первой версии (cgroups) и причинах появлении второй (cgroupsv2) 🍭 Сравнительном анализе разных версий cgroups и не только Помимо теории в статье есть практические примеры: создание собственной cgroup’ы, блокирование frok-bomb и т.д.. А ещё – немного истории о том, как этот механизм развивался со временем! Рекомендуем!

БеКон 2026: вкуснейшие ингредиенты и лучшие рецепты! Всем привет! Кто-то ждёт лето, кто-то тёплую погоду, кто-то – долгожданный отпуск, а кто-то… Конечно же единственную конференцию по безопасности контейнеров и контейнерных сред – БеКон! В этом году команда Luntry уже в 4-ый раз собирает всех неравнодушных к тематике защиты контейнеров в Москве, 2-ого июня 2026 года! На этот раз нас ждут сразу несколько направлений – Ингредиенты (про технологии) и Рецепты (про людей и процессы). Спикеры из Axiom JDK, ГК АСТРА, Т-Банка, Альфа-Банка, Luntry, Инфосистемы Джет и не только будут делиться своим опытом. Помимо этого, посетителям будет доступна выставочная зона, в которой производители ИБ и ИТ-решений будут рады пообщаться: Штурвал, Deckhouse, Orion Soft, Hexway, Axel PRO и многие другие! И, конечно же, будет ещё один «Секретный доклад». Кто помнит, что было представлено в том году и насколько оно вам понравилось – пишите в комментариях! Детальную информацию о мероприятии, включая описание программы, можно найти на официальном сайте. До встречи на БеКоне! ❤️❤️❤️

Kubernetes: что меняется от Dev до Production? Всем привет! Есть известная фраза, что «Kubernetes – это просто 5 бинарей». С этим сложно спорить. Но это может породить некоторую иллюзию простоты. Поначалу не задумываешься о то, насколько сильно один и тот же Kubernetes-кластер может преобразиться от Development-инсталляции до Production. Именно этому и посвящена статья. В ней Автор описывает про что нужно знать/помнить, чтобы было не очень «больно» в процессе перехода между этими состояниями. Он выделил 7 ключевых возможностей/потребностей: 🍭 Make Infrastructure Repeatable 🍭 Integrate The Product End-To-End 🍭 Move Delivery To GitOps 🍭 Restructure The Repository For Environments 🍭 Add Validation And Policy Guardrails и не только Именно это, по мнению Автора, позволит быть уверенным, что всё либо будет работать, либо можно будет привести в работающее состояние. И, получается, что у нас не просто «5 бинарей», а набор инструментов, процессов и специалистов, которые это всё поддерживают. В самой же статье очень много пояснений и комментариев, а представлена она в формате истории о «переезде», в котором и были учтены пункты, описанные выше. Читается легко и непринуждённо, рекомендуем!

Управление (утекшими) секретами при работе с VCS Всем привет! Рано или поздно, так или иначе, но секреты окажутся в кодовой базе. Но что делать и как быть? Начало ответа на этот вопрос можно найти в статье. Автор рассматривает полный жизненный цикл того, что (не) надо делать при работе с git-репозиториями и чувствительной информацией. Например: 🍭 Stop Hardcoding Credentials in Your Code (кто бы мог подумать). Про переменные окружения и работу с .*-ignore-файлами 🍭 Managing Secrets in Collaborative Environments. Использование Vault и его аналогов 🍭 Detecting Secrets Already in Your Git History. Сканирование репозиториев для выявления секретов 🍭 Review Findings and Remove False Positives. Оценка того, насколько сработки, полученные на предыдущем этапе, актуальны 🍭 Rewrite History with git-filter-repo. Инвалидация секретов, устранение секретов из кодовой базы По каждому разделу даётся небольшой набор рекомендаций и советов о том, что можно делать и каким средством автоматизации можно воспользоваться. В итоге получилась очень хорошая обзорная статья. Особенно для тех, кто только начинает погружаться в тему.

Kunobi: централизованное управление Kubernetes Всем привет! Управление кластерами Kubernetes, их ресурсами и GitOps-практиками через единый удобный, быстрый и красивый web-интерфейс. Примерно так можно описать Kunobi. Из ключевых особенностей можно отметить: 🍭 Локальная установка. Никаких облаков, никаких «внешних соединений» 🍭 Работа с Flux и ArgoCD через привычный интерфейс 🍭 Возможность анализа Helm Releases для идентификации изменений Создание кластеров через UI 🍭 Поддержка нужного ПО «из коробки» (Cert Manager, Prometheus, External Secrets и т.д.) и не только Посмотреть на то, как это выглядит можно по ссылке. Представлены ролики по таким областям, как: Explore/Debug, GitOps, Flux, Workspaces/Presets. Подробности про функциональные возможности можно узнать из документации на Kunobi. И остался вопрос – «Сколько стоит?». Пока что ответ такой: «Free for everyone today. When we launch paid plans, you keep your free tier — no surprises, no credit card required». Напишите своё мнение, если вам уже удалось воспользоваться инструментом: насколько он удобен и полезен?

SmokedMeat: CI/CD Red Team Framework Всем привет! SmokedMeat – open-source проект, который представляет из себя CI/CD Red Team Framework. Сами Авторы описывают его так: «Like Metasploit, but for CI/CD pipelines». Основная задача SmokedMeat – поиск уязвимостей (и их подтверждение) в конфигурациях конвейеров сборки. Можно сказать, что он поддерживает «полный цикл»: 🍭 Analyze. Поиск уязвимостей в настройках конвейера сборки 🍭 Exploit. Эксплуатация найденных на предыдущем этапе уязвимостей 🍭 Post-exploit. Эксфильтрация данных 🍭 Pivot. Попытки расширения области своего присутствия В текущей редакции поддерживается 6 CI/CD решений: GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins, Bitbucket. Для эксплуатации SmokedMeat может использовать следующие техники: PR, issue, comment, LOTP, workflow dispatch. Больше информации о его возможностях, архитектуре, способах запуска можно найти в GitHub-репозитории проекта. Важно(!): это не «пассивный» инструмент. Если вдруг захотите его использовать – лучше делать это с умом и всё перепроверить 😊

Practical Package Security: The Unofficial Guide Всем привет! По ссылке доступен материал от Wiz, в котором ребята рассматривают вопросы обеспечения ИБ при работе с пакетами и пакетными менеджерами. Статья структурирована по разделам: 🍭 Easy(ier) Wins for Package Security. Не обновляться сразу, использовать lockfiles, анализировать пакеты в момент загрузки и т.д. 🍭 Protecting the Execution Environment. Использование эфемерной ИТ-инфраструктуры, соблюдение принципов Zero Trust 🍭 Controlling What Gets Installed. Использование proxy для загрузки пакетов, периодический анализ того, что хранится локально Материал является «общим» и найти конкретных шагов по «безопасной настройке npm» не получится. Однако! В статье собраны основные идеи, из которых можно сделать собственные наборы требований, адаптированные под конкретных технологии.

HPA, VPA или KEDA: что выбрать? Всем привет! Среднестатистический кластер Kubernetes утилизирует 13% CPU и 20% RAM (согласно данным отчёта CNCF 2024 Kubernetes Benchmark Report). 87% остаются «простаивать». Чтобы устранить этот «недостаток» есть 3 autoscaler'a: HPA, VPA и KEDA. Каждый из них решает свою задачу или делает это чуть иначе, чем «сосед». И тут встаёт вопрос: а какой из них выбрать? Как сделать потребление ресурсов максимально эффективным? Чтобы найти свой ответ на этот вопрос можно обратиться к статье. В ней Автор рассматривает: 🍭 Общие принципы работы каждого из представленных autoscaler’ов 🍭 Проводит небольшой сравнительный анализ 🍭 Приводит рекомендации о том, когда можно/нельзя их комбинировать 🍭 Предлагает алгоритм того, как выбрать то, что в большей степени подойдет вам В статье много интересной статистики, примеров и пояснений того, что происходит «внутри». Да, не супер-технически-детально. Но! Для базового погружения – в самый раз!

MOAK: мать всех KEV Всем привет! Mean-time-to-Exploit изменялось от года году. Если раньше для генерации PoC на какую-либо CVE и её успешную эксплуатацию могли потребоваться месяцы, то сегодня время сократилось радикально. Теперь для этого требуются часы, в скором времени, возможно, минуты. Да, речь об использовании LLM для проверки того, что уязвимость эксплуатируема. Для наглядной демонстрации этой гипотезы был создан MOAK. Он представляет из себя агентский workflow, который успешно эксплуатирует 98% CVE, которые есть в базе Known Exploited Vulnerabilities (KEV). Без участия человека. Вообще. Состоит он из следующих агентов: 🍭 Collector. От человека требуется лишь указать номер CVE, а дальше Collector соберёт нужную информацию 🍭 Researcher. Изучает CVE на основании данных, полученных от Collector. Анализирует патчи, идентифицирует уязвимые функции и т.д. 🍭 Environment Builder. Его задача – создание окружения, которое будет подходить под «условия» эксплуатации, определенные его «коллегами» 🍭 Exploiter. «Разработчик» необходимого для эксплуатации ПО и последующая эксплуатация с подтверждением 🍭 Judge. Проверяет, что все остальные агенты «качественно» провели свою работу С «примерами» работы MOAK можно ознакомиться в разделе «CVE Dashboard» на сайте. Там указаны примерные действия, которые делали агенты, успешность эксплуатации и, что самое интересное – время, которое потребовалось для того, чтобы всё это реализовать. И ещё там есть много интересных статей по теме, на которые стоит обратить внимание.

Trailmark: представление кода в виде графа Всем привет! Trail of Bits продолжают радовать интересными open-source проектами. В этот раз команда отдала в сообщество свою разработку – Trailmark. Утилита позволяет превратить исходный код в графовое представление (обогащенный граф вызовов и структуры приложения), к которому можно делать вызовы. В нём вершинами являются функции, методы, классы и другие сущности кода, а рёбрами — связи между ними: вызовы, наследование, вложенность, импорты и т.д. Основной задачей, которую хотели решить ребята, был поиск ответа на вопрос: «Могут ли эти недоверенные входные данные достичь этого участка кода?». Не без использования ИИ, конечно же. У Trailmark есть 3 основные «фазы» работы: 🍭 Parse. Задача фазы – получить информацию о функциях, методах, классах, структурах, интерфейсах и т.д. 🍭 Index. Реализация возможности быстрой работы с графом 🍭 Query. Верхнеуровневый API для взаимодействия с полученным графом На текущий момент реализована поддержка 17 языков, среди которых Python, JS, TS, PHP, Ruby, C, C++, C#, Java, Golang и не только. Установка, настройка, запуск, примеры результатов – всё это можно найти в GitHub-репозитории проекта. Больше информации, включая сценарии использования (да-да, не обошлось без LLM) и skills от Trail of Bits, которые используют Trailmark, можно найти в статье. Рекомендуем!

Безопасен ли код, генерируемый ИИ? Всем привет! Кода, который генерируется ИИ становится всё больше. И его явно будет становиться больше. Но безопасен ли этот код? Можно ли доверять ему «вслепую»? Если вам интересны ответы на эти вопросы, то рекомендуем обратить внимание на вот эту статью. В ней Автор берёт собственный проект, созданный LLM, подключает SonarCloud и получает 234 проблемы на первом же скане. Дальше показывает, как с этим жить обычному вайбкодеру: настраивает конвейер сборки, который блокирует деплой при провале анализа, объясняет принцип работы с инструментами. Статья будет полезна тем, кто активно использует LLM в разработке и хочет понять с чего начать в теме безопасности кода. А что вы думаете по этому поводу? Проводили ли подобные эксперименты?

DefenseClaw: защита агентских AI Всем привет! Недавно Cisco выпустила DefenseClaw – open-source проект, задача которого – повысить уровень ИБ при использовании агентских AI. Он «состоит» из CLI-, написанной на Python, Gateway Sidecar на Golang и TS-плагина для OpenClaw. Если обобщить, то DefenseClaw позволяет: 🍭 Сканировать skills, MCP-серверы, плагины и код перед тем, как они будут запущены 🍭 Анализировать prompts, вызовы, которые будут реализованы инструментами 🍭 Искать секреты, опасные функции, небезопасную десериализацию, паттерны инъекций 🍭 Возможность запускаться в «песочнице» 🍭 Получать полную информацию о том, что происходило В итоге имеем вот такой вот «комбайн», который может как анализировать код, так и поведение используемых агентов. Подробнее о возможностях, настройке и использовании DefenseClaw можно прочесть в документации.