DevSecOps Talks
6.68K subscribers
63 photos
74 files
1K links
Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"
Download Telegram
Правила для Semgrep от Trail of Bits!

Всем привет!

Ребята из Trail of Bits выложили в открытый доступ еще 35 собственных правил для Semgrep. Всего их теперь 115, ознакомиться с ними можно здесь.

В новой подборке доступны правила для:
🍭 Ruby (большая часть – от Insecure SSL до проверок, связанных с десериализацией)
🍭 HCL (проверка TLS, поиск секретов, соответствие лучшим практикам)
🍭 YAML (большинство за поиск секретов)
🍭 Generic (проверка корректности использования криптографии)

Для каждого правила приводится небольшое описание.

А в завершении – краткий обзор функционала Semgrep (regex mode и поддержка HCL).
Почему Kubernetes не управляет пользователями?

Всем привет!

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

Нет процедур «ввода пароля», нет вкладки «Пользователи», а есть только некий kubeconfig, в котором что-то написано.

Но почему это так? В статье ребята из Armo предлагают свою версию:
🍭 Гибкость, которую надо предоставлять пользователям для подключения удобных им механизмов аутентификации, которые уже есть в компании
🍭 Разные сценарии использования. Кто-то использует bare metal, кто-то облака, кто-то все вместе. И везде будут свои лучшие практики по аутентификации
🍭 Безопасность. Различные стандарты предъявляют много требований к управлению пользователями. В этом случае удобнее и проще воспользоваться чем-то уже существующим

Поэтому (как и всегда) целесообразней не изобретать велосипед, а использовать нечто готовое и проверенное. Главное - сделать "ручку", через которую можно настроить интеграцию.

В заключение статьи разбирается несколько примеров настройки интеграции Kubernetes с Auth-провайдерами и вопросы, связанные с ролевым управлением доступа (RBAC).
Kubernetes Spec: интерактивный режим

Всем привет!

Изучение спецификации (раздела spec) ресурсов Kubernetes может быть не самой простой задачей. Да, есть документация, есть kubectl explain, однако, это не всегда удобно и уж точно не наглядно.

Для того, чтобы решить эту проблему Автор создал Kubespec!

Он содержит:
🍭 Древовидную структуру раздела spec Kubernetes ресурсов
🍭 Описание каждого параметра
🍭 Тип данных параметра
🍭 Изменения в наличии/описании параметра, что происходили от версии к версии
🍭 Небольшие примеры использования
🍭 Ссылки на полезные ресурсы (документация Kubernetes, tutorials)

Все это доступно online и с материалом можно ознакомиться по ссылке выше. Поддерживаются версии Kubernetes: 1.12 – 1.32.

P.S. На текущий момент доступно описание не всех ресурсов, но «основные» - точно на месте 😊
Command Injection в Golang

Всем привет!

Еще одна обзорная статья от SNYK, посвященная вопросам анализа кода. На этот раз, в качестве примера используется Command Injection в Golang.

Статья может быть интересна тем, кто делает первые шаги в AppSec.

Внутри можно найти:
🍭 Что такое Command Injection и почему лучше не допускать его появления
🍭 Примеры реализации уязвимости в Golang
🍭 Способы устранения и контроля

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

Из приятного – все описано очень просто и понятно 😊
Package Analysis

Всем привет!

Еще один материал от команды OpenSSFPackage Analysis! Его задача – анализ пакетов с целью выявления чего-то вредоносного.

Для этого утилита ищет ответы на вопросы: с какими файлами пытается взаимодействовать пакет? Какие сетевые соединения он пытается создать? Какие команды он пытается запустить?

Работает он по следующему принципу:
🍭 Осуществляется мониторинг новых пакетов в repository
🍭 Постановка задачи на анализ пакета (scheduling)
🍭 Анализ пакета различными средствами
🍭 Помещение результатов в BigQuery

На текущий момент поддерживаются NPM, PyPi, RubyGems. Ознакомиться с результатами можно в общедоступном BigQuery DataSet.

«Локальный» запуск также возможен. Информацию о том, как это сделать, можно найти в GitHub Repo проекта.
OCI Runtime Benchmark для Kubernetes

Всем привет!

Kubernetes – наиболее популярное решение, используемое для оркестрации контейнеров. Но если немного абстрагироваться, то сам он делает далеко не все.

Например, жизненный цикл контейнера по большей части управляется Container Rutime Interface (CRI. Например, Docker, containerd).

