DevSecOps Talks

Runtime анализ с JAR Inspector Всем привет! «Используется ли артефакт, содержащий уязвимости, в промышленной среде?» - именно этот вопрос побудил Автора создать JAR Inspector. А еще Log4Shell, куда уж без него ☺️ Идея достаточно простая: создать решение, которое анализирует JVM, получает перечень всех загруженных JAR и подсказывает, какие из них используются, а какие – нет. Результатом стал JAR Inspector, который: 🍭 Предоставляет информацию о JAR-файлах в режиме реального времени 🍭 Отображает все приложения и их зависимости (включая транзитивные) в едином окне 🍭 Показывает информацию о том, что загружено и что используется 🍭 Архитектура минималистична: небольшой агент, который получает информацию о JAR, HTTP-сервер и Web UI, который отображает информацию. Запускается, в том числе, и через Docker, если хочется попробовать у себя. Больше информации можно найти в статье и в GitHub-репозитории проекта.

Надо ли переосмысливать подход к Vulnerability Management? Всем привет Процесс управления уязвимостями, если очень сильно упростить, сводится к тому, чтобы найти некую «CVE» и устранить ее путем обновления версии уязвимого компонента. Да, очень и очень упрощенный сценарий (как поиска, так и устранения уязвимости), но для сегодняшнего поста подойдет. Как правило, есть некое «окно», в котором отсутствует exploit, что делает уязвимость не такой опасной и дает больше времени на ее устранение. А что, если… AI научится генерировать exploit для разных CVE за считанные минуты? Именно этому и посвящена статья. Что сделали Авторы: 🍭 Взяли модель qwen3:8b, впоследствии - openai-oss:20b 🍭 Начали собирать информацию о «CVE» (git repo проекта, версии без уязвимости, описание «CVE» и т.д.) 🍭 Собранная информация использовалась в prompts, целью которых было найти уязвимый код и дать детальное описание уязвимости 🍭 Генерация exploit! Но не просто «пример кода», а PoC и уязвимое приложение, на котором он был протестирован Подробности всех шагов с примерами и комментариями можно найти в статье. В результате Авторам получилось создать exploits за очень короткий промежуток времени. Ознакомиться с ними можно по ссылкам, доступным в статье. Получается, что надо переосмыслить подход к управлению уязвимостями? Что практика «обнаружить и обновить» перестанет работать со временем? Усилить контроль среды исполнения, чтобы даже при наличии CVE эксплуатировать ее было невозможно? … Что вы думаете по этому поводу?

Kubernetes Copilot Всем привет! Еще один пример использования LLM при работе с Kubernetes – небольшая утилита, получившая название Kubernetes Copilot. Для работы потребуется kubectl, Trivy (об этом чуть позже) и, конечно же, API-ключ для взаимодействия с LLM. На текущий момент поддерживается OpenAI, Gemini и Ollama. Kubernetes Copilot позволяет: 🍭 Анализировать проблемы, возникающие с определенным ресурсом 🍭 Проводить аудит безопасности выбранного ресурса (как раз тут и используется Trivy) 🍭 Выполнять команды, получаемые из prompt 🍭 Генерировать манифесты Kubernetes и не только Примеры команд можно найти в GitHub Repo проекта. Все очень минималистично и просто. Единственное, чего не хватает – примеров результатов работы Kubernetes Copilot.

AppSec и реагирование на инциденты ИБ Всем привет! Недавно на Tryhackme появилась новая комната, которая объединяет в себе безопасность приложений и реагирование на инциденты ИБ. «Комната» состоит из 5 основных частей, если не считать Introduction и Conclusion. Участников ожидает: 🍭 AppSec IR Fundamentals 🍭 Preparing for Application Incidents 🍭 Responding to an Application Incident 🍭 Remediation and Recovery 🍭 Practical Для прохождения не требуется каких-то особенных знаний, за исключением общего понимания концептов безопасности приложений и реагирования на инциденты ИБ. «Комната» рассчитана на 60 минут. Удачи! 😊

