DevSecOps Talks

Атаки на GitHub Workflows и способы защиты от них Всем привет! В очередном отличном материале от OpenSSF рассматриваются возможные векторы атак на GitHub Workflows и рекомендации по защите. Авторы проанализировали сценарии: 🍭 Запуск недоверенного кода в привилегированных Workflows 🍭 Внедрение вредоносного кода 🍭 Выпуск вредоносных релизов 🍭 Небезопасное использование cache и не только В начале статьи приводятся основные термины – что понимается под Privileged Workflow, какие события могут запустить Workflow, что считать недоверенными данными и т.д. Далее для каждого вектора приводится его «логическое описание», примеры реализации и способы по устранению недостатков. С пояснениями, кодом и примерами

DepFuzzer! И это не то, что вы думаете! Всем привет! Использование open source для разработки ПО – данность, с которой мало кто будет спорить. С этим согласны и Авторы статьи. Сперва в ней разбирается «по верхам» управление пакетами для Golang, Python, Rust и Node.JS. Например, откуда «берутся» пакеты, рассматриваются форматы файлов, в которых содержится перечень используемых пакетов (package.json, requirements.txt и т.д.) с кратким описанием. После этого кратко разбирается процесс установки пакетов на примере Node.JS. И зачем все это нужно? Для того, чтобы лишний раз подсветить вопросы ИБ, характерные для Supply Chain Security 😊. Например – dependency confusion. И именно для решения этой проблемы ребята сделали собственную утилиту – DepFuzzer. Нет, это не fuzzer в классическом понимании и можно «немного расслабиться» 😊 Его задача – искать те самые dependency confusion для рассматриваемых в посте языков программирования. В статье описана логика работы утилиты и примеры ее использования. А если нужен исходный код, то его можно найти в repo. P.S. Утилита достаточно «свежая», поэтому многого от нее на текущий момент ожидать не стоит. Но интересно посмотреть, во что она может развиться 😊

IDOR: где и как их можно найти? Всем привет! IDOR представляет из себя достаточно «популярную» уязвимость, которая встречается в WEB-приложениях и/или API. Грубо говоря IDOR, позволяет обращаться к некоему объекту (будь то файл или запись в базе данных) без надлежащей проверки возможности и прав доступа. В статье собрана информация о том, где чаще всего можно встретить указанные уязвимости. Например: 🍭 Parameter Pollution 🍭 «Модификация» передаваемых JSON-объектов 🍭 Изменение методов (например, с GET на POST) 🍭 Использование устаревших версий API 🍭 IDOR «второго порядка» и не только В статье приводится краткое пояснение к каждому методу. Это может быть полезно для того, чтобы понимать «откуда может прилететь» и, соответственно, удостовериться, что все проверено. Входные данные проверяются, неавторизованные запросы не реализуются, а сеансы пользователей находятся «под контролем».

GitOps с использованием Argo Rollouts Всем привет! Argo Rollouts – проект, который позволяет реализовать blue/green или canary/progressive deployment в Kubernetes. Он заменяет стандартный Kubernetes контроллер на свой собственный – Rollout – который как раз и упрощает некоторые процедуры и расширяет функционал Kubernetes. В статье Автор рассматривает следующие варианты: 🍭 Автоматизация Blue/Green deployment 🍭 Анализ успешности обновления (например, с использованием Prometheus) Помимо манифестов, в статье приведено пошаговое описание процесса обновления. А для тестирования возможностей Argo Rollouts можно воспользоваться вот этим приложением.

Git Undo: не совершая непоправимое! Всем привет! Легкий пятничный пост-шпаргалка для тех, кто только осваивается в git и «боится нажать что-то не то, чтобы это не сломалось». Например, вы хотите «отменить» изменения сделанные локально, случайно сделали commit не в ту ветку, случайно удалили ветку… Всякое бывает! Особенно, когда вы только начинаете работать с этим мощным инструментом. В статье приведены 13 команд, которые могут помочь: 🍭 «Отмена» всевозможных изменений (локальных, удаленных) 🍭 «Перенос» commit в другую ветку 🍭 Просмотр старых commits 🍭 Восстановление «чего-то» удаленного и не только Да, для тех, кто знаком и хорошо владеет git - ничего нового, а новичкам может быть крайне полезно. Как минимум, чтобы «не бояться сделать что-то не так»

