DevSecOps Talks Chat

Конфигурация сети в Linux: практика Всем привет! По ссылке доступна лабораторная работа от Iximiuz Labs(Ivan Velichko), в которой придётся поработать с настройкой сети Linux-хостов. Условия простые: есть 2 сервера в одной сети. На одном – Ubuntu, на втором Rocky Linux. Надо проанализировать их конфигурацию и ответить на вопросы. Примеры вопросов: 🍭 Какие названия у основных сетевых интерфейсов 🍭 IPv4/MAC-адреса рабочих станций 🍭 IPv4 адрес шлюза по умолчанию 🍭 Через какой интерфейс пакеты отправляются на указанный адрес и т.д. Да, задания достаточно базовые, но! Это те знания, которые точно пригодятся, ведь без понимания работы сетей – никуда. И если вы начинаете с этим работать, то лабораторные – то, что надо. Для запуска не требуется ничего устанавливать, всё доступно непосредственно на сайте в интерактивной «площадке». P.S. Помимо этой лабораторной, на labs.iximiuz.com можно найти ещё очень много всего интересного – рекомендуем!

Patch The Planet Всем привет! В интернете можно найти много статей, в которых описано, что «классический» подход к управлению уязвимостями перестаёт работать. В том числе это связано с развитием ИИ. Уязвимостей находят больше, быстрее, формирование exploit’ов сократилось с месяцев/недель до часов. Чтобы хоть как-то изменить/улучшить ситуацию OpenAI объединили усилия с Trail of Bits и реализовали инициативу Patch The Planet. Её суть в том, чтобы, используя передовые AI модели и экспертный опыт людей, находить уязвимости и создавать обновления в ПО для их устранения. Т.е. maintainer’ы не просто получают «У вас уязвимость, вот так воспроизвести», а полноценные рекомендации по устранению. Команда Patch The Planet активно работает с проектами и помогает тем, кто их разрабатывает. В статье можно прочесть о том, как это примерно работает, какие проекты уже вошли в инициативу, какие ИБ-практики применяются. А если вам хочется посмотреть на результаты, то рекомендуем обратить внимание на Patch The Planet Dashboard, в котором всё наглядно видно.

KubeBuddy: анализ ресурсов Kubernetes Всем привет! KubeBuddy – CLI-утилита, которая анализирует общее состояние кластера как со стороны ИТ, так и со стороны ИБ. Реализованы проверки для: 🍭 Статусов узлов, потребления ресурсов, состояния pod 🍭 Идентификации pod с ошибками, перезапусками 🍭 Выявления небезопасных привилегий в RBAC 🍭 Хранилищ, сервисов, сетевых политик и не только В результате работы KubeBuddy генерирует отчёт в одном из форматов на выбор: HTML, Text, CSV. А если вы используете Headlamp, то у KubeBuddy есть плагин, который позволяет отображать результаты его работы непосредственно в UI. Больше информации о возможностях утилиты, способах отображения информации, запуске, настройке и проверках можно найти в GitHub-репозитории проекта или в официальной документации.

Pluto AI: анализ безопасности кода Всем привет! Сегодня хотим рассказать про ещё один сканер безопасности, использующий возможности AI – Pluto AI. Он был разработан в качестве курсовой работы группой энтузиастов. Процесс работы с ним достаточно простой: 🍭 Загрузка исходного кода напрямую или через ссылку на репозиторий 🍭 Анализ с использованием AI 🍭 Классификация сработок: критичность, CWE и т.д. 🍭 Вычисление уровня риска от 0 до 100 🍭 Генерация отчёта для предоставления всем заинтересованным Его «AI-движок» позволяет находить 12 типов ИБ-дефектов: SQLi, XSS, использование жёстко закодированных паролей и т.д. В качестве основной модели используется Gemini 1.5. Помимо этого, Pluto AI генерирует рекомендации по устранению ИБ-дефектов и может «общаться» с пользователем через встроенный чат. Вряд ли стоит ожидать от него чего-то сверхъестественного, но для ознакомления и изучения «внутренностей» может подойти.

Метрики масштабирования в Kubernetes Всем привет! (Автоматическое) масштабирование – крайне интересная тема. На первый взгляд она кажется достаточно простой. Но лишь на первый, пока не начнутся вопросы. Масштабироваться реактивно? Проактивно? Как долго оставлять «неиспользуемые» ресурсы? Как контролировать масштабирование, чтобы оно не вышло из-под контроля?.. Автор статьи предлагает рассмотреть 5 метрик, которые могут помочь сделать процесс контролируемым. Среди них: 🍭 Committed capacity percentage. То, насколько используются существующие мощности 🍭 Error rates. Что происходит в момент масштабирования? 🍭 Mean Time to First Byte (MTFB). Как много проходит времени с момента принятия решения о масштабировании до выполнения полезной работы сервисом, ресурсы которого масштабируются? 🍭 Application disruption. Влияет ли масштабирование на нарушение работоспособности запущенных приложений 🍭 Application churn. Что происходит, если средство масштабирования определяет потребность в 2,5 реплики, но такого быть не может? По мнению Автора, отслеживание этих метрик может помочь оптимизировать процесс (автоматического) масштабирования. Увы, статья детально не раскрывает каждую метрику в отдельности… Но! Автор собирается сделать это в отдельных статьях. Помимо самих метрик в материале очень много интересных рассуждений на тему оптимального использования ресурсов. Рекомендуем!

