DevSecOps Talks

Ingress Nightmare: hands-on lab

Всем привет!

Новость об Ingress Nightmare очень быстро распространилась по сети и, вероятно, станет одной из «наиболее часто обсуждаемых уязвимостей» в 2025. По крайней мере для мира безопасности сред контейнеризации.

Если вам не хватило множества описаний и хочется посмотреть, как оно работает «на деле», то в этом repo собрана необходима информация.

Внутри можно найти алгоритм действий и необходимые скрипты для того, чтобы проэксплуатировать CVE-2025-1974.

Кстати, помимо этого, в repo есть и другие лабораторные работы по безопасности Kubernetes. Подробнее про него мы писали тут.

Идентификация вредоносного кода

Всем привет!

Убеждать кого-то о важности защиты от атаки на цепочку поставок вряд ли придется. Множество вредоносных пакетов в пакетных индексах, некорректные конфигурации сборочных сред, образы контейнеров с майнерами и многое другое.

Немного тяжелее становится, когда речь заходит о том как быть и что делать? Тема сама по себе довольна обширная и существуют разные подходы по противодействию.

Чтобы немного упростить задачу рекомендуем ознакомиться со статьей от Apiiro, в которой они рассказывают про то, как идентифицируют вредоносный код.

Не только словом! Команда предоставила в общий доступ несколько своих наработок.

Это:
🍭 Набор правил для Semgrep (Opengrep) для идентификации вредоносного кода
🍭 PRevent – анализ PR GitHub на наличие чего-то подозрительного

Инструменты можно использовать для анализа различных языков: Java, PHP, Ruby, Golang и т.д. А о том, чем именно руководствовались Авторы при разработке правил и утилит, можно узнать в статье.

В завершении (Appendix A) приведена статистика о True/False Positive при использовании наработок Apiiro применительно к Malicious Software Packages Dataset, подготовленного DataDog

API Pentesting Tools

Всем привет!

Давно не было awesome-подборок, решили это поправить ☺️ По ссылке доступны наборы open source инструментов, которые могут пригодиться при ИБ-анализе API.

Материал структурирован по разделам:
🍭 Reconnaisance
🍭 AuthN, AuthZ Testing
🍭 Input Validation Testing
🍭 Security Headers, CORS Testing и не только

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

А вы пользуетесь такими подборками или не видите в них смысла?

Container Security Site

Всем привет!

Rory McCune – личность достаточно известная в мире информационной безопасности контейнеров и сред контейнеризации.

У него, помимо превосходных статей и выступлений, есть сайт, в котором он агрегирует разную информацию по теме как для атакующих, так и для защищающихся.

Внутри можно найти:
🍭 Attackers: Compromised Container Checklist
🍭 Attackers: Compromised User Credentials Checklist
🍭 Container Breakout Vulnerabilities
🍭 Defenders: Container Image Hardening
🍭 Reading List и многое другое

Крайне полезный ресурс, если вам интересна тема защиты контейнеров. Однозначно рекомендуем к изучению!

DNS resolution в Linux и Kubernetes

Всем привет!

«It’s always DNS!» Да, все так. Нет, не баян, а классика ☺️ Для получения представления или усиления существующего рекомендуем вам ознакомиться со статьей.

Все началось с того, что Автор получил сообщение об ошибке: Nameserver limits were exceeded, some nameservers have been omitted.

Это послужило началом приключения, которое описано в статье. Автор делится своими знаниями о том, как устроен DNS resolution в Linux и Kubernetes.

В статье можно найти информацию о:
🍭 Общая теория DNS в Kubernetes
🍭 DNS в Linux: resolv.conf и nssswitch.conf
🍭 Что изменится при использовании, например, Alpine?
🍭 DNS в Kubernetes: kube-dns, настройки и модификации, dnsPolicy

Все это описывается максимально подробно, с примерами, комментариями и ссылками на документацию по теме.

А в завершении, конечно же, ответ на вопрос – «А почему же Автор получил такое сообщение об ошибке». Рекомендуем к прочтению!

Моделирование угроз: опыт Trail of Bits!

Всем привет!

По ссылкам доступны статьи, посвященные моделированию угроз (раз, два) и тому, как этот процесс реализован в Trail of Bits.

История стара, как мир: есть очень много всего интересного и полезного. Однако, нам ничего не подошло, и мы сделали свое – TRAIL.

За основу TRAIL был взят Rapid Risk Assessment и дополнен материалами из NIST (SP 800-154, 800-53).

