DevSecOps Talks

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

Композиционный анализ C/C++ проектов Всем привет! Разрешить зависимости, сформировать SBoM, проанализировать его на наличие уязвимостей и обработать их в соответствии с процессами, принятыми в компании. Казалось бы, всё просто! Но дьявол, как и всегда, кроется в деталях. Особенно для C/C++ проектов, где (как правило) нет удобного пакетного менеджера/перечня зависимостей, который может послужить отправной точкой для исследования. Как быть в этом случае? Ответ можно найти в статье от CodeScoring! Ребята рассматривают: 🍭 Как можно выяснить название и версию библиотеки, с какими нюансами можно столкнуться 🍭 Как определить те зависимости, которые попали в конечный артефакт/поставку 🍭 Почему для одного ПО может быть 2 разных SBoM 🍭 Где взять дополнительную информацию о библиотеке перед включением её в SBoM 🍭 Как связать найденные пакеты с уязвимостями, если PURL (не всегда) присутствует и не только Каждый вопрос раскрывается достаточно подробно, с примерами и рекомендациями. Помимо этого, рассматривается очень много различного рода нюансов, с которыми можно столкнуться при композиционном анализе C/C++ проектов. Однозначно к прочтению!

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

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

🔄Поздравляем победителей розыгрыша! Спасибо всем, кто принял участие в наших исследованиях DevSecOps, средств контейнеризации и MLSecOps. Среди участников мы случайным образом выбрали по три победителя: S.kovalenko@e****b.ru @Otopy Dmitry S @AlixThunder @Realmagnum @rlukashenko I.piga***zin@gmail.com +79*****4549 @tempa042 ⚡️Поздравляем! В ближайшие дни свяжемся с победителями и расскажем, как получить призы. А всем участникам спасибо за ответы — благодаря вам мы сможем увидеть реальную картину рынка и понять, куда движутся DevSecOps и MLSecOps.

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

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

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

Насколько хорошо ИИ анализирует код, написанный им же? Всем привет! Автор статьи работает в Greptile, которая занимается разработкой агента для AI Code Review. В процессе работы ему стало интересно, влияет ли используемая модель на то, сколько недостатков находится? Или, если проще, насколько хороши модели в анализе кода, который написан ими же? Для этого он подготовил данные и методологию: 🍭 Собрал данные из 500 PR, которые были написаны с использованием Claude Code и Codex 🍭 «Авторство» модели определялось через данные, получаемые из commit, названий PR и/или веток 🍭 Подготовил перечень дефектов, которые были в этих 500 PR 🍭 Запустил Codex и Claude Code в

/review

3 раза 🍭 «Почистил» результаты от комментариев, которые относились к «стилистике» и не являлись дефектами Что получилось? Оказалось, что модели лучше ищут ошибки в коде, который написан другими моделями. Разрыв не очень большой, но всё же присутствует. Ещё одним интересным наблюдением оказалось то, что модель скорее всего допустит ошибку при разработке, которую она скорее всего пропустит в review. Помимо этого, в статье есть ещё много интересного. Включая дефекты, которые находились при «рассуждениях», но пропадали из «финального вердикта».

MCP Configuration Poisoning Всем привет! Ёмкая статья от Checkmarx, посвященная тому, как можно выполнять произвольный код на рабочей станции жертвы через воздействие на конфигурационные MCP-файлы. Эти файлы содержат информацию о возможных для использования MCP-серверах: наименование, выполняемая команда, аргументы, переменные окружения и т.д. Сама атака состоит в том, чтобы подменить «выполняемую команду» на ту, что нужна атакующему и с большой вероятностью она выполнится. Из плохого – запуск в большинстве случаев может произойти автоматически, без запроса подтверждения пользователем. В некоторых сценариях даже Human-In-The-Loop (HITL) можно обойти. Из хорошего – реализовать это может быть не так просто, т.к. потребует некоторого доступа к данным проекта. В качестве примера реализации Автор приводит Snyk, snyk-agent-scan которых как раз мог «реализовать» MCP Configuration Poisoning(кстати, Snyk сперва не согласился с тем, что это недостаток ☺️). Подобное трудно найти с использованием сканеров. «Ограничивать» команды тоже не всегда представляется возможным. Поэтому в качестве рекомендации Автор предлагает использование «песочниц», мониторинг и контроль выполняемых программ и подтверждение действий пользователем.

