DevSecOps Talks

Infralens: анализ service-to-service взаимодействия Всем привет! Infralens – open-source проект, который использует eBPF для автоматического обнаружения и визуализации взаимодействия service-to-service в кластерах Kubernetes. Из ключевых функций можно отметить: 🍭 Отсутствие инструментации: никаких sidecars, изменения кодовой базы 🍭 Отображение топологии в режиме реального времени 🍭 Поддержка IPv4 и IPv6 🍭 Аналитика потребляемых ресурсов (CPU, RAM) узлами кластера 🍭 Интерактивная визуализация и не только Кроме этого, Infralens позволяет генерировать автоматическое описание используемых сервисов при помощи AI. Такая документация включает в себя: что делает сервис, какие используются технологии для его создания, описание сетевого поведения и т.д. Подробности про возможности Infralens, его архитектуру, способы установки и настройки можно найти в GitHub-репозитории проекта.

Kubelet: зачем он нужен и как устроен Всем привет! Kubelet – основной «агент» узлов кластера, который отвечает за жизненный цикл запускаемых на нём pod’ов. Поэтому понимание принципов его работы крайне важно. Особенно, если pod постоянно находится в состояниях Pending или ContainerCreating. Помочь в этом сможет статья, в которой Автор сделал очень неплохой «обзор» на Kubelet. Материал содержит разделы: 🍭 Архитектура Kubelet 🍭 Основные (core) компоненты Kubelet 🍭 Описание процесса создания pod Механизм синхронизации 🍭 Описание основных причин «падения» контейнеров и не только Очень много различных схем, диаграмм последовательностей, примеров команд, позволяющих разобраться в происходящем. Самое «то» для того, чтобы лучше представлять себе процесс создания pod и его основных «участников».

Атака на цепочку поставки: LiteLLM Всем привет! Атака на Trivy – вероятно самая обсуждаемая тема нескольких последних недель. Но не ей единой. Компрометации подверглась и LiteLLM. 47 000 скачиваний уязвимых версий (1.82.7, 1.82.8) за 46 минут. Вредоносное ПО делает следующее: 🍭 Сбор чувствительных данных (SSH-ключи, информация из конфигурационных файлов, shell-история и т.д.) 🍭 Собранные данные зашифровываются и передаются на https://models.litellm.cloud 🍭 Кроме этого, если присутствует Kubernetes Service Account Token, то вредоносное ПО пытается получить доступ о всех секретах кластера и создать pod и сделать некоторый mount на узел кластера Подробнее об атаке на LiteLLM можно прочесть в статьях: первая посвящена общему анализу и хронологии событий, вторая – описанию вредоносного ПО.

Митап по DevSecOps от СyberCamp — скоро начинаем 😄 😎😎😎😎😎 😎😎😎😎😎 Подключайтесь к трансляции в VK Видео в 12:00 МСК. Топовые ведущие — Полина и Антон! Вместе с нашими гостями поговорим про: 12:10 SAST в DevSecOps 12:50 Моделирование угроз при разработке ПО 13:25 Композиционный анализ ПО 14:05 Будни AppSec 15:20 Анализ состава образов контейнеров 15:50 Защиту мобильных устройств 16:30 Динамический анализ ПО 17:25 Масштабирование анализа уязвимостей в AppSec 18:10 Безопасность контейнерной инфраструктуры Смотрите эфир в VK Видео, задавайте вопросы спикерам и следите за событиями митапа в чате комьюнити CyberCamp. ⚠️ Киберучения на платформе Jet CyberCamp стартуют завтра в 10:00 МСК. Сегодня мы пришлем всем участникам инструкцию по доступу — скачайте заранее необходимые для заданий материалы. 🧿 Регистрация l 👋 Комьюнити 🥰 Буст для чата