Первая статья посвящена тому, зачем нужна TRAIL и как она работает. Команда использует разный уровень детализации – Lightweight и Comprehensive Threat Model. Разница в уровне детализации, примеры приведены в статье.

Вторая статья посвящена тому, как сделать процесс моделирования угроз непрерывным. Грубо говоря, что делать дальше, когда модель угроз уже есть, а ПО продолжает развиваться?

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

Единственный «нюанс» статей, что они достаточно поверхностные, хочется больше деталей и примеров того, как это работает ☺️

P.S. А еще у Trail of Bits есть Testing Handbook, в котором собрана часть их опыта по AppSec и DevSecOps. О нем мы писали тут

Обогащение информацией об уязвимостях

Всем привет!

При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии Comon Vulnerability Scoring System (CVSS).

Такие данные, например, доступны в National Vulnerability Database (NVD) – CVSSv2, CVSSv3, CVSSv4 (крайне редко, если вообще).

Нюанс заключается в том, что в NVD указаны результаты расчета Base Metric Group в соответствии с методологией. Temporal и Environmental «части» не участвуют в оценке. Хотя они могут сильно влиять на итоговый результат.

Чтобы как-то это исправить, рекомендуем обратить внимание на проект cvss-bt, который частично решает эту проблему и добавляет Temporal/Threat Metrics.

Работает это примерно так:
🍭 Каждое утро осуществляется синхронизация EPSS
🍭 При изменении EPSS Score обновляются данные по CVSS из NVD
🍭 Рассчитывается новая оценка с учетом Temporal/Threats. Данные берутся из CISA KEV, VulnCheck KEV, Metasploit и не только)
🍭 Новая оценка (вместе с исходной) устанавливается для CVE

В итоге получается CSV-табличка, которую можно скачать из repo. В ней содержится обогащенная информация по CVE согласно вышеописанному алгоритму.

Из нее наглядно видно, как могут измениться уровни критичности уязвимостей при добавлении новых данных. А ведь есть еще Environmental-часть той самой методологии…

P.S. Кстати, если вы никогда не задумывались как именно это считается, но очень хочется узнать – в repo есть ссылки на спецификации CVSSv2, v3, v3.1 и v4.

Kubernetes Security Hardening CLI

Всем привет!

Kube-Sec – еще одна утилита, которая позволяет анализировать конфигурации Kubernetes-кластеров для идентификации ИБ-дефектов.

При помощи нее можно найти:
🍭 Privileged Containers
🍭 RBAC Misconfigurations
🍭 Publicly Accessible Services
🍭 Pods Running as Root и не только

Проверки можно настраивать (включать/отключать), результаты предоставляются в качестве JSON/CSV.

В ближайшее время Автор собирается добавить регулярные сканирования (ежедневные/еженедельные)

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

Важно: проект пока что не является production ready со слов Автора и все еще находится в стадии разработки.

The State of Secrets Sprawl 2025

Всем привет!

В приложении можно найти отчет (~46 страниц) от GitGuardian, посвященный утечкам конфиденциальной информации, а именно – секретов.

Казалось бы, одна из самых базовых рекомендаций – не «храните» секреты в исходном коде и конфигурационных файлах – однако, год от года количество компрометированных секретов растет.

В отчете много статистической информации:
🍭 58% всех секретов – Generic (обычные строки для подключения к чему-либо)
🍭 35% просканированных private repo содержали хотя бы 1 секрет в открытом виде
🍭 Наиболее «популярный» секрет в private repo – ODBC connection string
🍭 Если говорить об образа контейнеров, то самое популярное место для поиска секретов – да, конечно, ENV (65% найденных секретов)
🍭 Большинство секретов остается «активными» после того, как их нашли
🍭 И многое другое

Отчет получился очень интересным, информативным и насыщенным.

Читается легко, «воды» практически нет, зато есть много данных для размышления. Рекомендуем! ☺️

Bearer: open source SAST

Всем привет!

Bearer – open source SAST от команды Cycode. Как и многие другие SAST-решения он может искать как ИБ-дефекты в исходном коде, так и секреты.

Поддерживается следующий набор языков: Golang, Java, JavaScript, TypeScript, PHP, Python и Ruby.

Количество правил варьируется – от 66 для PHP до 88 для Python. Ознакомиться с ними можно вот тут (само правило, описание, рекомендации, полезные ссылки и соотношение с CWE).

Отличительной особенностью Bearer является то, что он может анализировать использование чувствительной информации, например, имена, номера телефонов и т.д. С полным перечнем можно ознакомиться тут.