AegisBPF: runtime-защита Linux и Kubernetes Всем привет! AegisBPF – open-source инструмент, который позволяет отслеживать и блокировать несанкционированные действия с файловой системой и/или попытки установления сетевых соединений. Для этого он использует возможности BPF и Linux Security Modules (LSM). Из ключевых возможностей можно выделить: 🍭 Использование BPF LSM для блокировки открытия файлов 🍭 Контроль разрешенных IP-адресов, CIDR, портов и т.д. 🍭 Возможность работы в режиме «мониторинга» 🍭 Выгрузка метрик в Prometheus (количество блокировок, статистика) 🍭 Полноценное журналирование активности и не только Возможна установка как на «обычную» Linux-машину, так и в кластер Kubernetes (для этого есть готовый Helm Chart). Для визуализации информации (общие метрики, информация по политикам) можно использовать WebUI AegisBPF. Больше информации, включая данные о потреблении ресурсов в сравнении с Tetragon и Falco, можно найти в GitHub-репозитории проекта.

JWT: уязвимости, атаки и ИБ-практики Всем привет! Сейчас сложно представить веб-приложение, которое не использует JSON Web Token (JWT). Например, для аутентификации. Оттого эти токены и их безопасность – задача достаточно важная. Но какие для них характерны уязвимости, атаки и как сделать их более защищёнными? Ответы на эти вопросы можно найти в статье. В ней Автор рассматривает: 🍭 Что такое JWT, его структура 🍭 Преимущества и недостатки использования JWT 🍭 Наиболее часто встречающиеся уязвимости JWT 🍭 Способы повышения безопасности при работе с JWT Статья написана очень доступным и простым языком. Много примеров, диаграмм и пояснений. Отлично подойдёт как для начала изучения вопроса, так и для систематизации знаний.

Qwen 2.5 7B: «тонкая» настройка для ответов на ИБ-вопросы Всем привет! Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям. В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат. Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?». И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore. Решением стало обучение Qwen 2.5 7B: 🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.) 🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.) 🍭 Тренировка В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье. Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали». А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.

AI агенты для SRE-операций Всем привет! Эксплуатация чего бы то ни было задача непростая, особенно когда возникают инциденты и их приходится решать. Особенно ночью. Или в выходные. При этом процесс (зачастую) носит достаточно системный характер: посмотреть журналы событий, проанализировать метрики, уточнить что было установлено, какие были изменения и т.д. И проблема далеко не всегда в сложности задачи или отсутствии данных для анализа. Скорее наоборот – данных слишком много и тратится много времени на поиск ответов. Это приводит к мысли об автоматизации. Хотя бы в части понимания причины и возможных действий по её устранению. Именно этому и посвящена статья. В ней Автор рассказывает собственный опыт создания системы, которая получает уведомление об инциденте, анализирует данные и предоставляет пользователю сведения о причине и возможных способах решения проблемы. Для этого предлагается 5-и уровневая архитектура: 🍭 Layer 1. Данные. Журналы, метрики, события и т.д. 🍭 Layer 2. Инструменты. Системы мониторинга, логирования, непрерывной сборки, оркестрации контейнеров и т.д. 🍭 Layer 3. «Специалисты». Агенты для работы с инструментами 🍭 Layer 4. Оркестрация. Управление работой агентов 🍭 Layer 5. Люди. Принятие решений, аналитика, отчётность С использованием этой архитектуры Автор реализовал 8 шагов, который автоматизируют процесс работы с инцидентами. Помимо этого, в статье можно найти примеры того, как это работает и перечень технологий, которые позволили реализовать концепт.

Защита CI/CD: опыт Cilium Всем привет! Защита цепочки поставки и окружения сборки/доставки максимально актуальна в настоящее время. Для команды Cilium это крайне важно, т.к. их продуктами пользуются множество компаний по всему миру. Поэтому они достаточно серьёзно подошли к вопросу. И, заодно, поделились своим опытом со всеми желающими. В статье затрагиваются темы: 🍭 Кто может запускать сборки, где они осуществляются 🍭 Использование CODEOWNERS для контроля изменений 🍭 Работа с зависимостями (pinning, обновления и т.д.) 🍭 Статический анализ 🍭 Работа с учётными данными и не только Если нет времени читать всю статью, то вначале есть очень ёмкий tl;dr. Он описывает (в общем) подходы и практики, которые применяет Cilium. Многое «завязано» на возможности GitHub Actions, однако это можно повторить и в других CI-решениях, если сам подход вам понравился.