А что, если «копнуть глубже»? Ведь CRI тоже прибегают к помощи «сторонних сервисов» - OCI Runtime или Container Engine.

Если эта тема вам интересна, рекомендуем ознакомиться со статьей. В ней Автор, после небольшой исторической справки, сравнивает несколько известных OCI Runtime.

В выборку попали:
🍭 runc
🍭 crun
🍭 gvisor/runsc
🍭 youki

Далее Автор написал скрипт, который измеряет параметры запуска 1000 контейнеров из образов busybox.

Полученные результаты, комментарии Автора, «honorable findings» и выводы можно найти в статье.

P.S. Да, возможно не самый лучший benchmark-test (со слов Автора – «This is NOT a scientific benchmark»). А был ли у вас подобный опыт и какой OCI Runtime на ваш взгляд лучше?
Использованием LLM/AI для нужд AppSec

Всем привет!

Использование LLM/AI – вопрос времени. Можно сопротивляться, можно отрицать, но рано или поздно (если не уже) все начнут их использовать в какой-то степени.

В статье Автор предлагает рассмотреть возможность и целесообразность их использования для нужд Application Security. И нет, не для автоматической разметки или чего-то, связанного с работой сканеров. А для… оценки рисков.

Автор реализовал автоматизацию следующих шагов:
🍭 Классификация рисков
🍭 Rapid Risk Assessment (согласно руководству Mozilla)
🍭 Security Review

Единственное, что надо подать «на вход» - техническую спецификацию планируемого изменения. После этого все шаги выполняются автоматически, и пользователь получает готовый отчет.

Пример того, как это работает, можно посмотреть в видео, которое приложено к статье. С точки зрения Автора указанный подход позволяет не заменить, но «дополнить» AppSec-специалиста.

В завершении статьи есть интересный раздел Learning and Observations, в котором описаны нюансы работы PoC и что с ними можно сделать для улучшения результатов.

P.S. А как вы думаете – нужно ли пользоваться LLM/AI для нужд AppSec или все это «только сгенерирует больше шума, который нужно проверять»?
Semgrep Dependency Graph

Всем привет!

Недавно команда Semgrep анонсировала новый функционал их Supply Chain решения, а именно – построение графа зависимостей (dependency graph).

Увы, это не open source (разве что можно попробовать «for free»). Однако, в дополнение к анонсу ребята написали отличную статью, посвященную нюансам анализа open source зависимостей.

В ней предоставлена информация:
🍭 Что такое dependency graph и зачем он нужен
🍭 Как он помогает оптимизировать процесс анализа open source компонентов
🍭 Использование lockfiles – что это и нужны ли они

Все это рассмотрено на понятных и наглядных примерах.

Материал может быть полезен, если вы начинаете разбираться с тонкостями композиционного анализа и вам интересно на что стоит обращать внимание.
Advanced_SCA.pdf
4.1 MB
Advanced SCA от Xygeni

Всем привет!

В приложении доступна небольшая (~ 13 страниц) электронная книга от Xygeni, посвященная композиционному анализу (SCA).

В ней можно найти информацию о:
🍭 Истории развития композиционного анализа от 2000-х до настоящего времени
🍭 Значимости обеспечения ИБ используемых open source компонентов
🍭 Преимуществах использования SCA при разработке ПО
🍭 Наиболее значимых функциях, которые должны быть в SCA-инструментах и не только

Электронная книга небольшая. Но так даже лучше – минимум воды и много полезной информации ☺️
Новая версия DAF!

Привет, друзья! В новый год идём с новой версией фреймворка DAF 😅
В этой версии:
— добавили новый домен "Безопасность заказной разработки"
— добавили новый статус для каждой практики "Не применимо" на случай, если та или иная практика не применима в Компании и не нужно считать степень её выполнения
— актуализировали маппинг практик DAF на SAMM
— сделали маппинг требований DAF на фреймворк AppSec Table Top от уважаемых коллег из Positive Technologies
— добавили "экспериментальные" листы с расчетом FTE для Appsec специалистов и DevSecOps инженеров. ВАЖНО: мы пока прорабатываем оптимальный подход к задаче автоматизированного расчета FTE, здесь всегда будет много разных "но" и "если", мы постарались сделать эти "калькуляторы" наиболее индикативными.

Будем рады вашей обратной связи! И напоминаем, что участие в развитии фреймворка DAF обязательно будет вознаграждено🍺
С Наступающим!!! 🍾🍾🍾

Всем привет!

Сегодня никаких утилит, статей, безопасной разработки, Kubernetes и всего вот этого 😊