Погружение в Kubernetes Security Context Всем привет! Kubernetes предлагает разные возможности, которые можно использовать для повышения степени защищенности кластера. Одной из таких возможностей является Security Context. Если вы еще не знакомы с тем, что это такое и зачем оно нужно, то эта статья может вам подойти. Автор разбирает: 🍭 Что это такое, какие бывают и в чем между ними разница 🍭 Pod-Level Security Context 🍭 Container-Level Security Context 🍭 Различия между Pod-Level и Container-Level 🍭 Рекомендации по использованию и не только Для каждого отдельно взятого Security Context приводится описание, сценарии использования и небольшой демонстрационный пример. То, что надо для первичного ознакомления и погружения в тематику 😊

Secure Vibe Coding Guide Всем привет! Vibe Coding стал уже чем-то обыденным и все больше и больше людей его используют и создают ПО «совместно» с LLM. И где-где, а вот тут безопасность точно нужна. В соответствии с исследованием, около 40% генерируемого кода не является безопасным. В статье Автор рассматривает check list, который, по его мнению, может быть полезен при обеспечении ИБ для Vibe Coding. Например: 🍭 Vibe Coding Security Fundamentals 🍭 Application Security и API Security-практики 🍭 AI Specific Risks 🍭 Secure Vibe Coding Prompts и не только Для каждого раздела приводятся общие рекомендации и небольшие уточнения по ним. Чего-то сверх детального вы не найдете, но «общий взгляд» на вопрос получился достаточно интересный.

Krew — менеджер плагинов kubectl Всем привет! Когда-то давно упоминали krew 1, 2, 3. Но так и не рассказали, что это такое. Krew — пакетный менеджер, работает как apt или brew, но для плагинов kubectl. 🎯 Помогает находить, устанавливать и обновлять плагины 🎯 Делает плагины кроссплатформенными и легко управляемыми 🎯 В каталоге более 300 плагинов: от RBAC-аудита до инструментов отладки сети и работы с секретами Дополнительно можно посмотреть топ 15 kubectl плагинов для security инженеров в 2025 по мнению Sysdig или другие обзоры 1, 2 Однако стоит помнить о рисках безопасности: Исследование Trend Micro отмечает, что «любой желающий может разработать свой kubectl-плагин и опубликовать его через Krew. При этом нет никакой проверки безопасности» Используете krew в работе?

AspGoat: vulnerable ASP.NET Web App Всем привет! В полку «damn vulnerable»-приложений прибыло. Недавно был выпущен проект Asp.Goat – заведомо уязвимое приложение, созданное на базе ASP.NET. Внутри «все по классике»: 🍭 XSS 🍭 CSRF 🍭 SQLi 🍭 XXE 🍭 LFI 🍭 RCE и не только Небольшое демо того, как выглядит приложение можно найти в GitHub-репозитории проекта. Запускается с использованием Docker и сразу доступно для исследования и изучения, альтернативный способ – через dotnet. P.S. На всякий случай напоминаем, что цель подобных проектов – обучение и только обучение ☺️

10–11 сентября в Москве проходит IT Elements 2025 — крупнейшая конференция об ИТ-инфраструктуре, сетях, кибербезопасности, данных и ИИ. 2000+ участников ежедневно, топовые спикеры и реальные кейсы. Подготовили для вас подборку выступлений по теме DevSecOps, которые советуем посетить: Доклад «Keyless commit sign. Как подписывать коммиты без использования секретного ключа?» (Павильон ИБ с 17:00 до 17:30) СПИКЕР: Саленый Дмитрий, DevSecOps-инженер, Единый ЦУПИС Доклад «ML-инструменты в безопасности облака» (Павильон ИБ с 16:30 до 17:00) СПИКЕР: Яньков Павел, Cloud Security Expert, Т-Банк Круглый стол «Безопасная разработка. От слов к делу» (Зал «Энергия» с 18:00 до 19:00) МОДЕРАТОР: Антон Конопак, руководитель группы DevSecOps, «Инфосистемы Джет» СПИКЕРЫ: Алина Сагирова, бизнес-партнёр по безопасности приложений TechLead, Альфа-банк Георгий Старостин, директор дирекции информационной безопасности «Согаз» Илья Шаров, руководитель центра практик DevSecOps, МТС Web Services Максим Щедрин, начальник управления тестирования безопасности ГК «Иннотех» Подробности на сайте конференции.