Изучаем Istio: the Hard Way Всем привет! Если вы хотели притронуться к технологии Service Mesh и руки всё никак не могли дойти, то, возможно, эта статья сможет вам помочь. В ней Автор на примере Istio разбирает что это такое, как это работает и как настраивается. Статья содержит разделы 🍭 Описание «лаборатории» (все материалы можно найти в этом репозитории) 🍭 Краткое описание логики работы Istio Управление трафиком (VirtualServices, DestinationRules, Subsets) 🍭 Реализация ZeroTrust-концепта с использованием mTLS 🍭 Балансировка нагрузки и не только Краткое описание того, что происходит приводится в статье. Если нужно больше информации (например, для самостоятельного воспроизведения), то её можно найти в GitHub-репозитории.

Поиск вредоносных contributors в open-source: опыт DataDog Всем привет! DataDog – компания, которая много сил вкладывает в развитие open-source. Включая собственные разработки, которые ребята дают миру. Когда «идешь в public» - будь готов к тому, что тебя могут «исследовать» и пытаться атаковать. DataDog – не исключение. Supply chain атаки особенно популярны в наше время: от «воздействия» на название PR до различного вида инъекций, в результате чего может быть украдена информация, подменён артефакт и т.д. Недавно мы писали о BewAIre – наработке Компании, которая позволяет определить, является ли PR вредоносным или нет. Ребята пошли дальше и теперь направляют результаты работы BewAIre в свой SIEM для последующего реагирования со стороны их SIRT-команды. И именно это помогло им найти несколько атак на их open-source проекты. Случилось примерно следующее: 🍭 BewAIre указал на то, что один из PR в IaC Scanner (который, кстати, open-source) может быть вредоносным 🍭 Команда отреагировала и выяснила, что злоумышленник пытался внедрить вредоносный код в название файла 🍭 Инъекция заключалась в том, чтобы скачать подконтрольный злоумышленнику файл и выполнить его 🍭 На этом приключение не закончилось. Спустя несколько часов было открыто несколько issues, в описании которых содержался prompt injection Хорошие новости в том, что подход DataDog показал свою результативность на практике и действия злоумышленника удалось предотвратить. Что было в том prompt injection и что за файл надо было скачать и запустить – обо всём этом и не только можно прочесть в статье. Timeline, анализ действий злоумышленника, используемые им подходы, рекомендации по повышению уровня безопасности – всё на месте! Рекомендуем!

Trajan: анализ безопасности CI/CD Всем привет! Trajan – open-source утилита от Praetorian, которая позволяет анализировать настройки CI/CD и идентифицировать в них ИБ-дефекты. «Из коробки» доступна следующая функциональность: 🍭 32 плагина для идентификации небезопасных настроек 🍭 24 плагина для идентификации атак 🍭 Несколько «режимов работы»: enumerate, scan и attack 🍭 Наличие графического web-интерфейса На текущий момент поддерживается GitHub Actions, GitLab CI, Azure DevOps и Jenkins. Количество плагинов для идентификации небезопасных настроек и атак варьируется в зависимости от рассматриваемой CI-системы. Больше подробностей про проект можно найти в GitHub-репозитории или вот в этой статье от Авторов Trajan.

Видеообзор с инструкцией по использованию DAF Всем привет! Мы стараемся сделать наш фреймворк понятным и доступным, поэтому решили записать небольшой видеоролик, в котором разбираем все основные компоненты DAF, рассказываем как им пользоваться и на что обращать внимание. Осветили в обзоре следующие пункты: - описание фреймворка на github - все вкладки фреймворка, их структура и назначение - принципы и процесс заполнения практик на листе "Практики", интерпретация результатов заполнения. Пишите нам обратную связь по ролику и дайте нам знать, что еще хотелось бы увидеть в следующих роликах!

SecScore: оценка безопасности сборки Всем привет! SecScore – open-source утилита, которая позволяет описать правила (не) прохождения сборки, основываясь на критериях. Да, по факту это некий аналог Security/Quality Gate. Работает это примерно так: 🍭 Вы определяется «оценку», по достижении которой сборка считается «неудачной» (например, 100) 🍭 Для разных уровней критичности определяются свои веса (например, High – 20, Medium – 7 и т.д.) 🍭 Кроме этого, можно указать «Hard Fails» - т.е. нечто, чего попросту не должно быть. Да, даже если «оценка» не достигнута 🍭 Дополнительно можно указать условия. Например, реагировать только на новые ИБ-дефекты По результатам работы, в том числе, создается комментарий в PR. В нём отображается информация о «принятом решении» и причины, на основании которых оно было сделано. Больше подробностей о SecScore можно прочесть в GitHub-репозитории проекта.

