DevSecOps Talks

GitHub Actions: угрозы, атаки и защита

Всем привет!

По ссылке можно ознакомиться со статьёй от Wiz, посвященной моделированию угроз, атакам и способам защиты для GitHub Actions.

В начале статьи рассматривается, где проходит грань между (не) доверенным зонам: от владельцев репозиториев до ботов и приложений, которые могут создавать pull request.

Это позволяет лучше понять проблематику и как именно могут совершаться атаки на GitHub Actions.

Далее Авторы детально рассматривают несколько примеров:
🍭 Ошибки при работе с pull_request_target (который похож на pull_request_trigger, но всё-таки отличается)
🍭 Script Injection («расширение» возможностей запускаемого workflow)
🍭 Compromised 3rd-party Action (компрометация популярного action)

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

Дополняет этот материал обилие ссылок на полезные ресурсы по теме и примеры реальных атак.

Cilium Policy Generator

Всем привет!

Если вам нужны Network Policy, но вы не хотите их писать самостоятельно, а вместо этого использовать средства автоматизации, то проект cpg может вам помочь.

Работает он по следующему принципу: соединяется с Hubble Relay, анализирует dropped-соединения и генерирует CiliumNetworkPolicy, которые их разрешают.

Предполагается, что всё начинается с правила default-deny-all, что позволяет «открывать» только нужные каналы взаимодействия на основании анализа трафика.

Сам по себе он ничего не применяет, а лишь генерирует YAML-файлы для дальнейшей проверки и применения, если всё соответствует действительности.

Не все dropped-соединения попадают в политику. Часть из них «отбрасываются» cfg с указанием причины принятого решения.

Из ключевых ограничений можно выделить: работа только с L4-трафиком, создание только CiliumNetworkPolicy (а не CLusterWide).

Подробнее о том, как всё это работает, в каких режимах можно запускать cpg и какие результаты он предоставляет, можно прочесть в GitHub-репозитории проекта.

Lazydocker: TUI для Docker-контейнеров

Всем привет!

Lazydocker – open-source проект, который представляет из себя TUI для работы с контейнерами, запущенными с использованием Docker и/или Docker Compose.

С его помощью можно:
🍭 Получать информацию об использовании ресурсов (CPU/RAM)
🍭 Просматривать логи в режиме реального времени
🍭 Управлять используемыми volumes
🍭 Изменять конфигурации запущенных контейнеров
🍭 Останавливать, перезапускать и удалять контейнеры
🍭 Работать с образами (просмотр, удаление «не используемых) и не только

Получился некий аналог k9s, но для работы с Docker-контейнерами, где всё можно посмотреть в едином UI и всё «под рукой».

Подробности о проекте – установка, настройка, использование – можно прочесть в его GitHub-репозитории.

«Посмотреть» на Lazydocker «в деле» можно в этом видео (~ 12 минут), где Автор показывает как им пользоваться и как его можно настраивать.

Remediation at Scale: What High-Performing AppSec Teams Do Differently

Всем привет!

Команда Semgrep проанализировала то, насколько часто/быстро устраняются ИБ-дефекты. Для исследования была получена обратная связь от команд, которые суммарно разрабатывают тысячи репозиториев.

В итоге, Semgrep разделил результаты на 2 крупных блока – Leaders (15%) и Field (85%). В прилагаемом отчёте (~ 34 страницы) можно найти результаты исследования.

Из ключевых insights можно выделить:
🍭 Leaders устраняют в 2-3 раза больше ИБ-дефектов
🍭 Сканирование PR/MR «ускоряет» устранение в 9 раз (по сравнении со скоростью устранения ИБ-дефектов, которые найдены при сканировании кодовой базы)
🍭 Leaders пользуются бОльшим количеством функций доступных им инструментов
🍭 Анализ достижимости сильно меняет подход к расстановке приоритетов при анализе сработок SCA
🍭 Использование AI помогает в разметке и сокращении False Positive
🍭 Если ИБ-дефект «застрял» в backlog более чем на 90 дней, то вероятность его устранения стремится к 0

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

Помимо этого, в отчёте еще очень-очень-очень много интересной и полезной информации о том, что (не) важно при работе с SAST и SCA-дефектами.

Рекомендуем!

Фреймворки DAF и JCSF победили в премии Security UP: «Безопасность начинается с кода»!

Привет, друзья! Спешим похвастаться: наши фреймворки оценили на премии Security UP: «Безопасность начинается с кода», организованной ГК "Солар", Ассоциацией ФинТех и сообществом FinDevSecOps:
🦴Фреймворк оценки зрелости безопасности контейнерной инфраструктуры Jet Container Security Framework (JCSF) победил в номинации «Открытые горизонты: Open Source в безопасности ПО»
🦴Фреймворк оценки зрелости процессов безопасной разработки DevSecOps Assessment Framework (DAF) получил знак качества Ассоциации ФинТех.

Мы очень рады, что наш вклад в open source оценили столь уважаемые эксперты в области DevSecOps! Это очень вдохновляет нас и, надеемся, вас тоже на развитие безопасной разработки и DevSecOps в наших компаниях и во всем мире. Make DevSecOps great again!