Сегодня только поздравления с наступающим Новым Годом и пожелания встретить его в кругу самых родных и близких 🏡

Чтобы Новогодняя Ночь была поистине волшебной 🎄🎄🎄, настроение бодрым, а сердце – умиротворенным 🥛🥛🥛

Самое время отдохнуть, вспомнить что было, подумать о том, что будет, и набраться сил для покорения новых высот в 2025!!!

До встречи!!! Уже скучаем ❤️

Ваша Редакция DevSecOps Talks
Please open Telegram to view this post
VIEW IN TELEGRAM
Helm Dashboard!

Всем привет!

Начинаем 2025 год постепенно, начиная с чего-то простого (не всем же надо с места в карьер 😊). Поэтому сегодня хотим рассказать вам про Helm Dashboard.

Да, все как в названии – это некоторый «графический справочник» по всем установленным Helm Charts.

С его помощью можно:
🍭 Получить информацию о всех установленных charts и их revision history
🍭 Узнать разницу (diff) в манифестах, в сравнении с предыдущими версиями
🍭 Откатиться к предыдущей версии или установить новую
🍭 Сканировать ресурсы с использованием Trivy и/или Checkov и многое другое

Полное описание возможностей Helm Dashboard можно найти тут.

Устанавливается через binary, через Helm Plugin Manager или через Helm Chart, который можно найти в repo.

И в завершении хочется пожелать отличного начала 2025 года, чтобы оно было плавным и максимально приятным ☺️
А так ли всем нужен Kubernetes?

Всем привет!

Не Kubernetes’ом единым! Да, если искать информацию об оркестрации контейнеров, то в 99% (согласно правилу, что 70% статистики берется «с потолка») это будет Kubernetes.

Но, это не единственный оркестратор, который существует. И нет, мы не говорим про различные платформы, построенные «вокруг него».

Например, есть еще достаточно известный, но реже встречаемый в РФ Nomad. В статье можно ознакомиться с опытом небольшой команды о том, как они собираются «переезжать» с Kubernetes на Nomad.

Если кратко, то история следующая:
🍭 Некоторое время все было хорошо, но потом команда столкнулась со сложностями (регулярные проблемы с доступностью узлов оркестратора, технические сложности и задержки в развертывании приложений, регулярные, проблемы с аварийной остановкой pod’ов)
🍭 Поддержка Kubernetes силами небольшой команды оказалась крайне сложной. Казалось, что команда больше времени тратит на инфраструктуру, чем на создание продукта
🍭 Было принято решение о том, чтобы рассмотреть альтернативы. Им стал Nomad. Он проще, он дает нужную гибкость, масштабируемость и т.д. И самое главное – прощай YAML, привет HCL!
🍭 PoC прошло успешно и команда планирует полноценный «переезд»

«Да они просто не умеют правильно готовить Kubernetes» - мысль, которая может посетить при прочтении статьи. Возможно. С другой стороны, а надо ли «преодолевать себя», если рядом есть более простой вариант, который всецело соответствует требованиям?

Может быть не всем нужен Kubernetes? Возможно, что для небольших команд он и правда избыточен и стоит посмотреть на что-то иное? А что вы думаете по этому поводу?
Доступ к удаленным данным на GitHub

Всем привет!

Интересное исследование провела команда Truffle Security (авторы известного решения по поиску секретов – Trufflehog).

Их интересовал вопрос: «Можно ли получить доступ к данным GitHub, которые уже удалены или должны быть недоступны?»

Для этого ребята рассмотрели сценарии:
🍭 Доступ к данным удаленного fork’a
🍭 Доступ к данным удаленного репозитория
🍭 Доступ к данным закрытого (private) репозитория

В итоге оказалось, что да, можно. Не без нюансов, но все-таки.

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

Интересно еще и то, что согласно политикам GitHub все работает так, как и ожидалось. Этому в статье посвящен отдельный раздел.
Анализ кода в Reddit

Всем привет!

В статье описан опыт команды Reddit по созданию собственной AppSec-платформы.

Они хотели, чтобы было:
🍭 Что-то, что настраивается и управляется командой
🍭 Что-то, что позволит быстро подключать новые сканеры
🍭 Что-то, что является централизованным и позволяет быстро вносить изменения
🍭 Что-то, что является масштабируемым, т.к. количество сканирований будет только расти (в Reddit ~ 2000 repository)

Определив «примерные функциональные требования», был выбран и технологический стек: Golang, Async, Redis и Kubernetes.

