DevSecOps Talks

Fuzzing на примере использования libFuzzer Всем привет! Fuzzing – интересная, но далеко не самая очевидная тема, особенно «в начале пути». Чтобы чуть упростить погружение предлагаем Вашему вниманию статью. В ней собрана как теоретическая информация, так и пара практических примеров. Рассматривается следующий «процесс»: 🍭 Инструментация. Грубо говоря – добавление в код или в исполняемый файл средств, которые позволяют понять какие части кода были выполнены в момент тестирования (code coverage) 🍭 Генерация входных данных. Первичные данные, которые будут использованы в дальнейшем – можно генерировать как «руками», так и с использованием средств автоматизации 🍭 Мутация входных данных. Генерация новых тестовых данных за счет изменения существующих 🍭 Тестирование. Применение сгенерированных тестовых данных для анализа программного обеспечения 🍭 Сбор обратной связи. Анализ code coverage, запуск повторных тестов для получения лучшего результата Для указанного выше «процесса» Автор статьи создает PoC на примере минималистичного приложения, написанного на C++. Второй пример чуть интереснее: в качестве «подопытного» выступает библиотека libxml2. Комментарии, код, описание, результаты – все на месте!

Написание Semgrep-правил: основы Всем привет! В статье описываются основы написания собственных правил анализа исходного кода с использованием Semgrep. Например: 🍭 Поиск patterns 🍭 Адаптация patterns для более точного поиска 🍭 Написание правил для поиска ошибок аутентификации в API Endpoints 🍭 Передача пользовательских данных в качестве параметров в os.system() и не только Для каждого правила приводится его описание и пример реализации, а также результаты которые оно сможет найти.

Minder: защита repos, артефактов и зависимостей Всем привет! Minder – open source проект от Stacklok, которые позволяет повысить уровень защищенности Компаний против software supply chain атак. Пока что решение работает только с GitHub, однако в планах есть и такое «In the future, Minder will support other source control and artifact repositories». Основными функциями являются: 🍭 Управление конфигурациями repo, параметрами его безопасности 🍭 Аттестация артефактов: контроль подписей артефактов, их целостности 🍭 Управление зависимостями: за счет интеграции с Trusty (общая информация по пакету), Minder позволяет реализовать policy-driven подход к управлению зависимостями (например, на основании уровня риска) 🍭 Уведомления: отправка сообщений о нарушениях политик или auto remediation (там, где это возможно) Представляет из себя cli-утилиту и сервер, обрабатывающий запросы. Сервер может быть облачным (только для public repo), а если надо – можно развернуть его локально. Web-интерфейс отсутствует, только консоль и, конечно же, YAML! (возможно, кто-то сделает видео со Стивом Балмером, где он говорит YAML, YAML, YAML, YAML… 😊) Процесс работы примерно такой: установка Minder, регистрация repository, создание profiles и rules (с перечнем из коробки можно ознакомиться тут) с последующим применением и анализов результатов. Можно создавать свои правила, подробнее про это написано в статье. И, как всегда, больше подробностей можно найти в документации. Важно: пока что Minder (кстати, как и Trusty), находится в стадии «experimental»

Git, SVN и все все все Всем привет! В последние годы мы все чаще сталкиваемся с необходимостью замены устаревших решений на более современные. Одно из таких решений - Subversion, когда-то бывший(а для кого-то и сейчас являющийся), конкурент Git. Git стал де-факто индустриальным стандартом, многие разработчики умеют работать только с ним. Возникает вопрос миграции В статье от разработчиков Git достаточно подробно описывается: 🍭Как мигрировать с Subversion, Mercurial и Perforce в Git 🍭Как перенести коммиты, чтобы разработчики и не заметили 🍭Как автоматизировать эти задачи

Bash Golf Всем привет! В современном мире господствующего DevOps'а каждый пишет множество скриптов. Каждый из них, по сути, маленькая программа, как и завещали нам отцы Unix. В цикле статей автор предлагает свои "маленькие программы" и хитрости на языке Bash для решения различных задач. 🍭 Умеет ли Bash отправлять TCP запросы без дополнительных утилит? 🍭 Есть ли встроенная переменная, со случайным числом? 🍭 Как экспортировать функцию в xargs? Прочитать все части цикла можно по ссылкам ниже. Часть 1 Часть 2 Часть 3

DevNetOps Всем привет! Автоматизация управлением сетевыми железками всегда вызывала много вопросов. Есть несколько решения: 🍭 Вендорские решения - предлагают большую функциональность, однако и стоят они достаточно дорого. 🍭 Скрипты и костыли - популярное решение, к которому приходит со временем каждый админ. Но мир движется вперед. IaC и GitOps приходят из мира IT и в мир сетей. Профильные издания уже по полной используют термин DevNetOps. В статье автор попытался разобраться, как можно управлять сетевыми устройствами из пайплайнов, на примере GitlabCI и Arista cEOS.

