Работа с контейнерами Docker: разбор популярных утилит

Всем привет!

Иногда нам приходится возвращаться к Docker, чтобы протестировать и быстро оценить функционал нового приложения, инструмента, сканера. На помощь приходят удобные утилиты:
🎯 lazydocker – интерактивный терминальный UI для мониторинга контейнеров, образов, логов и ресурсов.
🎯 ctop – аналог htop, но для Docker: показывает загрузку CPU, RAM, диски, сети контейнеров.
🎯 cdebug – удобный инструмент для дебага контейнеров (позволяет пробрасывать в контейнер link до бинарников хоста).
🎯 dive – анализ слоев Docker-образов, помогает оптимизировать их размер и выявлять неэффективные сборки.
🎯 layeremove – пример скрипта на Python для удаления слоев из Docker-образов.

Если чего-то не хватает, можно использовать простые запросы к Docker, для вывода JSON — добавляй --format '{{json .}}'.
Например, чтобы получить данные об использовании ресурсов:

# Использование ресурсов
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
# Информация о контейнерах в json
docker ps --format '{{json .}}' | jq .

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

Как работает scheduling в Kubernetes?

Всем привет!

«Как именно Kubernetes «размещает» создаваемые `pod` на узлах кластера?» - если вам интересен этот вопрос, то статья может быть полезна.

В ней описывается весь процесс:
🍭 Попадание pod в Scheduling Queue
🍭 Фильтрация (Filtering) – «отбрасываются» узлы, на которых нельзя разместить pod (например, у узла статус Unreachable)
🍭 Выбор оптимального узла (Scoring) – выбор осуществляется из узлов, которые «прошли» предыдущий этап
🍭 «Назначение» pod определенному узлу (Binding)

Автор описывает все эти этапы достаточно детально, чтобы в голове сформировалось представление о том, что происходит «под капотом».

Затрагиваются такие темы, как Priority Class, Taints, Tolerations, (Anti) Affinity, Selectors и многое другое.

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

Анализ достижимости и приоритизация уязвимостей

Всем привет!

По ссылке можно найти статью от Xygeni, посвященную анализу достижимости и его пользе в расстановке приоритетов при работе с уязвимостями в open source компонентах.

Главный вопрос, на который надо найти ответ звучит примерно так: «А можно ли как-то исполнить уязвимый код во время работы (исполнения) ПО?». Именно для этого и используется анализ достижимости.

В статье Авторы раскрывают такие темы, как:
🍭 Что такое анализ достижимости и какие подвиды у него бывают
🍭 Почему этот анализ так важен для процесса управления уязвимостями в 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, что часто важно
🤷‍♂️ Не понятно как поведет себя с большим кол-вом данных

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

OWASP DevSecOps Guideline

Всем привет!

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

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

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

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

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

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

Всем привет!

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

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

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

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

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

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

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

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

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

Всем привет!

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

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

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

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

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-файлы ☺️

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

Всем привет!

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

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

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

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

Введение в OCI

Всем привет!

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

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

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

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

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

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

Всем привет!

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

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

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

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

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

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

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 внутри, то можно обратиться к этому разделу документации.

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

The State of Secrets Sprawl 2025

Всем привет!

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

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

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

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

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

Kubernetes Security Hardening CLI

Всем привет!

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

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

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

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

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

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

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

Всем привет!

При работе с уязвимостями многие (по крайней мере по началу) используют метрики, получаемые при использовании методологии 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.

Моделирование угроз: опыт 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. О нем мы писали тут

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

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

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

Container Security Site

Всем привет!

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

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

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

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