Vesparian: API Discovery

Всем привет!

Vesparian – open-source проект от команды Praetorian, который обнаруживает API endpoints за счёт анализа «живого» HTTP-трафика с последующей генерацией спецификаций.

На текущий момент он умеет:
🍭 REST API Discovery
🍭 WSDL/SOAP Discovery
🍭 Headless Browser Crawling
🍭 Traffic Import и не только

Работает он в 2 этапа: «захват» траффика и генерация нужно спецификации.

Для REST – OpenAPI 3.0, GraphQL – GraphQL SDL и WSDL для WSDL/SOAP.

Подробнее о возможностях, запуске и настройке Vesparian можно прочесть в GitHub-репозитории проекта или вот в этой статье.

Как идентифицировать побег из контейнера?

Всем привет!

«Какая именно телеметрия генерируется, когда совершается «побег» из контейнера?» – именно с этого вопроса началось путешествие Автора статьи.

Для того, чтобы ответить на свой вопрос он взял 3 популярных решения – Tetragon, Falco, Tracee и подготовил 15 различных сценариев.

Сценарии можно разбить на группы:
🍭 Misconfiguration escapes. Наиболее часто встречающиеся сценарии «побегов»
🍭 A baseline control. В этом сценарии Автор разбирал сколько событий сгенерируют решения на «обычный, ничего не делающий контейнер». Спойлер: Tetragon «выиграл»
🍭 CVE-based patterns. Идентификация определенных уязвимостей уровня ядра (Leaky Vessels, DirtyPipe и т.д.)
🍭 Capability abuse scenarios. Анализ действий привилегированного контейнера
🍭 A stress test. Он самый. Что будет, если злоумышленник будет генерировать миллионы syscalls в секунду?

Каждый такой сценарий запускался на своей собственной виртуальной машине (3 GB RAM, 2 vCPUs, Ubuntu 22.04, kernel 5.15.0-91-generic).

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

Еще одним интересным наблюдение стало количество генерируемой информации.

Tetragon сгенерировал 1,2 GB данных, в то время как Tracee – 20 MB, а Falco – 36 MB.

И это далеко не всё. Настоятельно рекомендуем ознакомиться со статьей.

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

Рекомендуем!

ASAMM: agentic SAMM

Всем привет!

Да, это именно оно! «Расширение» OWASP Software Assurance Maturity Model (OWASP SAMM) при использовании AI-Driven разработки.

Автором расширения является Сергей Гордейчик.

ASAMM предлагает следующие функции:
🍭 Governance
🍭 Design
🍭 Implementation
🍭 Verification
🍭 Operations

Для каждой функции определен набор контролей и уровней зрелости (которых в модели определено 3 штуки). Всего получилось 17 контролей, «разбитых» по 5 функциям.

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

И это еще не всё! Если вам интересна таксономия угроз, характерных при работе с агентами, то и она есть в предоставленных Автором материалах.

Supply Chain Monitor

Всем привет!

Supply Chain Monitor от команды Elastic – open-source проект, задача которого – анализировать PyPi и npm пакеты на предмет компрометации.

Работает он следующим образом: из каждого индекса скачиваются последние версии пакетов, происходит анализ с его «предшественником» с использованием LLM.

Если в пакете есть что-то подозрительное, то происходит оповещение в Slack.

LLM «направлена» на поиск следующего:
🍭 Обфусцированный код (base64, exec, eval, XOR и т.д.)
🍭 Попытка установки сетевых соединений
🍭 Запись в файловую систему
🍭 Запуск процессов и/или shell-команд
🍭 Стеганография в медиа-данных и не только

Подробности о принципах работы, настройке, примерах оповещений и возможностях Supply Chain Monitor можно найти в GitHub-репозитории проекта.

Vibe Security Radar

Всем привет!

Vibe Security Radar – проект, который помогает определить, что определённая уязвимость была добавлена в исходный код с использованием LLM.

Работает по следующему принципу:
🍭 Анализ уязвимости и поиск commit’a с исправлением
🍭 Идентификация «автора изменения»
🍭 Поиск AI-«сигналов»
🍭 Уточнение данных для того, чтобы убедиться, что «автор» - ИИ

На текущий момент было выявлено 78 таких уязвимостей, 43 из которых имеют уровень критичности High и Critical.

Для каждой такой уязвимости можно посмотреть информацию об LLM, которая её «добавила» и общие данные («сигналы», commit’ы с исправлениями и результаты анализа и т.д.).

Если хочется больше подробностей, то они представлены в GitHub-репозитории проекта.

Self-Deployment: работа с ИТ-инфраструктурой

Всем привет!

В приложении можно найти полноценную книгу (~ 774 страницы), в которой собрана информация, которая может помочь погрузить в тематику работы с ИТ-инфраструктурой и Kubernetes в частности.

Автор написал её для разработчиков, чтобы они понимали не только «свою часть», но и «всю картину» в общем.

Книга содержит главы:
🍭 Introduction to Linux
🍭 Basics of the Shell Environment
🍭 Basic Linux Commands
🍭 Containerization and Docker
🍭 Kubernetes и не только

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