Анализ зависимостей и инструментария разработки ПО Всем привет! Анализ ПО начинается не с запуска сканеров, а с понимания того, что это такое, как это устроено, как собирается, как тестируется и т.д. Т.е. с некоторой метаинформации о проекте. Собирать её можно разными способами. Можно «в ручном режиме», а можно с использованием средств автоматизации. Несколько полезных утилит, которые помогут решить задачу, сделал Andrew Nesbitt (мы писали про его статью, посвященную модели угроз пакетных менеджеров). Первая – brief – используется для получения информации об используемых языках, пакетных менеджерах, тестах, сборке, количестве строк и т.д. Вторая – git-pkgs – позволяет анализировать используемые зависимости, в том числе по всей git-истории. Основными её командами являются list, history, blame, diff и т.д. Они позволяют быстро получить ответ на вопрос «откуда эта зависимость появилась в проекте». Обе утилиты ничего не «додумывают». Фактически, они собирают информацию, которую могут получить за счёт анализа репозитория. Подробности, параметры установки/запуска и примеры содержания генерируемых отчётов можно найти в GitHub-репозиториях или в документации.

Vaikora LLM Gateway Всем привет! С повсеместным использованием AI-агентов всё чаще встречается вопрос, связанный с информационной безопасностью. Это породило создание отдельной группы инструментов, задача которых – контролировать происходящее. Vaikora LLM Gateway является представителем этой группы. Если просто, то он «находится» между AI-агентами и «конечными системами» (LLM, базы данных, MCP, API и т.д.). Его задача состоит в перехвате каждого действия, которое хочет совершить агент и анализе его на соответствие определённому набору политик. Каждому действию присваивается статус: ALLOW, ALLOW_LOG, CONSTRAIN или BLOCK. На текущий момент Vaikora LLM Gateway работает со следующими LLM: OpenAI, Anthropic, Google Gemini и OpenRouter. Политики позволяют обнаруживать разные активности: утечку конфиденциальной информации, jailbreak, prompt injection и не только. Сам по себе «движок правил» является детерминированным и не использует нейронные сети, что позволяет получать идентичные результаты на одни и те же действия. Подробнее о возможностях утилиты можно прочесть в GitHub-репозитории проекта.

Platform Skills Всем привет! По ссылке доступен GitHub-репозиторий, в котором можно найти внушительный набор skills для работы с элементами ИТ-инфраструктуры и безопасности. Поддерживаются такие системы как: Kubernetes, Argo CD, Flux CD, Terraform, Kyverno, Trivy, Kingfisher и многие другие. Для каждой из поддерживаемых систем определён набор skills и возможностей. Например, можно создавать, тестировать и проводить аудит политик Kyverno. Или мигрировать их на новый CEL-синтаксис. Запускать сканирования Trivy, осуществлять поиск проблем и их причин в кластере Kubernetes, создавать роли т.д. Полный перечень доступных команд можно найти в файле COMMANDS.md. Указанный набор skills доступен для GitHub Copilot, Claude Code, Codex, Cursor. Больше информации о возможностях skills, их устройстве, запуске и результатах работы можно найти в GitHub-репозитории проекта.

AI Coding Agent Security Benchmark Всем привет! Команда Endor Labs задалась вопросом насколько хорошо AI пишет безопасный код. Для этого они провели анализ 13 агентов и моделей с использованием SusVibes Benchmark. 200 задач из 108 open-source проектов, написанных на Python. При этом измерялась не только безопасность, но и корректное (ожидаемое) функционирование результата. Из ключевых результатов можно отметить: 🍭 Существует «разрыв» между корректным функционированием и безопасностью 🍭 Модели стали сильно лучше писать код с точки зрения работоспособности, но не безопасности 🍭 Агенты «жульничают» 😅 Да, бывало так, что они просто находили подходящее решение вместо reasoning 🍭 Одна и та же модель может вести себя по-разному при работе с разными агентами 🍭 Та модель, что лучше всех справляется с функциональной частью может быть не самой лучшей с точки зрения ИБ И это далеко не всё, что есть в исследовании. Рассматривались следующие модели: Claude Sonnet, Kimi, Gemini, GPT. Кто и в чём победил? Ответы есть в статье, как и множество деталей о проведённой работе. Рекомендуем к ознакомлению! P.S. Материал опубликован в апреле и уточнён в мае 2026 года. Это важно учитывать, ведь, увы, подобные исследования «устаревают» достаточно быстро. Но! Это не делает их менее интересными ☺️

Стройте графы через joern для java и проверяйте достижимость