Советы по Custom Controller для Kubernetes Всем привет! «В любой непонятной ситуации – пиши свой operator!». Как и в любой шутке, в этой есть доля правды, ведь Kubernetes Operators крайне сильный инструмент, который позволяет расширить функциональность Kubernetes так, как нужно именно Вам. Однако, разработка operators, поначалу, может быть не очень понятной и простой. Сегодняшняя статья направлена на то, чтобы немного упростить порог вхождения. В ней собраны следующие советы: 🍭 Обработка ресурсов, помеченных для удаления 🍭 Фильтрация событий, влияющих на реконсиляцию 🍭 Binding ресурсов с использованием ownership 🍭 Запись событий 🍭 Проверка того, запускается ли operator в Red Hat OpenShift и не только Всего в статье собрано 8 советов, для каждого из которых приводится описание, потребность в использовании и, конечно же, примеры исходного кода с пояснениями.

DevSecOps Pipelines Всем привет! Неплохой long read на предстоящие выходные! Если верить «оценке», то потребуется ~ 53 минуты, чтобы прочесть статью. В ней собраны примеры исходного кода на Python, которые можно использовать для запуска анализаторов и последующей обработки результатов. Например: 🍭 Создание и анализ проекта с SonarQube (взаимодействие через REST API) 🍭 Анализ кода с использованием Semgrep (взаимодействие через cmd) 🍭 Запуск сканирования web-приложения с использованием ZAP 🍭 Анализ образов контейнеров с использованием Trivy 🍭 Запись и получение секретов из HashiCorp Vault через hvac 🍭 Подпись артефактов и еще много-много-много чего, рекомендуем ознакомиться лично Для каждого сценария приводится описание workflow и небольшие рекомендации как можно его улучшить. Например, анализировать результаты, отправляя их в сторонние системы с использованием того же REST API. В материале нет ничего революционного: если вы писали собственные jobs с проверками, то увидите знакомые команды. Однако, приятно, когда все «под рукой» и «рядом» 😊