10–11 сентября в Москве проходит IT Elements 2025 — крупнейшая конференция об ИТ-инфраструктуре, сетях, кибербезопасности, данных и ИИ. 2000+ участников ежедневно, топовые спикеры и реальные кейсы. Подготовили для вас подборку выступлений по теме DevSecOps, которые советуем посетить: Доклад «Keyless commit sign. Как подписывать коммиты без использования секретного ключа?» (Павильон ИБ с 17:00 до 17:30) СПИКЕР: Саленый Дмитрий, DevSecOps-инженер, Единый ЦУПИС Доклад «ML-инструменты в безопасности облака» (Павильон ИБ с 16:30 до 17:00) СПИКЕР: Яньков Павел, Cloud Security Expert, Т-Банк Круглый стол «Безопасная разработка. От слов к делу» (Зал «Энергия» с 18:00 до 19:00) МОДЕРАТОР: Антон Конопак, руководитель группы DevSecOps, «Инфосистемы Джет» СПИКЕРЫ: Алина Сагирова, бизнес-партнёр по безопасности приложений TechLead, Альфа-банк Георгий Старостин, директор дирекции информационной безопасности «Согаз» Илья Шаров, руководитель центра практик DevSecOps, МТС Web Services Максим Щедрин, начальник управления тестирования безопасности ГК «Иннотех» Подробности на сайте конференции.

Cracking the Vault: как искали и нашли zero-day в HashiCorp Vault Всем привет! 👋 Команда Cyata обнаружила девять ранее неизвестных zero-day уязвимостей в ядре HashiCorp Vault, некоторые были в коде почти десяток лет. Баги затрагивали как open-source, так и Enterprise версии и уже были исправлены HashiCorp. Это не memory corruption или race condition, а тонкие логические уязвимости в аутентификации, идентификации и политиках Vault — они подрывают Vault как основу «модели доверия» инфраструктуры. Cyata выявили их вручную, через глубокий анализ логики. Кратко по находкам: 🎯 Userpass backend: - CVE-2025-6010: различный ответ при неверном логине → можно узнать, существует ли пользователь - CVE-2025-6004: изменение регистра (Admin vs admin) сбрасывает счетчик блокировок - CVE-2025-6011: тайминговая атака через разную обработку несуществующих юзеров 🎯 LDAP backend + MFA: - CVE-2025-6004 (опять): из-за некорректной нормализации (пробелы, регистр) можно обойти блокировку - CVE-2025-6003: при username_as_alias=true и MFA по EntityID, MFA может вообще не тригериться 🎯 TOTP MFA — целая цепочка багов: - Выдаёт разные ошибки по reuse, позволяя узнать, был ли использован код - Тримминг пробелов отключает защиту one-time-use - TTL и глобальный кэш позволяют обойти rate-limit через entity-switching или ожидание создав skew window → всё это объединено в CVE-2025-6016 🎯 Аутентификация по сертификатам и entity impersonation: - CVE-2025-6037: в non-CA режиме владелец приватного ключа может подменить CN и аутентифицироваться от имени другой сущности 🎯 Privilege escalation и RCE — самые критичные: - CVE-2025-5999: позволяет поднять привилегии до root через неверную нормализацию policy - CVE-2025-6000 — первый публичный RCE в Vault, позволяющий взять систему под полный контроль через каталог плагинов (цепочка из disclosure → запись файла → выставление execute → регистрация плагина) Статья (≈38 мин) технически глубокая и нацеленная на практику — авторы показывают не только факт находки, но и путь обнаружения через схемы и видео.