Коммитить нельзя сканировать: как мы боремся с секретами в коде Всем привет! Да, мы обещали не беспокоить вас более новостями о CyberCamp 2024, но не могли «пройти мимо»! Буквально в последний момент к составу спикеров присоединился Александр Карпов из команды VK! В докладе Александр расскажет захватывающую историю: «Поиск секретов в исходном коде в масштабах VK — непростая задача. Мы предлагаем вам послушать, как мы ее решали, чтобы при случае применить полученные знания на практике. Что будет в докладе: 🛡 Выбор оптимальной точки «контроля» секретов — сравнение pre-commit, web и server side hook 🛡 Комплексная архитектура решения — описание основных компонентов, связь с AppSec-экосистемой VK 🛡 Доработка Gitleaks — почему нас не устраивал вариант «из коробки» и что мы доделали сами» Приходите, будет интересно и полезно! CyberCamp 2024 начнется уже в четверг этой недели! P.S. Напоминаем, что следить за CyberCamp «в прямом эфире» можно в официальном TG-канале. Никакой рекламы, только информация о мероприятии, заданиях и ИБ 😊

Application Security Cheat Sheet! Всем привет! По ссылке можно найти «сборник cheat sheets», посвященных Application Security. Cheat sheet – это небольшая «шпаргалка», в которой содержится «выжимка» по некоторой теме. Что есть внутри: 🍭 Контейнеры. Основные принципы технологии, способы «побега» 🍭 Linux. Немного про основы и bash tips 🍭 Мобильные приложения. iOs и Android 🍭 Web Application. Cookie Security, CORS, Race Condition и многое другое Можно найти сведения как об атаках, так и о способах защиты. Из плюсов – cheat sheets, как правило, весьма «конкретные и явные», из минусов – теорию и понимание основ с них поиметь сложно (а это важно 😊).

Контроль целостности образов в Kubernetes Всем привет! Контроль целостности образов, запускаемых в кластере Kubernetes – важный аспект безопасности цепочки поставки (Supply Chain Security). В статье Автор предлагает реализовать его с использованием нескольких Open Source решений: Cosign, Kyverno и HashiCorp Vault. Получается следующая схема: 🍭 Cosign подписывает образ в CI/CD 🍭 Ключ, используемый для подписи, хранится HashiCorp Vault 🍭 Kyverno проверяет наличие и валидность подписи перед тем, как запустить образ. Также она контролирует, что образ «извлекается» из доверенного источника Как все это настроить, какие политики нужны для Vault и Kyverno, как это «соединить вместе» - очень детально описано в статье. С примерами и комментариями Автора 😊

Безопасность Kubernetes: руководство новичка! Всем привет! Сегодня хотим предложить вам чтение на выходные! Статья про безопасность Kubernetes для начинающих, ~ 30 минут для прочтения. Начинается все с постепенного погружения: что такое Kubernetes, из каких компонентов он состоит и зачем они нужны, какие задачи выполняют. Что такое ConfigMaps, Secrets, Volumes, Namespaces и т.д. Дальше Автор углубляется в вопросы ИБ: 🍭 Общие концепты. Вопросы, связанные с AuthN/Z, использование Admission Controller, Pod Security, RBAC и т.д. 🍭 Векторы атак. Примеры тактик и техник, с «привязкой» к этапам kill chain 🍭 Реагирование и расследование. Набор рекомендаций для идентификации событий ИБ, характерных для сред контейнерной оркестрации Таким образом статья представляет из себя отличный обзорный материал, в котором собрано все необходимое для того, чтобы начать погружаться в безопасность Kubernetes.

Как контейнер устроен «внутри»? Всем привет! Сегодня хотим поделиться с вами еще одной теоретической статьей из цикла «как оно устроено». Такие статьи помогают лучше разобраться в технологии, в том, чего от нее ожидать и, как следствие, как ее можно защищать. Если упростить, то контейнер это: 🍭 Один или несколько процессов, выполняемых пользователем (Processes) 🍭 Он изолирован от ОС, на которой запущен (Namespaces) 🍭 Также он ограничен в доступных ресурсах (Cgroups) 🍭 У него есть собственная файловая система, независимая от ОС, на которой он запущен (Chroot) Да, описание не совсем корректное и его можно улучшить, но оставим его для упрощения восприятия. В статье Автор описывает что такое Processes, Namespaces, Cgroups и Chroot. Далее он предлагает создать «аналог контейнера» с использованием Golang: код и комментарии на месте. Создание идет «по нарастающей» - от простого вывода в stdout до «изоляции и ограничения» с использованием Namespaces и Cgroups.