По завершению работы можно получить несколько отчетов – Security Report, Privacy Report и Data Types Report.

Если вам интересно как работает Bearer внутри, то можно обратиться к этому разделу документации.

Кстати, она достаточно емкая, удобная и информативная – рекомендуем к изучению для лучшего знакомства со сканером ☺️

Сравнение LLM для моделирования угроз

Всем привет!

По ссылке можно найти результаты сравнения возможностей LLM по моделированию угроз.

В выборку попали: gemma, Phi, DeepSeek, llama и не только.

Сравнение проводилось по группам критериев:
🍭 STRIDE Coverage & Accuracy: насколько модель покрывает все группы угроз в соответствии с методологией STRIDE
🍭Threat Completeness: показывает количество угроз, качество описания
🍭Technical Validity: насколько описание является технически корректным и релевантным
🍭JSON Structure Compliance: проверка корректности заполнения и формата данных в итоговых результатах

Все результаты представлены в виде интерактивных графиков – общие результаты, результаты по приведенным выше группам и т.д.

Больше подробностей про саму методологию можно найти в соответствующем разделе сайта.

P.S. Кстати, это сравнением сделал Matt Adams – Автор STRIDE GPT, о которой мы писали тут.

Введение в OCI

Всем привет!

При работе с образами контейнеров вы, вероятно, слышали про то, что они создаются в соответствии со спецификацией Open Container Initiative, OCI.

Но что это значит? Если вас интересует ответ на этот вопрос, то рекомендуем прочесть статью.

В ней Автор разбирает несколько типов OCI-спецификаций:
🍭 OCI Image-spec: структура образов контейнеров
🍭OCI Distribution-spec: способы распространения образов контейнеров
🍭OCI Runtime-spec: реализация жизненного цикла контейнеров

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

В завершении приведены ссылки на полное описание спецификаций, если вам интересно разобраться более подробно

Finalizers в Kubernetes: что это и зачем?

Всем привет!

Наверное, при работе с Kubernetes вы встречались с тем, что после kubectl delete … удаляемый ресурс «подвисал» в состоянии terminating.

Зачастую причина этого состояния кроется в finalizers - тех самых «очень важных делах», не совершив которые нельзя упокоиться с миром удалять что-либо.

Просто и понятно о них описано в статье:
🍭 Автор делает собственный finalizer и пытается удалить ресурс
🍭Поясняет что делать, если terminating все-таки висит
🍭 Рассказывает о том, что есть finalizer и как они устроены

Статья небольшая, зато дает общее представление о том, как «победить» состояние бесконечного удаления.

Bomber: анализ BoM-файлов

Всем привет!

Bomber – утилита, которая позволяет анализировать BoM-файлы для идентификации уязвимостей в open source компонентах.

Он может работать с разными форматами BoM-файлов: SPDX, CycloneDX, Syft. В качестве источников данных об уязвимостях используются индексы (providers): OSV, GHSA, OSS Index (Sonatype) и Snyk.

По результатам анализа Bomber предоставляем информацию:
🍭 Пакетный менеджер
🍭 Зависимость, ее версия
🍭 Уязвимость (CVE), ее критичность
🍭 EPSS

Помимо этого, он также анализирует информацию об используемых лицензиях.

Сами отчеты можно получить, как в stdout, так и в JSON и HTML-форматах.

Больше о возможностях утилиты можно прочесть в repo проекта.

P.S. Еще одной интересной особенностью Bomber является сканирование целой папки, внутри которой находятся BoM-файлы ☺️

Как TruffleHog ускорил поиск секретов за счет алгоритмических оптимизаций

Всем привет!

Отличная статья о том как TruffleHog обновил алгоритмы сканирования, ускорив поиск утекших секретов. Теперь сканирование быстрее без потери точности – за счет оптимизации переходов при построении автомата Aho-Corasick.

Что изменилось?
🎯 Один проход по коду: ~800 ключевых слов от всех детекторов проверяются за раз, без повторных циклов
🎯 Aho-Corasick + предвычисления: заранее просчитаны переходы состояний, что сократило CPU-нагрузку
🎯 Быстрее на 11–17%: особенно заметно на больших репозиториях
🎯 Масштабируемость: добавление новых детекторов больше не замедляет анализ. Применение Aho-Corasick обеспечивает линейную масштабируемость по объему данных
🎯 Следующий шаг — оптимизация памяти и ускорение сканирования до 22–40%

