DevSecOps Talks

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’ов
🍭 Проводит небольшой сравнительный анализ
🍭 Приводит рекомендации о том, когда можно/нельзя их комбинировать
🍭 Предлагает алгоритм того, как выбрать то, что в большей степени подойдет вам

В статье много интересной статистики, примеров и пояснений того, что происходит «внутри». Да, не супер-технически-детально.

Но! Для базового погружения – в самый раз!

100 DevOps Projects

Всем привет!

Скоро вторые майские и это значит, что самое время изучить что-то новое. На предыдущей неделе мы писали про 100 Kubernetes Assignments.

На этот раз предлагаем обратить ваше внимание на второй проект Автора – «100 DevOps Projects», который находится в приложении (~ 75 страниц).

В материале можно найти задания по таким темам, как:
🍭 CI/CD Pipelines, GitHub Actions, Jenkins, GitLab CI, ArgoCD и т.д.
🍭 Kubernetes & Container Orchestration. HPA/VPA, настройка кластера с kubeadm, сетевые политики и т.д.
🍭 Infrastructure as Code. Terraform, Ansible, AWS Cloud Formation и т.д.
🍭 Monitoring & Observability. Prometheus/Grafana, ELK Stack, Loki, Jaeger и т.д.
🍭 DevSecOps & Security. Управление секретами, использование SAST/DAST, защита цепочки поставки ПО и т.д.

И это далеко не всё, что предлагает Автор!

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

Как и в предыдущем материале – никакой воды, только задания, задания, задания и ещё раз задания.

Теории, кстати, тоже нет. Поэтому рекомендуем держать «под рукой» документацию на изучаемую технологию.

Поддержать Автора и сказать ему спасибо можно через вот этот вот пост.

P.S. А также желаем вам приятной погоды, солнечного света, попутного ветра и хорошо отдохнуть на грядущих выходных. С Праздником!!!

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 в разработке и хочет понять с чего начать в теме безопасности кода.

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

100 Kubernetes Assignments

Всем привет!

Скоро майские и самое время придаться чтению. А чтению чего-нибудь полезного – ещё лучше!

В приложении можно найти электронную книгу «100 Kubernetes Assignments» (~ 106 страниц).

В ней Автор собрал, да-да, целых 100 заданий, которые помогут вам лучше разобраться в технологии.

Задания разделены на 3 группы: Beginner (1 – 30), Intermediate (31 – 70) и Advanced (71 – 100). Уровень «сложности» заданий и рассматриваемых тем растёт от группы к группе.

Каждое задание включает в себя:
🍭 Понятное и лаконичное описание
🍭 Перечень того, что нужно иметь или сделать для его выполнения
🍭 Пошаговый набор команд для реализации, если у вас не получилось самостоятельно
🍭 Заключение, в котором подводится итог пройденному заданию

Никакой воды, только задания, задания, задания и множество команд. Может быть полезно всем тем, кто только начинает знакомство с Kubernetes.

Важно: никакой теории в материале нет. Поэтому сперва рекомендуем ознакомиться с основными концептами Kubernetes. Например, через официальную документацию.

А если вы хотите отблагодарить Автора, то это можно сделать через вот этот вот пост.

P.S. Желаем вам отличного настроения, тёплой погоды, вкусных шашлыков и отличного времяпрепровождения на майских праздниках! 😊

DefenseClaw: защита агентских AI

Всем привет!

Недавно Cisco выпустила DefenseClaw – open-source проект, задача которого – повысить уровень ИБ при использовании агентских AI.

Он «состоит» из CLI-, написанной на Python, Gateway Sidecar на Golang и TS-плагина для OpenClaw.

Если обобщить, то DefenseClaw позволяет:
🍭 Сканировать skills, MCP-серверы, плагины и код перед тем, как они будут запущены
🍭 Анализировать prompts, вызовы, которые будут реализованы инструментами
🍭 Искать секреты, опасные функции, небезопасную десериализацию, паттерны инъекций
🍭 Возможность запускаться в «песочнице»
🍭 Получать полную информацию о том, что происходило

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

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

wachd: поиск причин проблем с помощью ИИ

Всем привет!

Ещё один вариант использовании ИИ для облегчения задач поиска ошибок.

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

Работает она по следующему алгоритму:
🍭 Получает webhook от Grafana, Datadog, Splunk или любого иного подходящего источника
🍭 Дополучает контекст: логи сообщений, историю потребления ресурсов и т.д. Контекст берётся из промежутка времени, в котором произошел инцидент
🍭 Удаляет всю конфиденциальную информацию перед анализом
🍭 Пытается понять, что именно стало причиной проблемы
🍭 Уведомляет ответственного об инциденте и его возможной причине

Установка, настройка, описание API, инструкции – всё это доступно в GitHub-репозитории проекта.

Open-source версия wachd имеет ограничения в использовании: 1 команда, 5 пользователей, 1000 уведомлений в месяц и возможность использования только Ollama.

k9sight: TUI для работы с Kubernetes

Всем привет!
k9sight – open-source проект, представляющий из себя текстовый интерфейс для работы с ресурсами Kubernetes.

Он позволяет:
🍭 Получать информацию о Deployments, StatefulSet, DaemonSet, Job, CronJob и не только
🍭 Просматривать логи pod, осуществлять поиск и фильтрацию
🍭 Делать exec и port-forward
🍭 Перезапускать ресурсы, изменять количество реплик
🍭 Получать информацию об events, метриках и не только

И самое интересное! Vim-style навигация! Для всех фанатов этого редактора или просто для тех, кто так и не смог из него выйти ☺️

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

А вместе с этим – небольшая (но наглядная) демонстрация его возможностей.

Изменения в NVD, обновление подхода к управлению уязвимостями

Всем привет!

Количество уязвимостей растёт год от года. И сама скорость роста тоже возрастает. В связи с этим недавно NVD объявила о том, что подход к обогащению данными по CVE будет изменён.

Раньше было примерно так: кто-то публиковал CVE, её ID, иногда – CPE, набор ссылок и CVSS, который считался Автором CVE.

NVD, в свою очередь, всё это обрабатывала и стандартизировала: корректный CPE, уточнение CVSS, добавление CWE, группировка ссылок-референсов.

Это позволяло сделать процесс более системным и нормализованным.

Однако, 15 апреля 2026 года подход изменился. Описанная выше работа NVD будет не для всех уязвимостей, а только для части из них.

Например, если CVE есть в KEV. Но таких всего 0,5%. Получается, что в долгосрочной перспективе мы будем получать меньше информации или она будет не так структурирована и информативна.

Что с этим делать и как быть? Мнение на этот счёт есть у Автора статьи.

Он считает, что пора уходить от подхода, где ИБ расставляет приоритеты исходя из характеристик определенной CVE (критичность, CVSS и т.д.).

Получать дополнительную информацию: тот же KEV, информация из EPSS, использование альтернативных источников данных по уязвимостям (GHSA, бюллетени, OSV и т.д.), понимание контекста актива, в котором найдена уязвимость.

Это позволит самостоятельно определить те значимые параметры, которые раньше (пусть и не очень точные) можно было получить от NVD.

И, конечно, не стоит забывать и о runtime-защите, которая позволит поставить «временный патч» и выиграть время для устранения уязвимости в коде.

А что вы думаете по этому поводу? Насколько для вас значимо то, что NVD, со временем, сократит количество предоставляемой информации по CVE?