Что же получилось в итоге? Если кратко, то процесс выглядит следующим образом:
🍭 Разработчик делает commit в repo
Информация о commit направляется в Code Scanner Server
🍭 На основании данных commit’a и метаданных repo подбираются сканеры и их конфигурация
🍭 Сканеры анализируют проект и сохраняют результат

Более полное описание процесса представлено в статье, включаю схему высокоуровневой архитектуры предлагаемого решения. В завершение статьи представлены планы дальнейшего развития получившейся платформы.
Intigriti Hackademy

Всем привет!

Еще одна подборка обучающих материалов, посвященная тематике Web Application Security от Intigriti.

По большей части доступна теория в виде статей и обучающих роликов. За основу взяты угрозы из OWASP Top 10.

Да, «еще один материал», но, возможно, лишним не будет. Да и не это самое интересное!

Помимо указанных курсов команда проводит регулярные challenges, которые можно найти вот тут.

На текущий момент их доступно 38 штук, и они продолжают появляться с определенной периодичностью.

Каждый из них представляет из себя небольшое CTF-задание, которое можно решить самостоятельно или изучить writeup’ы, подготовленные сообществом.
Что такое DevOps?

Всем привет!

Если вам всегда было интересно, и вы боялись спросить… 😊 То вот этот материал может вас
заинтересовать – DevOps Engineering Handbook.

В нем собрано много информации по темам:
🍭 Continuous Delivery & Deployment
🍭 Platform Engineering
🍭 Software Deployments
🍭 Metrics и не только

Данные варьируются в зависимости от раздела. Это может быть общее описание, примеры, средства автоматизации, (анти) паттерны.

Главное, что их много и они хорошо структурированы 😊
Cyclops – UI для Kubernetes

Всем привет!

Небольшой пятничный пост, посвященный еще одной «графической обертке» для KubernetesCyclops. Open Source! Free now and forever!

Если кратко, то он позволяет делать следующее:
🍭 Предоставляет информацию о ресурсах Kubernetes
🍭 Просматривать разницу (diff) в манифестах
🍭 Создавать ресурсы Kubernetes
🍭 Просматривать журналы событий ресурсов кластера
🍭 Изменять параметры конфигурации существующих ресурсов и не только

«В комплекте» идет Cyclops CLI (cyctl), при помощи которой можно автоматизировать действия, доступные через UI.

С подробностями (установка, внешний вид, настройка, расширенное описание возможностей) можно ознакомиться в repo проекта или в документации.
CodeQL: From zero to hero, Part 4

Всем привет!

Продолжение цикла статей, посвященных вопросам использования CodeQL. В первых частях (про которые мы писали тут, тут и тут) Автор рассказывал про то, что такое CodeQL, как он работает и как его можно использовать для поиска ИБ-дефектов в ПО.

Четвертая часть посвящена анализу Gradio:
🍭 Краткое описание что это такое, примеры интерфейсов
🍭 Определение поверхности атаки
🍭 «Моделирование» Gradio с использованием CodeQL
🍭 Поиск уязвимостей, в том числе с использованием Multi-Repository Variant Analysis (запуск query на множестве проектов, подробности можно найти в третьей части)

Статья очень большая и подробная, в ней много примеров кода, отсылок к логике работы CodeQL, комментариев Автора о том, что происходит. Рекомендуем!

P.S. С использованием описанного подхода Автору удалось найти 11 уязвимостей в нескольких Gradio-проектах. Подробнее об этом можно прочесть тут (проще всего искать по имени - Sylwia Budzynska)
Настройка HPA с использованием Custom Metrics

Всем привет!

Одним из преимуществ использования Kubernetes является возможность настройки автоматического масштабирования (как горизонтального, так и вертикального).

По умолчанию горизонтальное масштабирование настраивается с учетом достаточно ограниченного набора метрик – потребление CPU и памяти.

Но что, если хочется большего? Как раз этому и посвящена статья. В ней Авторы демонстрируют как можно «расширить» возможности Horizontal Pod Autoscaler (HPA) через использование произвольных метрик.

Команда предлагает реализовать схему:
🍭 Допустим у нас есть приложение, которое генерирует метрики
🍭 В кластере Kubernetes установлен 🍭 Prometheus, который эти метрики «собирает»
🍭 Prometheus Adapter «забирает» только нужные нам метрики из предыдущего пункта
🍭 HPA принимает решение о масштабировании исходя из данных, предоставляемых Prometheus Adapter

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

В завершении ребята подвергают конструкцию нагрузочному тестированию с помощью Vegeta 😊