Подробнее – в разборе алгоритма

Используете TruffleHog? 🐽

Компрометация данных через session tokens…

Всем привет!

… или еще одна история о том, как заработать 15 000$ на bug bounty. Все начиналось как обычно, bug hunter взял «заказ» на Hackerone на уже знакомую ему систему.

События начали стремительно развиваться после того, как он заполнил данные на странице регистрации – имя, email, прочую информацию.

Оказывается, что сервер вернул сессионный token, но не простой, а без… expiration date. Это заинтересовало исследователя и он решил продолжить изучение.

После завершения регистрации и создания учетной записи приложение перенаправило его на страницу вида https://somesite.com/apply/information/?s=success&token=… Все так, там был «тот самый token без срока действия».

Следующий шаг вполне логичен – попробовать поискать аналогичные token в сети. Google Dorks в помощь и да, token был получен, как и доступ к конфиденциальной информации его владельца.

В завершении статьи описываются дополнительные исследования Автора относительно того, сколько по времени подобная уязвимость была в приложении. Рассказывать не будем, рекомендуем прочесть статью 😊

Анализ угроз для ArgoCD

Всем привет!

Команда Exness написала отличную статью, посвященную идентификации ИБ-угроз, характерных в случае использования GitOps подхода и ArgoCD в частности.

После небольшого знакомства с ArgoCD и ее ключевыми компонентами/сущностями Авторы углубляются в то, как можно реализовать мониторинг возможных угроз.

Рассматриваются угрозы из «ArgoCD End User Threat Model», например:
🍭 Initial admin password compromise
🍭 Abuse of Argo CD local users
🍭 External cluster credentials compromise
🍭 Abuse of unrestricted default project и не только

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

Статья не затрагивает темы защиты, фокусируясь полностью на идентификации. Причина проста – защита потребовала бы отдельной статьи по теме 😊

🔍 TruffleHog Analyzer – анализ утекших API-ключей

Всем привет!

Обнаружение секретов в коде – уже стандарт, но что делать, если ключ утек? TruffleHog предлагает новый подход: trufflehog analyze позволяет провести глубокий анализ ключа, выяснив, какие у него разрешения и какие ресурсы он затрагивает. Теперь можно не только находить ключи, но и сразу понимать их влияние.

🎯 Проверяет активность ключа – действующий он или нет
🎯 Определяет владельца – чей именно ключ
🎯 Анализирует доступ – какие ресурсы доступны по ключу (доступно до 20 источников)
🎯 Выявляет привилегии – что можно делать с этими ресурсами
🎯 Помогает в отзыве – инструкция как отозвать секрет

Если хотите разобраться глубже – вебинар по теме.

Как вы проверяете утекшие ключи? Пользуетесь ли авто-валидацией? Делитесь в комментариях! 💁‍♂️

OWASP DevSecOps Guideline

Всем привет!

Как-то так получилось, что мы ни разу не писали про материалы по DevSecOps от OWASP, а именно про OWASP DevSecOps Guideline.

В нем собрана информация о:
🍭 Моделировании угроз
🍭 Статическом и динамическом анализе
🍭 Композиционном анализе
🍭 Анализе образов и контейнеров и т.д.

Для каждого раздела описано что это такое и какими open source инструментами можно пользоваться для реализации практики.

Кроме этого, есть ссылки на полезные материалы по теме.

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

Централизованное управление уязвимостями

Всем привет!

Когда сканеров становится много, а уязвимостей еще больше, неплохо бы иметь единое место для их сбора, фильтрации и приоритизации. SecObserve (open-source) – может стать новым отличным решением на замену DefectDojo:

Платформе меньше двух лет, но уже доступно множество фич:
🎯 Интегрируется в CI/CD, поддерживает SARIF и парсеры на множество инструментов
🎯 Удобное управление проектами – поддержка веток и версий
🎯 Отслеживает лицензии – импорт информации из SBOM (CycloneDX и SPDX)
🎯 Обогащает данные с помощью Exploit Prediction Scoring System (EPSS)
🎯 Дает метрики как по всем продуктам так и по отдельным
🎯 Экспортирует уязвимости в трекеры (Jira, GitLab, GitHub), отправляет уведомления в Slack, Teams, email
🎯 REST API для автоматизации
🎯 Хорошая документация

Из минусов:
🤷‍♂️ Нет поддержки LDAP, что часто важно
🤷‍♂️ Не понятно как поведет себя с большим кол-вом данных

А вы как управляете уязвимостями в проектах?