DevSecOps Talks

DefenseClaw: защита агентских AI Всем привет! Недавно Cisco выпустила DefenseClaw – open-source проект, задача которого – повысить уровень ИБ при использовании агентских AI. Он «состоит» из CLI-, написанной на Python, Gateway Sidecar на Golang и TS-плагина для OpenClaw. Если обобщить, то DefenseClaw позволяет: 🍭 Сканировать skills, MCP-серверы, плагины и код перед тем, как они будут запущены 🍭 Анализировать prompts, вызовы, которые будут реализованы инструментами 🍭 Искать секреты, опасные функции, небезопасную десериализацию, паттерны инъекций 🍭 Возможность запускаться в «песочнице» 🍭 Получать полную информацию о том, что происходило В итоге имеем вот такой вот «комбайн», который может как анализировать код, так и поведение используемых агентов. Подробнее о возможностях, настройке и использовании DefenseClaw можно прочесть в документации.

wachd: поиск причин проблем с помощью ИИ Всем привет! Ещё один вариант использовании ИИ для облегчения задач поиска ошибок. Wachd позволяет оптимизировать этот процесс за счёт получения уведомлений от различных систем о возникшей проблеме с последующим оповещением ответственного о причинах, которые к ней привели. Работает она по следующему алгоритму: 🍭 Получает webhook от Grafana, Datadog, Splunk или любого иного подходящего источника 🍭 Дополучает контекст: логи сообщений, историю потребления ресурсов и т.д. Контекст берётся из промежутка времени, в котором произошел инцидент 🍭 Удаляет всю конфиденциальную информацию перед анализом 🍭 Пытается понять, что именно стало причиной проблемы 🍭 Уведомляет ответственного об инциденте и его возможной причине Установка, настройка, описание API, инструкции – всё это доступно в GitHub-репозитории проекта. Open-source версия wachd имеет ограничения в использовании: 1 команда, 5 пользователей, 1000 уведомлений в месяц и возможность использования только Ollama.

k9sight: TUI для работы с Kubernetes Всем привет! k9sight – open-source проект, представляющий из себя текстовый интерфейс для работы с ресурсами Kubernetes. Он позволяет: 🍭 Получать информацию о Deployments, StatefulSet, DaemonSet, Job, CronJob и не только 🍭 Просматривать логи pod, осуществлять поиск и фильтрацию 🍭 Делать exec и port-forward 🍭 Перезапускать ресурсы, изменять количество реплик 🍭 Получать информацию об events, метриках и не только И самое интересное! Vim-style навигация! Для всех фанатов этого редактора или просто для тех, кто так и не смог из него выйти ☺️ Подробности о возможностях, способах установки – всё в GitHub-репозитории проекта. А вместе с этим – небольшая (но наглядная) демонстрация его возможностей.

Изменения в NVD, обновление подхода к управлению уязвимостями Всем привет! Количество уязвимостей растёт год от года. И сама скорость роста тоже возрастает. В связи с этим недавно NVD объявила о том, что подход к обогащению данными по CVE будет изменён. Раньше было примерно так: кто-то публиковал CVE, её ID, иногда – CPE, набор ссылок и CVSS, который считался Автором CVE. NVD, в свою очередь, всё это обрабатывала и стандартизировала: корректный CPE, уточнение CVSS, добавление CWE, группировка ссылок-референсов. Это позволяло сделать процесс более системным и нормализованным. Однако, 15 апреля 2026 года подход изменился. Описанная выше работа NVD будет не для всех уязвимостей, а только для части из них. Например, если CVE есть в KEV. Но таких всего 0,5%. Получается, что в долгосрочной перспективе мы будем получать меньше информации или она будет не так структурирована и информативна. Что с этим делать и как быть? Мнение на этот счёт есть у Автора статьи. Он считает, что пора уходить от подхода, где ИБ расставляет приоритеты исходя из характеристик определенной CVE (критичность, CVSS и т.д.). Получать дополнительную информацию: тот же KEV, информация из EPSS, использование альтернативных источников данных по уязвимостям (GHSA, бюллетени, OSV и т.д.), понимание контекста актива, в котором найдена уязвимость. Это позволит самостоятельно определить те значимые параметры, которые раньше (пусть и не очень точные) можно было получить от NVD. И, конечно, не стоит забывать и о runtime-защите, которая позволит поставить «временный патч» и выиграть время для устранения уязвимости в коде. А что вы думаете по этому поводу? Насколько для вас значимо то, что NVD, со временем, сократит количество предоставляемой информации по CVE?

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 минут), где Автор показывает как им пользоваться и как его можно настраивать.

Фреймворки DAF и JCSF победили в премии Security UP: «Безопасность начинается с кода»! Привет, друзья! Спешим похвастаться: наши фреймворки оценили на премии Security UP: «Безопасность начинается с кода»: 🦴Фреймворк оценки зрелости безопасности контейнерной инфраструктуры 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-репозитории проекта.

Безопасность 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 Каждый из описанных выше разделов состоит из набора рекомендаций, перечень которых варьируется. Для каждой рекомендации приводятся некоторые советы и набор команд, в которых указано как её можно реализовать на практике. Кратко, по делу и ничего лишнего. Рекомендуем!