Не Golang'ом единым... Встречайте: Youki (яп. 容器 - контейнер). Новый container runtime, написанный на Rust! "Rust один из лучших языков для реализации oci-runtime спецификаций. Много крутых контейнерных тулзов написано на Go. Однако, container runtime используют SYSCALL'ы, которые не так то легко реализовать на Go (например namespaces(7) и fork(2). На Rust это сделать гораздо проще!" По заверениям авторов, Youki потенциально быстрее и использует меньше памяти, чем runc. Поддерживаются: 🍭Containerd 🍭Docker 🍭Podman Решение полностью совместимо с OCI Runtime Spec. Проект уже собрал 5.5к звезд на Github и имеет внушительное количество контрибьютеров. Учитывая активное развитие языка, ожидаем версию Kubernetes на Rust😁

VulnerableCode: база данных по уязвимостям в пакетах Всем привет! VulnerableCode – проект, цель которого агрегировать информацию по CVE в пакетах из различных источников. Основная идеология проекта заключается в том, что подобная информация должна быть открыта для сообщества и удобна для использования. Помимо «традиционной» базы данных от NIST, VulnerableCode агрегирует данные по Rust, npm, ubuntu, openssl и не только (с полным перечнем можно ознакомиться тут). Также проект предоставляет web-интерфейс и REST API, которые можно использовать для автоматизации процесса управления уязвимостями. Кстати, можно посмотреть, что он из себя представляет по ссылке (можно искать как по пакетам через purl, так и по CVE ID). Важно: проект пока находится в стадии доработки и не вся информация может отображаться «полностью». Больше подробностей, как обычно – либо в документации, либо на GitHub Repo проекта.

Автоматическое создание «snapshot» компрометированного контейнера Всем привет! Эфемерность контейнеров, помимо плюсов, не лишена и минусов. Особенно для информационной безопасности и forensics процессов в частности. Иногда хочется покопаться «внутри» и понять, а что же там такого произошло? Однако, контейнера уже давно нет и трудно что-либо сказать. Для решения подобной задачи можно использовать observability решения, которые могут записывать все, что «происходило внутри». А можно соорудить что-то «из подручных средств». Так и поступили Авторы статьи. Команда собрала следующее решение: 🍭 Falco. При помощи него осуществляется идентификация «вредоносных событий» и дается дальнейшая команда по созданию «snapshot’a» контейнера 🍭 OpenFAAS. Функция, которая получает команду от Falco и взаимодействует с CRIU для «сохранения» контейнера 🍭 CRIU (Checkpoint/Restore in Userspace). Как раз тот самый инструмент, который позволяет создать «snapshot» за счет функционала checkpoint Если захочется поэкспериментировать и воссоздать аналогичный сценарий – в статье все для этого есть. Описаны технические ограничения, установка необходимых компонентов, код функции и пример запуска тестового сценария.

Действительно ли Kubernetes лучше работает на "голом железе", чем на виртуальных машинах? Вы когда-нибудь задумывались над тем, насколько сильно виртуализация влияет на производительность? В этой статье автор решил проверить как работает Kubernetes на bare-metal и в виртуальной среде. Сразу скажем: результаты впечатляют! Тестировались такие показатели, как: 🍭Скорость и утилизация CPU 🍭Задержки в оперативной памяти 🍭Количество транзакций в секунду в дисковой подсистеме 🍭Пропускная способность и задержки в сети Тесты показали, что кластер, развернутый на bare-metal: в 2️⃣ раза производительнее в части CPU, более чем в 2️⃣ раза лучше показал себя при работе с дисковой подсистемой в 3️⃣ раза лучше в части работы с оперативной памятью, более чем в 5️⃣(sic!) раз лучше в производительности сети! Конечно, все тесты отчасти синтетические и реальные показатели в продуктовых средах могут отличаться, но в любом случае, если для ваших приложений нужна максимальная производительность, то стоит всерьёз рассмотреть вариант bare-metal инсталляций!

GitHub Actions Goat Всем привет! По ссылке можно ознакомиться с заведомо-уязвимым проектом для эксплуатации уязвимостей в GitHub Actions. На текущий момент можно реализовать такие сценарии, как: 🍭 Компрометация исходного кода и учетных данных 🍭 Изменение исходного кода или артефактов во время сборки 🍭 Отсутствие корректного журналирования CI/CD конвейера 🍭 Использование «долгоживущих» учетных данных 🍭 Применение недоверенных GitHub Actions от 3rd party Для каждого сценария приводится сопроводительная информация, поясняющая проблематику, ссылки на лучшие практики по защите и примеры того, как можно настроить GitHub Actions более правильно и безопасно.

Software Supply Chain: Awesome Всем привет! Герой сегодняшнего поста – Awesome подборка, посвященная тематике защиты цепочек поставки программного обеспечения. Внутри можно найти: 🍭 Материалы от «организаций» (NIST, OWASP, OpenSSF и т.д.) 🍭 Стандарты, frameworks и прочие best practices Угрозы и атаки на цепочки поставки ПО 🍭 SBOM, VEX, KEV 🍭 Отчеты, статьи, podcast 🍭 Ссылки на полезные GitHub Repo и не только Материалов очень много, на любой вкус и цвет. Уверены, что Вы найдете для себя что-то интересное и полезное.

Лучшие коктейли на Highload++ 2023 только в Jet Secret Club! Внутри вас ждут: 🏆квиз с призами 🍹авторские коктейли 🥷разговоры о важном DevSecOps, инфраструктуре, мониторинге и всем, что связано с ИТ Ищите нас рядом с залом №10 - Кейптаун!

Атака на CI/CD через shared runners Всем привет! Во многих рекомендациях по защите CI/CD упоминается о том, что использовать shared runner не самый безопасный способ. Но что тут, казалось бы, плохого? Ответ можно найти в статье, где как раз рассматривается интересующий сценарий: 🍭 Допустим, что есть 2 сотрудника, обладающих доступом к разным проектам: один – стажер, у которого особо нет полномочий, а второй – может делать deploy в production-окружение 🍭 Допустим, что стажер был компрометирован. В случае использования shared runners он может получить доступ, выходящий далеко за пределы его полномочий Возможность реализации подобного сценария Автор реализует с использованием docker-in-docker runner’a, dind (что тоже не является самый лучшей практикой наряду с shell runner). Начинается все с простого примера poisoned pipeline execution, а далее задача усложняется – «побег из dind» с последующим получением конфиденциальной информации и компрометацией host, на котором запускаются runner’ы. Помимо примеров реализации атаки в статье также присутствует информация о том, как сделать так, чтобы этого не произошло. Или, по крайней мере, стало в разы сложнее

Друзья, мы, редакция DevSecOps Talks, рады пригласить вас на доклад нашего эксперта на Highload++! Во вторник, в 11:00, в зале "Рио" Семён Барышников будет рассказывать о нашем переосмыслении VDI и о том, как мы для мероприятия CyberCamp 2023 предоставили доступ в инфраструктуру участникам киберучений. Будет описано много интересных решений, нестандартных подходов как в области инфраструктуры, так и в области безопасности k8s. Тема рассказа: Высоконагруженная VDI из Open Source для платформы киберучений «CyberCamp» в облачном Kubernetes

Повышение привилегий в Kubernetes Всем привет! Статья, в которой рассматриваются несколько способов, описывающих как и за счет чего можно повысить привилегии в кластере Kubernetes. Автор рассматривает следующие возможности: 🍭 Pod Creation. В целом, в этом нет ничего «опасного», если контролируется манифест создаваемого pod’a и гарантируется, что используется «валидный образ». Однако, если это не так, то можно реализовать несколько сценариев по повышению привилегий 🍭 Read Secrets. Бесконтрольный доступ к секретам никогда не бывает хорошей практикой. В любой системе, в том числе и в Kubernetes 🍭 Bind Roles. Назначение большего количества полномочий, чем требуется 🍭 Escalate Existing Roles. Добавление больших прав к существующей роли 🍭 Impersonate. Возможность отправки запросов к kube-apiserver от более привилегированной роли Для каждой из вышеописанной возможности приводятся некоторые сценарии с примерами как этим можно воспользоваться. Минимально-необходимым уровнем защиты от описанных в статье сценариев является корректная настройка ролевой модели Kubernetes и использование Admission Controller с необходимыми политиками контроля