Графический генератор Audit Policy для Kubernetes

Всем привет!

Команда «Штурвала» сделала «Генератор политик аудита» для Kubernetes. С его помощью можно создавать требуемые политики в удобном web-интерфейсе!

Для этого потребуется
🍭 Перейти по ссылке выше
🍭 Создать правило, на которое будет срабатывать политика
🍭 Указать необходимые параметры (уровень логирования, ресурсы, глаголы и т.д.)
🍭 Повторить до желаемого результата

Ресурс пока что находится в стадии beta-тестирования.

Если вдруг вы найдете что-то, что не работает или у вас есть мысли по развитию функционала, то можете смело их адресовать в Telegram-чат «Сообщества Штурвал» 😊

mTLS в Kubernetes

Всем привет!

Mutual TLS очень полезная функция, особенно когда дело касается информационной безопасности.

Для начала погружения в тему очень может подойти вот эта статья.

В ней Автор разбирает:
🍭 Краткое описание того, что такое mTLS и зачем он нужен
🍭 «Сделай сам!»-реализация с изменением логики работы приложения
🍭 Использование Service Mesh для достижения цели
🍭 Реализация mTLS на основе Ambient Mesh
🍭 Общие рекомендации о том, как это можно сделать

Статья небольшая, дает общение понимание что и зачем и как это можно реализовать. Самое «то» для пятницы ☺️

AppSec метрики от SNYK

Всем привет!

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

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

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

Сегодня хотим обратить ваше внимание на подборку AppSec-метрик от SNYK. Возможно, что-то покажется вам полезным.

Ребята разделили их на 4 блока:
🍭 Risk reduction metrics
🍭 Team coverage and engagement
🍭 Application security posture trends
🍭 Vulnerability management efficiency

Для каждого блока приводится набор метрик с качественным описанием и общей логикой расчета (без формул и математики).

Docker Init

Всем привет!

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

Чтобы упростить задачу можно использовать docker init. С его помощью можно создать dockerfile, compose.yaml и .dockerignore автоматически.

Работает это примерно так:
🍭 Вы запускаете docker init и попадаете в интерактивную сессию
🍭 Потребуется указать используемую технологию (Node, Go, Python и т.д.)
🍭 Определиться с командой, которая должна быть запущена в контейнере
🍭 Написать порт, по которому можно обращаться к ПО
🍭 Готово!

Да, возможно не самый лучший вариант, но для начала вполне неплохо. Подробнее об использовании docker init можно прочесть в статье.

Autogrep!

Всем привет!

Да, вам не кажется! Это то, о чем вы подумали! Автоматическое создание правил для Semgrep с использованием нейронных сетей.

Если кратко, то его возможности заключаются в:
🍭 Создании правил для Semgrep на основе информации из патчей с исправленными уязвимостями
🍭 Анализе качество создаваемых правил
🍭 Поддержке различных языков программирования, для которых создаются правила.

В использовании тоже нет ничего сложного: скачиваем утилиту, создаем правила, используем их вместе с Semgrep для анализа интересующего проекта.

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

Securing Kubernetes using Policy-as-Code

Всем привет!

В приложении можно скачать электронную книгу (~ 36 страниц), посвященную Policy-as-Code от Nirmata (дада, те самые разработчики Kyverno).

После вводной части, посвященной тому, что такое Policy-as-Code и основам безопасности Kubernetes, начинается самое интересное!

Авторы описывают:
🍭 Kyverno: основы, написание политик
🍭 Защита образов и реестров
🍭 Использование Kyverno в CI-конвейере
🍭 Использованием Kyverno для нужд compliance и не только

Получилось неплохое руководство для знакомства с Kyverno. Однако, рекомендуем держать «под рукой» документацию, чтобы изучение было максимально полезным и эффективным.

Автоматическое устранение ИБ-дефектов в коде

Всем привет!

Сегодня предлагаем вам легкое пятничное чтиво, в котором Автор рассуждает о том, насколько можно/нужно/целесообразно полагаться на различные технологии, предоставляющие функционал по автоматическому устранению ИБ-дефектов в исходном коде.

В качестве примера он берет то, «что показывают все производители на всех демонстрациях» (ведь это круто работает!) – работа с SQL-инъекциями.

Дальше он делает аналогичное для:
🍭 Cross-Site Scripting
🍭 Weak Cryptography
🍭 Hardcoded Secrets

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

А что вы думаете по этому поводу? Надо/Не надо/Надо, но аккуратно/Иное – пишите свое мнение в комментариях ☺️

Работа с контейнерами 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: реализация жизненного цикла контейнеров

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

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