KubeGuard: Kubernetes Security Scanner Всем привет! Еще-один-open-source-сканер, позволяющий выявлять нарушения в конфигурации ресурсов кластера Kubernetes – KubeGuard. Он позволяет: 🍭 Производить статический анализ манифестов на наличие ИБ-дефектов 🍭 Сканировать созданные в кластере ресурсы на наличие ИБ-дефектов 🍭 Генерировать отчеты (в формате JSON) 🍭 Автоматизировать работу с использованием REST API «Из коробки» доступно более 25 правил, включающих, в том числе, проверки на соответствие CIS Benchmark. Аналитическую информацию можно посмотреть в Grafana. Например, информацию о сканированиях, ИБ-дефектах, потреблении ресурсов KubeGuard’om. Подробности об установке и настройке можно найти в GitHub-репозитории проекта. Важно: проект еще очень молодой и не успевший набрать "звезд" от сообщества (первый коммит месяц назад)

Поиск ИБ-дефектов в исходном коде с использованием LLM Всем привет! Команда Semgrep провела небольшое исследование. Они использовали Claude Code и OpenAI Codex для поиска ИБ-дефектов в исходных кодах 11 популярных Python-приложений. Суммарно было найдено более 400 ИБ-дефектов, которые команда проверила. Получилось следующее: 🍭 Claude нашел 46 ИБ-дефектов (14% - TPR, 86% - FPR) 🍭 Codex – 21 ИБ-дефект (18% TPR, 82% FPR) 🍭 Лучше всего получалось находить IDOR (Claude) и Path Traversal (Codex) 🍭 Самой большой сложностью был taint-анализ среди нескольких файлов 🍭 И да, нюансы с идемпотентностью никуда не делись. Разные запуски могли давать разные результаты Детали исследования можно найти в статье (а там много всего интересного). Из приятного – у Semgrep есть мысли о том, чтобы отдать полученный dataset в «общественное использование» ☺️

Netflix и Dependency Confusion Всем привет! Зачем смотреть Netflix, когда можно его «сломать»? Примерно такие мысли были у Автора статьи, когда он решил проверить: получится ли использовать атаку Dependency Confusion против IT-гиганта? Dependency confusion это по сути подмена: вместо «целевой» библиотеки (например, npm илт PyPi) пользователь получает ту, что собрал злоумышленник. Однако, какую именно библиотеку надо «подменять»? Это можно посмотреть в манифесте (который неоткуда взять) или воспользоваться «доступными средствами». Именно второй путь и выбрал Автор. Он реализовал следующий алгоритм: 🍭 Запись HAR-файла, в котором были все запросы и ответы веб-сессии 🍭 Анализ полученных данных 🍭 Идентификация скачанных файлов 🍭 Проверка того, что скачанные библиотеки (не) доступны в публичных реестрах, что есть более новые версии и т.д. Спустя некоторое время Автору повезло и он нашел nf-cl-logger. «Вряд ли Netflix ходит во вне за пакетами». «А вдруг есть ошибки в настройках ноутбука разработчика или инженера?». Интерес взял верх ☺️ Payload использовался крайне простой – получение обычной информации о рабочей станции. Просто проверка гипотезы. И она была подтверждена. Притом достаточно быстро! Ну а подробности, как обычно, в статье. Приятного чтения! ☺️

Alfa CTF: Surfing Edition! 🏄‍♂️ Всем привет! Alfa CTF – мероприятие от Альфа Банка, в котором можно попробовать новое, испытать себя и прокачаться в кибербезопасности! Ребята предлагают обширный набор заданий, который включает в себя и безопасную разработку. Вас ждут: 🍭 Web. Получить доступ к базе сайта, купить товар без денег, скачать файл (доступный только администратору) 🍭 Reversing. Понять алгоритм программы без исходников, обойти проверки в приложении, разобраться в протоколе между приложением и бэкэндом 🍭 Pwn. Переполнение буфера, ошибки при работе с кучей, стеком, перетирание указателей в памяти Регистрация открыта до 13-ого сентября! Подробности о сроках, поиске команды, правилах и, конечно же, призах можно найти по ссылке на мероприятие. P.S. Задания будут разной сложности, опыт в CTF не обязателен, главное – желание!