Примеры, пояснения, немного истории, ссылки на полезные материалы по рассматриваемой теме – всё внутри!

P.S. Если кто-то хочет материально отблагодарить Автора, то сделать это можно по ссылке

Безопасность CI/CD: рекомендации Latio

Всем привет!

Сканирование зависимостей и образов контейнеров на наличие уязвимостей практика, безусловно, полезная, но не всегда достаточная.

Особенно, когда речь касается безопасности процесса сборки. Причина проста – поверхность атаки гораздо больше.

Чтобы разобраться что к чему и с чего начать, можно воспользоваться рекомендациями от Latio.

Ребята собрали набор практик по следующим разделам:
🍭 Third-Party Packages
🍭 Container Images
🍭 GitHub Actions
🍭 Infrastructure-as-Code Modules
🍭 AI/ML Modules
🍭 IDE Extensions and Developer Tools

Для каждого раздела приведен checklist, состоящий из двух разделов.

Первый – Immediate Actions – описывает высокоприоритетные задачи, которые помогут значительно «сократить» поверхность атаки.

Второй – Long-term Initiatives – предлагает набор практик для развития и дальнейшего улучшения.

В завершении статьи можно найти примеры атак по рассмотренным выше областям.

Кстати, проверки всех checklist’ов можно автоматизировать с использованием Claude Code Plugin, ссылку на который можно найти в статье.

Регистрация на Альфа ЦТФ уже открыта ⚡️

25 апреля Альфа-Банк проводит соревнование по захвату флага — Цепляй Трофейный Флаг. Будете искать уязвимости на городских высотах и бороться за призовой фонд 3 100 000 рублей.

Что нужно сделать:
➡ Выпить бодрящий кофе перед стартом и настроиться на маршрут
➡ Сгонять на велозаезд — или хотя бы сделать вид
➡ Искать флаги как в городе, так и внутри систем
➡ Не теряться на сложных участках
➡ Находить и разбирать уязвимости

Во время соревнования будут доступны ИТ-хабы в Москве, Санкт-Петербурге, Екатеринбурге и Сочи, а также коворкинги в вузах-партнёрах: Финансовом университете, ИТМО и Сириусе.

Будет 4 направления:
🚩 ЦТФ-трек для специалистов по ИБ и опытных игроков, которые готовы к сложным заданиям
🔢 ИТ-трек для ИТ-специалистов кроме тех, кто работает в кибербезопасности или участвовал в соревнованиях по спортивному хакингу
😁 Студенческий трек для учащихся вузов и колледжей
👟 Школьный трек — впервые могут участвовать подростки 14–18 лет

Регистрируйтесь, собирайте команду или залетайте в соло!

GitHub Actions: Security Roadmap

Всем привет!

События последних недель ясно дали понять, что безопасность цепочки поставки ПО – вещь достаточно важная и значимая.

Команда GitHub это понимает и ведёт работы в этом направлении. Недавно они опубликовали перечень нововведений, которые будут реализованы для повышения уровня информационной безопасности.

Ознакомиться с получившимся Security Roadmap можно по ссылке.

Если говорить в общем, то работа ведётся в трёх направлениях:
🍭 Ecosystem. Явное определение зависимостей и безопасная публикация
🍭 Attack Surface. Управление политиками, настройками по умолчанию и ограничение области действий учётных данных
🍭 Infrastructure. Контроль действий в реальном времени, ограничение сетевого взаимодействия runner’ов

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

Или же создание политик, которые явно определяет кто именно/какое событие может запускать сборку.

И, конечно же, какой Roadmap без сроков – информацию о доступности нововведений можно найти в статье.

Безопасная работа с npm

Всем привет!

В GitHub-репозитории собраны лучшие практики, позволяющие повысить уровень информационной безопасности при работе с npm.

Глобально материал «разбит» на разделы:
🍭 npm Security Best Practices
🍭 Secure Local Development Best Practices
🍭 npm Maintainer Security Best Practices
🍭 npm Package Health Best Practices

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

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

Кратко, по делу и ничего лишнего. Рекомендуем!

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 👋 Комьюнити
🥰 Буст для чата

The Agentic Coding Security Report

Всем привет!

В приложении можно найти небольшой отчёт (~ 14 страниц) от DryRun Security – The Agentic Coding Security Report.

В нём отражена точка зрения на вопрос: «AI-агенты всё чаще и чаще используются для разработки ПО. Но как это влияет на уровень информационной безопасности?».

Для этого команда «поставила задачу» трём агентам – Claude, Codex и Gemini – по разработке ПО с последующей его «доработкой» через PR.

По завершению «работы» итоговые варианты программного обеспечения были проанализированы на наличие ИБ-дефектов.

Если кратко, то:
🍭 87% PR содержали ИБ-дефекты
🍭 Большинство ИБ-дефектов были «Высокого» уровня критичности
🍭 Разные агенты допускали идентичные ошибки (Broken Access Control, TOCTOU, XSS, User Enumeration и т.д.)
🍭 Codex показал лучшие результаты ☺️

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