DevSecOps Talks

MOAK: мать всех KEV Всем привет! Mean-time-to-Exploit изменялось от года году. Если раньше для генерации PoC на какую-либо CVE и её успешную эксплуатацию могли потребоваться месяцы, то сегодня время сократилось радикально. Теперь для этого требуются часы, в скором времени, возможно, минуты. Да, речь об использовании LLM для проверки того, что уязвимость эксплуатируема. Для наглядной демонстрации этой гипотезы был создан MOAK. Он представляет из себя агентский workflow, который успешно эксплуатирует 98% CVE, которые есть в базе Known Exploited Vulnerabilities (KEV). Без участия человека. Вообще. Состоит он из следующих агентов: 🍭 Collector. От человека требуется лишь указать номер CVE, а дальше Collector соберёт нужную информацию 🍭 Researcher. Изучает CVE на основании данных, полученных от Collector. Анализирует патчи, идентифицирует уязвимые функции и т.д. 🍭 Environment Builder. Его задача – создание окружения, которое будет подходить под «условия» эксплуатации, определенные его «коллегами» 🍭 Exploiter. «Разработчик» необходимого для эксплуатации ПО и последующая эксплуатация с подтверждением 🍭 Judge. Проверяет, что все остальные агенты «качественно» провели свою работу С «примерами» работы MOAK можно ознакомиться в разделе «CVE Dashboard» на сайте. Там указаны примерные действия, которые делали агенты, успешность эксплуатации и, что самое интересное – время, которое потребовалось для того, чтобы всё это реализовать. И ещё там есть много интересных статей по теме, на которые стоит обратить внимание.

Trailmark: представление кода в виде графа Всем привет! Trail of Bits продолжают радовать интересными open-source проектами. В этот раз команда отдала в сообщество свою разработку – Trailmark. Утилита позволяет превратить исходный код в графовое представление (обогащенный граф вызовов и структуры приложения), к которому можно делать вызовы. В нём вершинами являются функции, методы, классы и другие сущности кода, а рёбрами — связи между ними: вызовы, наследование, вложенность, импорты и т.д. Основной задачей, которую хотели решить ребята, был поиск ответа на вопрос: «Могут ли эти недоверенные входные данные достичь этого участка кода?». Не без использования ИИ, конечно же. У Trailmark есть 3 основные «фазы» работы: 🍭 Parse. Задача фазы – получить информацию о функциях, методах, классах, структурах, интерфейсах и т.д. 🍭 Index. Реализация возможности быстрой работы с графом 🍭 Query. Верхнеуровневый API для взаимодействия с полученным графом На текущий момент реализована поддержка 17 языков, среди которых Python, JS, TS, PHP, Ruby, C, C++, C#, Java, Golang и не только. Установка, настройка, запуск, примеры результатов – всё это можно найти в GitHub-репозитории проекта. Больше информации, включая сценарии использования (да-да, не обошлось без LLM) и skills от Trail of Bits, которые используют Trailmark, можно найти в статье. Рекомендуем!

Безопасен ли код, генерируемый ИИ? Всем привет! Кода, который генерируется ИИ становится всё больше. И его явно будет становиться больше. Но безопасен ли этот код? Можно ли доверять ему «вслепую»? Если вам интересны ответы на эти вопросы, то рекомендуем обратить внимание на вот эту статью. В ней Автор берёт собственный проект, созданный LLM, подключает SonarCloud и получает 234 проблемы на первом же скане. Дальше показывает, как с этим жить обычному вайбкодеру: настраивает конвейер сборки, который блокирует деплой при провале анализа, объясняет принцип работы с инструментами. Статья будет полезна тем, кто активно использует LLM в разработке и хочет понять с чего начать в теме безопасности кода. А что вы думаете по этому поводу? Проводили ли подобные эксперименты?

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, ссылку на который можно найти в статье.