Основы Taint Analysis Всем привет! SAST это не только «поиск по шаблонам», многие решения включают в себя более сложные механизмы поиска ИБ-дефектов, включая Taint Analysis. Если упростить, то это нечто вроде анализа «пути жизни данных» - от их передачи в ПО до использования в различных методах. По ссылке можно прочесть небольшую статью, в которой кратко и просто объясняется, что это такое и как это работает. Статья содержит разделы: 🍭 Основные концепты: sources, sinks, sanitizers 🍭 Принципы работы Taint Analysis 🍭 Примеры паттернов для уязвимостей (SQLi, XSS, Command Injection, Path Traversal) 🍭 Как писать правила для Taint Analysis Никакой воды, много примеров и доступных объяснений. Самое «то» для начала погружения в тематику и основы ее работы. P.S. Помимо описания Taint Analysis на сайте представлен аналогичный материал для Control и Data Flow Analysis.

Плагины и утилиты для Helm Всем привет! Helm’a при всем его (не) удобстве не всегда бывает достаточно. Иногда хочется как-то расширить его функционал. И именно этому посвящена статья – набору плагинов и утилит, которые помогут решить наиболее часто встречающиеся задачи. Например: 🍭 helm-diff – анализ изменений до их применения 🍭 helm-docs – автоматическая генерация документации для чартов 🍭 trivy – анализ чартов на наличие уязвимостей 🍭 helm-mapkubeapis – анализ устаревших (deprecated) версий API и не только Для каждого плагина/утилиты Автор кратко описывает назначение, преимущества от использования и ссылки на GitHub Repo. А чтобы вы добавили/удалили из этого перечня?

Использование AI для анализа CVE Всем привет! В статье описан опыт NVidia по анализу CVE в контейнеризованных приложениях с использованием AI. Проблематика известная и понятна: «традиционный подход» - проанализировать и использовать обновление – на больших масштабах работает не очень хорошо. Особенно с учетом того, что многие результаты не релевантны: сканер ошибся, уязвимый метод не достижим, не рассматривается контекст (например, используемые меры защиты или окружение, в котором разворачивается ПО). Если рассматривать процесс управления уязвимостями, как последовательность шагов «Scan», «Investigate», «Decide», «Mitigate» и «Publish», то перед NVidia стояла задача сокращения этапа «Investigate». На этом этапе как раз и определяется – является ли уязвимость эксплуатируемой или нет, что влияет на следующие шаги процесса и принимаемые решения. Если кратко, то используется следующий алгоритм: 🍭 Генерируется список действий (проверить наличие уязвимости, наличие JRE и т.д.) 🍭 Каждый элемент списка действий анализируется LLM. При этом используются внешние источники: SBOM-файлы, информация о репозиториях, данные от TI и т.д. 🍭 Завершается все анализом полученных результатов, формирование мнения относительно возможности эксплуатации CVE (в том числе в формате VEX) Примеры того, как это выглядит можно найти в статье. Кроме того, есть краткое описание процесса по управлению уязвимостями, реализованном в NVidia: от момента помещения нового контейнера в реестр до формирования VEX-файлов.

Multipart Parsers: примеры обхода Всем привет! Парсеры multipart/form-data не всегда работают корректно и есть разные способы для того, чтобы их обойти. В статье (~ 27 минут) разбираются некоторые примеры того, как именно это можно сделать. Начинается статья с того, что Автор описывает стандартные способы проверки (расширение файла, magic bytes, content-type и т.д.) и что такое multipart\form-data. Дальше – сами техники обхода: 🍭 duplicated name parameter 🍭 breaking the CRLF seuqences 🍭 removing double quotes 🍭 missing closing boundary string 🍭 filename*=utf-8'' in request Помимо этого, в статье есть информация о том, как можно обходить разные WAF. Каждый пример, приведенный в статье подробно описан, с кодом и пояснениями. Проверка передаваемых параметров – задача крайне важная и статья может помочь в том, чтобы понять на что обращать внимание и как сделать этот процесс более безопасным.