Gateway API Benchmarks Всем привет! Вопрос замены Ingress NGINX на нечто иное становится важнее день ото дня. Недавно был выпущен его финальный релиз, а в скором времени проект перейдёт в статус Archive. Одной из возможных замен является Gateway API. Но какую реализацию выбрать? Возможно, что вот это сравнение сможет вам помочь. В нем Авторы сравнивают реализации: 🍭 Agentgateway 🍭 Envoy Gateway 🍭 Istio 🍭 Kong 🍭 Traefik 🍭 Nginx (да, он все еще попал в сравнение) Помимо общих результатов сравнения, для каждого из «участников» приводятся некоторые нюансы, на которые стоит обратить внимание. Тесты, цифры, графики, информация о потреблении ресурсов, данные о производительности и не только – всё это можно найти в сравнении. P.S. По прямой ссылке доступна первая версия. К результатам второй версии можно попасть через ссылку, доступную в репозитории.

Superuser Gateway: опыт Uber Всем привет! Управление привилегированным доступом – задача крайне важная. Одна ошибка и ты ошибся. При этом, результаты могут быть достаточно «неприятные». Типовой процесс работы, зачастую, выглядит следующим образом: пользователь подключается с учетной записью супер-пользователя, выполняет команды, отключается. Но у такого процесса много недостатков, как минимум, связанных с ошибками человеческого фактора. Чтобы сократить вероятность того, что «что-то пойдет не так», команда Uber сделала Superuser Gateway. С его использованием процесс стал иным: 🍭 Инженер запрашивает выполнение команды с использованием CLI 🍭 Вместо «прямого выполнения» создается PR в определённом репозитории 🍭 Осуществляются проверки, включая review со стороны другого инженера 🍭 Как только PR согласован, он выполняется с использованием средств автоматизации Superuser Gateway состоит из нескольких компонентов: CLI-утилиты, git-репозитория, набора CI-jobs и сервиса, который имеет «право» выполнять команды. Подробнее о том, как устроен сервис, какие проверки реализованы и как это «выглядит» можно узнать в статье.

K8sQuest: интерактивное обучение по Kubernetes Всем привет! K8sQuest – это набор лабораторных работ (заданий) по Kubernetes, которые помогут научиться искать ошибки в кластере. K8sQuest предоставляет интерактивный интерфейс (терминал), подсказки, пошаговые инструкции о том, как проходить задания, возможность «сброса» уровней, если застряли и, конечно же, achievements! Куда без них! Задания разделены по «мирам»: 🍭 Core Kubernetes Basics 🍭 Deployments & Scaling 🍭 Networking & Services 🍭 Storage & Stateful Apps 🍭 Security & Production Ops Каждый мир имеет свой набор заданий, количество получаемого «опыта» и уровень сложности. Всего заданий – 50 штук. Подробнее о заданиях можно и о том, что вас ожидает можно прочесть в GitHub-репозитории проекта. И, что самое классное – устанавливается всё локально, не нужно никаких «облаков»!

Docker Time Machine Пятница! Самое время для совершения путешествий во времени! И Docker Time Machine (DTM) может в этом помочь. Эта утилита автоматизирует процесс анализа различных версий (тэгов) одного и того же образа контейнера. Может работать как с реестром (скачивается только meta-информация об образе), так и с git-репозиторием (для каждого commit создается образ и осуществляется сравнение). DTM позволяет: 🍭 Осуществлять «послойный» анализ образов 🍭 Идентифицировать изменения в размере образов 🍭 Найти самый «толстый» образ из доступных 🍭 Найти самый «худой» образ из доступных Результаты работы утилиты «упаковываются» в JSON, CSV, MD или в лаконичный HTML, наглядно отображающий то, как менялся образ. Подробности о возможностях Docker Time Machine, об использовании и примеры результатов можно найти в GitHub-репозитории проекта.