Небольшие Kubernetes Quizzes! Всем привет! Есть очень хороший ресурс, посвященный Kubernetes – Learnk8s. Помимо множества обучающих материалов, команда сделала набор задач, посвященных тонкостям работы технологии контейнерной оркестрации. Например: 🍭 Counting endpoints (как и сколько endpoints будет у Service) 🍭 Waiting for miracle (как работает shutdown) 🍭 I said stop (как «оттянуть» время удаления Pod) 🍭 Designing shared clusters (какую архитектуру выбрать) 🍭Kernel panic (время паниковать? 😊) На текущий момент доступно 19 таких «статей». Все приводить мы не стали, полный список можно найти по Автору – Daniele Polencic. Для каждого задания приводится условие, варианты ответов и непосредственно ответ с пояснениями. Рекомендуем, прежде чем читать ответ, подумать, что именно будет происходить и почему 😊 Очень увлекательно!

ChatGPT против Snyk! Всем привет! «Когда я впервые попросил написать ChatGPT *что-то* я был приятно удивлен результату! Казалось, что это может сэкономить кучу времени!» - так Автор начинает свою статью. Наверное, эта мысль отзывается многим. Но так ли все хорошо на самом деле? Для ответа на этот вопрос Автор проделал простой эксперимент: он попросил ChatGPT написать ему конфигурацию для создания S3 Bucket при помощи Terraform. Полученный результат Автор проанализировал с помощью Snyk и нашел достаточно много нюансов, связанных с ИБ. Да, впоследствии (согласно условиям эксперимента) скрипт был адаптирован силами того же ChatGPT и улучшен, но не факт, что ИБ-проблемы исчезли на 100%. Из этого небольшого эксперимента можно сделать несколько выводов: 🍭 «Prompt engineering» - крайне важная вещь. ChatGPT не будет «додумывать» за вас что вам надо. Ему надо явно ставить задачу 🍭 AI/LLM – не панацея и все результаты, полученные с их помощью надо проверять. Поэтому не следует убирать проверки из ваших CI-конвейеров 🍭 Пока что AI/LLM могут выступать в качестве хорошего помощника, который может решить «проблему чистого листа», но не более Вроде бы это и очевидно, но как соблазнительно все выглядит – хочется просто взять и скопировать результаты, запустить приложение и радоваться! Однако, доверяй, но проверяй.

Shift Left/Right с использованием Trivy Всем привет! Trivy – достаточно известный инструмент от Aqua Security, который используется для идентификации уязвимостей и некорректных конфигураций в образах контейнеров. Такой вот «швейцарский нож», который много чего умеет. Многие уже знают, что это и как с этим работать. А если вы еще не пробовали, то рекомендуем вам вот эту статью. В ней Автор показывает, как работать с Trivy и Trivy Operator. Например: 🍭 Сканирование образов на наличие уязвимостей 🍭 Сканирование конфигурационных файлов для идентификации проблем 🍭 Анализ файловой системы для поиска чувствительных данных 🍭 Запуск Trivy Operator для анализа образов, из которых запущены контейнеры в кластере Kubernetes 🍭 Отправка данных в Grafana и последующая визуализация Ничего «сверхъестественного», просто хорошая обзорная статья, в которой рассматриваются разные режимы работы Trivy и «точки интеграции» в процессы безопасной разработки. А еще внутри можно найти наглядные и полезные sequence-диаграммы 😊

Диаграммы на любой вкус и цвет! Всем привет! Многие люди гораздо проще готовы воспринимать информацию, представленную в виде графики, а не текстового описания. Если вы из таких, то этот легкий пятничный пост точно для вас! На сайте собрано невообразимое количество различных схем. Например, можно найти: 🍭 Infrastructure as Code 🍭 API Security Cheatsheets 🍭 Объяснение принципов работы аутентификации (Password, Session, Cookie, Token, JWT, SSO, OAuth) 🍭 Good Coding Principles to Improve Code Quality и много чего еще Помимо самой схемы-диаграммы есть небольшое описание или ссылка на видеоролик, в котором можно найти больше информации P.S. Всех с пятницей и отличных вам выходных!!! 😊