DevSecOps митап на CyberCamp! 27 марта в 12:00 МСК С прошлого DevSecOps митапа CyberCamp прошло целых три года, огромное количество событий успели произойти за это время, вышли новые фреймворки и инструменты DevSecOps, изменились подходы к анализу кода и процессам безопасной разработки. И все эти изменения будут освещены на самом большом митапе в истории CyberCamp! Интересные доклады, практические задания, море интерактива ждут тебя, дорогой читатель, как онлайн, так и в оффлайн-студии! Спикеры: 😎 Антон Михайлов, SAST в DevSecOps: от «сканера в пайплайне» к управлению риском релиза 😎 Женя Богачев, Моделирование угроз как фундамент безопасной архитектуры ПО 😎 Антон Володченко, Композиционный анализ: из чего состоит и как помогает? 😎 Антон Гаврилов, 6 дней AppSec 😎 Полина Соломенцева, В одном далеком-далеком контейнере... 😎 Юра Шабалин, Безопасность мобильных приложений в РФ: риски, требования и практики защиты 😎 Сева Шамов, Runtime — наше всё: как мы ищем уязвимости динамически и какие инструменты используем 😎 Саша Бакин, AppSec под нагрузкой: масштабирование анализа кода в условиях ограниченных ресурсов 😎 Дима Евдокимов, Путеводитель по безопасности контейнеров и Kubernetes 27 марта в 12:00 МСК! 🧿 Регистрация l 👋 Комьюнити

Multi-Cluster Scaling: опыт Kedify Всем привет! Зачастую, кластер Kubernetes существует в единственном числе недолгое время. Рано или поздно кластеров становится несколько. Например, из-за технических (сокращение задержки), организационных (отдельный кластер под определённую команду) или регуляторных (сокращение «области действия» требований) причин. И тут начинается самое весёлое: всё, что было сделано для того «первого» кластера надо отмасштабировать на остальные. И не только отмасштабировать, но и централизованно управлять всем этим, что приводит к «двойной работе». В статье от Kedify описан подход, который использовала команда, чтобы решить эту задачу. Если кратко, то всё просто: создание единого «мозга», который всем управляет. Но дьявол в деталях! Ребята используют один KEDA-кластер, который анализирует метрики и взаимодействует с Member-кластерами через kube-apiserver. Member-кластеры, в свою очередь, создают необходимые нагрузки и всё это с минимально-необходимыми правами. Для того, чтобы KEDA-кластер мог управлять Member-кластерами команда сделала свой CRD - DistributedScaledObject. Он определяет, на каких Member-кластерах можно создавать ресурсы, что делать в случае их недоступности, как собирать информацию о «здоровье» и т.д. В итоге получается конструкция, которая позволяет управлять несколькими кластерами Kubernetes «на масштабе» и может работать в случае недоступности некоторых Member-кластеров. Больше информации, как обычно, можно найти в статье.

Использование AI агентов для исследования CVE Всем привет! В статье от Praetorian описан концепт, в котором AI агенты используются для автоматизации процесса исследования уязвимостей (CVE). За основу взят Google’s Agent Development Kit (ADK), который «координирует» весь процесс, состоящий из 4-х шагов. Шаги представляют из себя: 🍭 Deep Research. Получение максимального количества информации о CVE 🍭 Technology Reconnaissance. Определение технологий, которые могут быть «подвержены» CVE 🍭 Actor-critic Template Generation. Формирование Nuclei Template на базе собранной информации 🍭 Exploitation Analysis. Анализ векторов атак, возможных техник, ущерба и т.д. На выходе, в идеале, получается Nuclei Template, который можно использовать для проверки того, подвержен ли сервис X уязвимости Y. Для каждого этапа вышеописанного процесса используются различные модели. Т.е., в зависимости от решаемой задачи, выбирается «оптимальный инструмент». Больше подробностей, включая краткое описание того, как это используется, можно найти в статье.