VEX Hub: агрегация информации по VEX-отчетам Всем привет! Vulnerability Exploitability eXchange (VEX) – удобный формат обмена информацией о том, подвержено ли некоторое ПО уязвимости X или нет. Или при каких условиях. VEX может быть частью SBOM, а может жить «самостоятельной жизнью». Его задача достаточно проста – обогащение информацией. Процесс управления уязвимостями (Vulnerability Management), вероятно, больше всех прочих нуждается в множестве данных, которые помогут принять решение и расставить приоритеты. Как иначе понять, за какую из 100 Critical-уязвимостей браться в первую очередь, при условии, что «мощность» команды на устранение в нужный период лишь 40 штук? Для того, чтобы немного упростить жизнь, команда Aqua Security анонсировала VEX Hub! У него крайне простое назначение – агрегировать VEX-данные от различных производителей и централизованно предоставлять информацию пользователям. Работает по следующему принципу: 🍭 Maintainer repo создает папку .vex в корне и помещает в нее отчет 🍭 Maintainer делает PR в VEX Hub с просьбой добавить его для сбора информации 🍭 Crawler Aqua собирает данные и агрегирует все в едином repo 🍭 Все! Больше подробностей можно узнать в repo проекта или в статье от Aqua Security. Да, наполнение пока «не очень», но и проект анонсировали недавно. Интересно будет наблюдать за его развитием 😊 P.S. Кстати, Trivy, начиная с версии v0.54 может работать с VEX для предоставления еще большей информации об уязвимостях.

KubeAdmiral: multi-cluster orchestration engine! Всем привет! В начале своей деятельности команда ByteDance использовала подход, в котором для каждого бизнес-направления использовались собственные кластеры Kubernetes. Со временем, ребята поняли, что такой подход имеет ряд существенных ограничений с утилизацией ресурсов и поддержкой отдельно взятых инсталляций. Это привело к дому, что они начали «копать» в сторону реализации федеративных кластеров. И сперва использовали для этого KubeFed. Концепт состоит в том, что есть host и member кластеры. Пользователь может создать federated-ресурс на host кластере, после чего он будет создан в member-кластерах. Однако, и у такого подхода есть недостатки: поддержка ограниченного количества ресурсов для scheduling; возможные проблемы, связанные с rescheduling и не только. Все описанное выше привело к тому, что был создан KubeAdmiral! Он позволяет централизованно управлять множеством кластеров и не содержит недостатков, которые есть у KubeFed. Подробнее о нем можно прочесть в статье, repo проекта или в документации.

JET Pilot: UI для Kubernetes Всем привет! Если вы из тех, кому нравится выбор, и вы любите смотреть на разные технологии, решающие одну и ту же задачу, но по-разному, то JET Pilot может вас заинтересовать. Это минималистичный UI для Kubernetes, который позволяет: 🍭 Получать информацию о ресурсах кластера 🍭 Смотреть и редактировать их конфигурацию 🍭 Анализировать логи в real time 🍭 Получать shell-доступ внутрь контейнера Каких-то явных преимуществ в сравнении с Lens или k9s у него нет. Но у всех свои вкусы ) Например, тот, кто написал этот пост любит k9s и не очень любит использовать Lens 😊

Supply chain атака на PyPi: Revival Hijack Всем привет! «Как только пакет удаляется из PyPi, его имя сразу становится доступно для регистрации». Directed by Robert B. Weide. Наверное, тут уже не «кажется, что что-то может пойти не так», а прямо кричит об этом. Особенно учитывая то, насколько Supply Chain атаки «популярны». Сценарий крайне простой: 🍭 Пользователь работает с пакетом X версии 1.42 🍭 «Владелец пакета» удаляет его из PyPi 🍭 Злоумышленник регистрирует пакет X версии большей, чем 1.42. Но только уже совсем с иным «содержанием» 🍭 Пользователь обновляет пакет… И это не typosquotting, где пользователь ошибся. С его точки зрения это вполне легитимная операция. Команда JFrog, нашедшая указанный недостаток, написала отличную статью, в которой все описано в мельчайших подробностях. От теории до PoC с примерами, скриншотами и всем необходимым для более глубокого погружения. На этом ребята не остановились и пошли дальше! Они «прикинули» сколько пакетов подвержено этой атаке. Т.е. были недавно удалены. Оказалось, что таких – 22 000! При этом, в среднем в месяц удаляется около 309 пакетов. Но есть и хорошие новости! Чтобы защитить community, специалисты JFrog создали Security Holding. Он загружает «пакет-заглушку» для наиболее часто скачиваемых пакетов, что были удалены. И понижает версию до 0.0.0.1, что позволяет минимизировать вероятность dependency confusion. И даже это еще не все… 😊 Крайне рекомендуем к ознакомлению! Читается на одном дыхании!