Gitxray: анализ GitHub репозиториев

Всем привет!

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

Он позволяет собрать множество информации о репозитории для последующего анализа.

Например:
🍭 Искать чувствительную информацию в профилях contributors
🍭 Идентифицировать не настоящие (fake) или зараженные (infected) репозитории
🍭 Анализ времени commit’ов для идентификации аномалий
🍭 Предоставлять сведения об артефактах релизов, которые были изменены уже после релиза
🍭 И многое другое

Устанавливается и запускается крайне просто. Результаты работы утилиты предоставляются в виде наглядного html-отчета.

Больше информации об Gitxray можно найти в репозитории или в документации.

Как «безопасный» кластер Kubernetes был взломан за 17 минут

Всем привет!

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

У команды был свой кластер: настроена ролевая модель доступа, для контроля сетевого трафика использовались NetworkPolicy, проводилось регулярное сканирование на уязвимости.

Однако, это не помогло.

Случилось примерно следующее:
🍭 Злоумышленник просканировал публично доступные endpoints (забыли про kubelet read-only port)
🍭 Быстро нашел уязвимый контейнер (почему он таким стал – лучше прочтите сами)
🍭 При помощи него развернул майнер криптовалюты
🍭 Узлы кластера начали «разваливаться»

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

Подход «один раз сделать и забыть» работать гарантированно не будет.
Используемые практики надо проверять, дополнять и адаптировать под существующие реалии.

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

«Внутри» Chainguard Factory

Всем привет!

Команда Chainguard известна тем, что создает и поддерживает образы с минимальным количеством уязвимостей. Их SLA: 7 дней для «Критичных», 14 для «Высоких», «Средних» и «Низких».

И это сложно! Собирать множество образов для разных дистрибутивов с невероятным количеством разных зависимостей…

«Мы делаем это не потому, что это просто, а потому, что думали, будто это будет просто». Если вам интересно узнать о том, как это устроено «внутри», то предлагаем прочесть статью с говорящим названием «This Shit is Hard».

В ней Автор разбирает следующие области:
🍭 Сборочная линия. От GitHub Actions до собственных наработок
🍭 Команда. Да-да, всегда самое важное и ценное
🍭 Роботизация. Автоматизация рутинных задач, чтобы команда хоть иногда отдыхала
🍭 Использование ИИ. Куда без него 😅
🍭Тестирование. «Нельзя просто так взять и собрать»
🍭 Доставка. Как сделать так, чтобы наработки забрали быстро и безопасно

В статье нет деталей, тем не менее читается она на одном дыхании.

Есть такой тезис, что «весь код – ваш код». Команда Chainguard усиливает идею – «относитесь к конвейеру сборки так, будто это промышленное окружение».

Рекомендуем к прочтению!

Predictive Vulnerability Database

Всем привет!

Сегодня хотим поделиться с вами ресурсом от Miggo – Predictive Vulnerability Database. Да, еще один агрегатор информации о «CVE». Но не совсем!

Помимо стандартной информации:
🍭 Оценка уровня критичности (CVSS v3.1)
🍭 EPSS
🍭 Даты публикации, обновления
🍭 Наличия исправления

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

Это может быть полезно как для разметки, так и для анализа достижимости с использованием средств автоматизации.

Из нюансов – информация о методах есть только для уязвимостей, которым менее 60 дней и автоматизировать обращение к базе через API (по крайней мере бесплатно) – не получится.

В остальном – она открыта для использования ☺️

Что такое анализ достижимости?

Всем привет!

Этот термин (хоть он далеко и не новый) появляется все чаще и чаще. Но что он означает? Как обычно, разные специалисты/компании интерпретируют его по-своему.

В статье Автор пытается разобраться в вопросе и формирует свой ответ на то, что же это такое.

Начинается все со сравнения – каким был процесс управления уязвимостями раньше и каким он стал сейчас. Да, когда-то было достаточно просто обновить версию ПО. Однако, сканеры развиваются, начинают лучше понимать ПО и могут анализировать ОС, пакеты, зависимости, ПО и т.д.

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

Например, понимание того:
🍭 Загружена ли библиотека
🍭 Используется ли метод
🍭 Доступно ли ПО извне
🍭 Есть ли какие-то меры по ИБ

может сильно помочь. И да, CVE может и присутствовать, но эксплуатировать ее нельзя. Тогда это false positive?

Поэтому, по мнению Автора, анализ достижимости это не только про комбинирование практик SAST и SCA, но и про понимание контекста – инфраструктуры, средств защиты.

Таким образом получается, что цель не в снижении false positive, а в поиске true positive.

А что вы думаете по этому поводу и реализуете ли вы такой анализ у себя?

Что такое анализ достижимости? Часть 2!

Всем привет!

Продолжение вчерашнего поста. Автор определился с тем, что такое анализ достижимости и пошел дальше.

Теперь его цель разобраться в том, какие виды такого анализа бывают, как они работают и в чем их разница.

Он выделяет 2 основных типа:
🍭 Статический анализ достижимости. Исследование исходного кода, библиотек, их использования и поиск уязвимых функций
🍭 Динамический анализ достижимости. Пакеты ОС, их использование, поиск уязвимых функций, идентификация вредоносного ПО

Далее Автор разбирает каждый из типов более детально и с примерами. Например, в чем разница между Package Level Reachability и Function Level Reachability, если говорить про статический анализ достижимости.

Помимо этого, в статье приводится очень хорошее описание сильных и слабых сторон для каждого из рассматриваемых способов анализа.

Что такое анализ достижимости? Часть 3!

Всем привет!

Завершающая статья из цикла, посвященного анализу достижимости (о первых двух мы писали тут и тут).

В последней части Автор рассказывает о сложностях, которые присущи Runtime Reachability. Одной из таких сложностей является то, что все понимаю ее по-разному.

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

С точки зрения Автора все несколько иначе:
🍭 Зависимость загружена и, возможно, используется. Имеет место быть. Ведь если нет зависимости, то не т и уязвимости. Но сильно не поможет.
🍭 Доступ по сети. Может быть использован для расстановки приоритетов. Если есть N приложений с уязвимостью, эксплуатируемой удаленно и только 2 доступны извне – то лучше обратить внимание на них
🍭 Исполнение уязвимой функции. Самое интересное – именно этот способ может позволить максимально эффективно отсеять лишнее. Ведь если зависимость загружена, это не означает, что используется уязвимый метод

Поэтому, для достижения лучшего результата можно использовать все три способа.

Нюанс в том, что информацию об исполнении уязвимой функции в runtime получить не так просто и крайне мало средств автоматизации.

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

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

Использование нейросетей для выявления секретов, опыт Wiz

Всем привет!

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

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

Нейронные сети показали себя с весьма хорошей стороны в вопросах понимания исходного кода и выявления секретов.

Именно этому и посвящена статья от Wiz, в которой команда описывает свой путь.

«Традиционные» модели (GPT, Claude Sonnet и т.д.) им не подошли по ряду причин:
🍭 Слишком сильное потребление ресурсов (Wiz анализирует миллионы файлов ежедневно)
🍭 Слишком высокая стоимость (обусловленная, опять-таки, большим количеством анализируемой информации)
🍭 Передача конфиденциальной информации (многие пользователи Wiz не хотели, чтобы их данные попадали в вышеуказанные сети)

Поэтому команда решила отойти от парадигмы «bigger is better» и использовать небольшую модель, которую обучили выполнять ровно одну задачу – искать секреты в исходном коде и конфигурационных файлах.

Все этапы: от формирования набора данных (data set) до тестирования и анализа результатов (ожидание/реальность) представлены в статье.

Да-да, в том числе в статье написано какую именно модель выбрали и какие подходы к обучению использовали.

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

Offensive Container Security: техники, сценарии атак

Всем привет!

По ссылке можно ознакомиться со статьей, в которой собрана информация об угрозах и рисках, присущих средам контейнеризации (как Docker, так и Kubernetes), а также о способах их эксплуатации.

В статье содержится информация о:
🍭 Наиболее «популярные» ошибках в конфигурации Docker (privileged, exposed docker socket, fs mount и т.д.)
🍭 Наиболее «популярных» ошибках в конфигурации Kubernetes (exposed endpoint, token abuse, RBAC misconfigurations и т.д.)
🍭 Техниках побега из контейнера и повышения привилегий
🍭 Способах закрепления и дальнейших действиях в кластере
🍭 Атаках на цепочку поставки, применимых к контейнеризации

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

Chainguard: интеграция со сканерами уязвимостей

Всем привет!

Вторая статья из серии This Shit is Hard (про первую, посвященную Chainguard Factory) мы писали тут.

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

Если упростить, то сканеры работают примерно так:
🍭 Анализ артефакта (ELF-файл, JAR-файл, образ контейнера и т.д.) с целью понять, что в него «положили»
🍭 Соотношение полученной информации (пакеты, версии) с известными источниками данных об уязвимостях
🍭 Обогащение «контекстом». Если сканер понимает откуда был получен пакет, то он может запросить дополнительную информацию от поставщика

Третий пункт – именно то, на что обращает внимание команда Chainguard. Они составляют определенные файлы, в которых содержится дополнительная информация.

Например: да, уязвимость есть; уязвимость устранена, на нее можно не обращать внимание; определенные условия, в которых уязвимость становится актуальной и т.д.

Ребята ежедневно сканируют собираемые образы (они используют Grype) и постоянно работают над сокращением уязвимостей.

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

Сканеров очень много и все они работают по-разному. Поэтому Chainguard выпустили собственные рекомендации о том, как можно с ними интегрироваться, на что обращать внимание и как можно реализовать дополнить результаты работы сканера данными из их feeds. Кроме того, они размещают информацию на OSV.dev.

В итоге получается очень удобная и практичная конструкция. Вместо того, чтобы убеждать всех, что «все работает, но мы ничего не расскажем» Chainguard активно работает с производителями сканеров и сообществом, чтобы каждый мог получить как можно больше данных и оптимизировать процесс управления уязвимостями. А заодно убедиться, что уязвимостей и правда нет ☺️

P.S. Список сканеров, которые поддерживает Chainguard на текущий момент, доступен тут.

malcontent: инструмент для обнаружения supply-chain атак

Всем привет!

Изменения в бинарях важно заметить вовремя, особенно если речь идёт о скрытом или едва заметном поведении программы (subtle behavior). В таких случаях полезен malcontent от Chainguard — инструмент для выявления supply-chain компрометаций через контекстный анализ и сравнение артефактов.

🎯 Malcontent поддерживает три режима работы:
- diff — анализ изменений между двумя версиями: добавленные права или поведение будущих версий
- analyze — глубокий анализ возможностей и capabilities бинаря
- scan — поиск malware в директориях и в процессах
🎯 Использует YARA-правила: огромный набор — более 14,5к open-source правил, включая правила от Avast, Elastic, FireEye, Mandiant, ReversingLabs и других.
🎯 Широкая поддержка: работает с бинарями в форматах ELF, Mach-O, PE и платформами Linux, macOS, Windows, а также с языками (C, Go, Javascript, PHP, Perl, Ruby, Shell, Typescript), архивами (apk, tar, zip) и контейнерными образами. Отлично подходит для CI/CD.
🎯 Позволяет формировать отчёты в JSON, YAML и Markdown.

Важно:
Инструмент «параноидальный», многие находки могут быть ложноположительными — будьте к этому готовы.

Уже ставили что-то подобное в CI/CD? Делитесь опытом!

Headlamp AI Assistant

Всем привет!

Headlamp – интерактивный Web UI для Kubernetes, о нем мы писали тут. Недавно команда добавила возможность использования собственного AI-ассистента.

Ассистент может помочь решить разные задачи:
🍭 Подготовить манифест для ресурса, который можно применить впоследствии без лишних действий
🍭 Дать «сводную информацию» о состоянии приложения
🍭 Помочь в идентификации причин возникающих проблем
🍭 Подготовить рекомендации о том, как устранить существующие ошибки
🍭 Выполнить действие (например, перезапустить deployment) и не только

Устанавливается он в качестве plugin и практически сразу готов к работе.

По ссылке также доступен небольшой ролик, в котором демонстрируется весь процесс: от установки и настройки до демонстрации возможностей.

Falco Vanguard

Всем привет!

Falco – очень известное решение в мире защиты сред контейнерной оркестрации. С его помощью можно анализировать события, происходящее в кластере с целью выявления инцидентов ИБ.

Недавно команда объявила о выпуске нового продукта – Falco Vanguard, который расширяет функционал Falco и упрощает процесс работы с ним.

Если кратко, то Falco Vanguard позволяет:
🍭 Обогатить результаты работы Falco с использованием AI. Помимо использования OpenAI и Gemini есть возможность использования локальной LLM (Ollama), чтобы исключить передачу данных во "внешние системы"
🍭 Получать информацию об уровне защищенности на готовых дашбордах
🍭 Генерировать рекомендации для сработавших правил Falco
🍭 Повысить точность работы Falco по идентификации угроз и не только

В статье приводится описание архитектуры, способов установки и первичной настройки Falco Vanguard.

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

Важно(!): проект находится в стадии активной разработки. Некоторый функционал может не работать или работать не так, как ожидалось. И да, возможны breaking change без уведомлений

Лучшие практики по защите Kubernetes

Всем привет!

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

Например:
🍭 Using Non-Root Containers
🍭 Do not use hostPath Volumes
🍭 Do not share the Host Namespace
🍭 Do not use Insecure Capabilities
🍭 Do not set Custom SELinux Options и другие

Для каждой рекомендации ёмко и кратко поясняется «почему это так», приводятся примеры и рекомендации о том, как и что лучше реализовать.

DeepPass2: выявление секретов с использованием
LLM

Всем привет!

На предыдущей неделе мы писали про опыт Wiz в использовании LLM для поиска секретов с целью повышения качества анализа и сокращения false positive.

На этой неделе хотим поделиться статьей, в которой решается аналогичная задача и рассказывается про DeepPass2 (увы, не open source).

Команде нужен был инструмент, который из «стены текста» сможет найти пароли. Да, «P@SSW0RD» найти легко. А вот «Бабочка»? Это пароль или нет? Зависит от контекста.

«Большие LLM» не использовались. Проблематика схожа с тем, к чему пришли Wiz: это дорого, качество не всегда устраивает (в том числе и из-за галлюцинаций), вопросы с конфиденциальностью.

По этой причине команда решила использовать собственный подход.

Он заключается в том, что:
🍭 Используются небольшие модели
🍭 Добавляются RegEx. Команда взяла их у NoseyParker (о нем мы писали тут)
🍭 В качестве «данных для тренировки» использовались dump’ы с паролями; тексты генерируемые LLM
🍭 Дополнительно команда сделала «skeleton sentences» и подставляла в них разные данные, чтобы обучить модель пониманию контекста. Например: «Your account has been created with username: {user} and password: {pass}»

Что в итоге и какие планы на будущее? Ответы на эти вопросы и не только можно найти в статье.

Получились две идеологически очень похожие статьи (как с точки зрения подхода, так и с точки зрения достигнутых результатов). Быть может, повышение точности обнаружения секретов и сокращение количества false-positive – это то, где нейронные сети уже хорошо себя показывают?

Автоматическое масштабирование с помощью KEDA с использованием пользовательских метрик RED

Всем привет! 👋

Статья рассказывает, как настроить автоскейлинг в Kubernetes с помощью Kubernetes Event-driven Autoscaling (KEDA) и Rate, Errors, Duration (RED) метрик из Prometheus.

Автор начинает с задачи: старые сервисы перегружались в часы пик, но простаивали в остальное время. Отмечается, что традиционные метрики CPU/памяти не всегда отражают реальную нагрузку на приложение, поэтому для масштабирования был выбран подход, ориентированный на пользовательский опыт.

Ключевые шаги:
🎯 Архитектура решения: K8s + KEDA + Prometheus. Рассматривается сравнение KEDA с другими средствами (HPA, Cluster Autoscaler, Knative, самописные решения). KEDA поддерживает множество источников метрик (включая Prometheus и пользовательские), умеет масштабироваться «до нуля» и гибко настраивается через ScaledObject.
🎯 Тестирование нагрузки (Locust, JMeter) для имитации пиковых нагрузок, настройка мониторинга через Grafana.
🎯 Основные проблемы и их решения: оптимизация PromQL-запросов (подбор метрик, окон агрегации, упрощение запросов). Также нужно было сбалансировать быстродействие и устойчивость: регулировать pollingInterval и cooldownPeriod, а при уменьшении нагрузки — устанавливать разные пороги для масштабирования вверх и вниз. Кроме того, при масштабировании стали заметны узкие места внешних систем (например, БД). Для этого внедрили пул соединений, реплики для чтения базы данных и кэширование, чтобы помочь интеграционным компонентам выдерживать увеличенную нагрузку.
🎯 Результаты: улучшение отклика сервисов, оптимизированы расходы на облако, более надёжная архитектура и аналитика.

И самое полезное — в статье есть конкретные примеры манифестов и команд, которые можно повторить у себя! 🚀

GitHub Actions: Hardening

Всем привет!

Еще один материал от Wiz! На этот раз команда делится опытом о том, как можно сделать GitHub Actions более безопасным и на что стоит обращать внимание.

В статье рассматривается:
🍭 Configuring GitHub Actions for Safer GitHub Actions. Управление полномочиями, контроль Actions, управление runners
🍭 Safely Writing GitHub Workflows. Управление полномочиями, «внешними» Actions, контроль использования секретов
🍭 Safely Running GitHub Workflows. Управление runner и корректная настройка инфраструктуры

В результате получилось очень наглядное и понятное руководство о том, как и что можно настроить в GitHub Actions для повышения уровня защищенности.

Изгоняя демонов SAST

Всем привет!

Такое название отчету (который можно найти в приложении) дала Ghost Security. Он посвящен результатам исследования возможности использования LLM для оптимизации времени разметки результатов, генерируемых SAST.

В рамках исследования Команда:
🍭 Просканировала порядка 3000 репозиториев open source проектов
🍭 Проанализировала более 2000 сработок
🍭 Потратила 350 часов (~ 2 месяца) для того, чтобы найти 180 истинных срабатываний

Итог простой и очевидный – нужно «что-то», что поможет как-то оптимизировать процесс. И этим «чем-то», конечно, стала LLM.

В отчете достаточно детально описана методика тестирования (что анализировали, что искали, какие инструменты использовали).

Правда не хватает описания используемых LLM и соответствующих prompt’ов.

Единственное, что указано: чтобы сработка считалась истинной необходимо выполнение 3х условий. Код достижим, возможна эксплуатация через external input, ИБ-контроли отсутствуют.

Был ли у вас опыт использования LLM для разметки результатов SAST и если да, то какой?

Rules Files Backdoor

Всем привет!

Еще один пример атаки на цепочку поставки. На этот раз главным действующим лицом стали AI-агенты, которые используются для генерации кода.

Выглядит это следующим образом:
🍭 Злоумышленник создает собственный Rule File
«Делится» им с сообществом
🍭 Разработчики используют этот Rule File (который кажется весьма безобидным)
🍭 «Что-то» начинает добавляться в генерируемый код (зависит от того, что было в Rule File)

Для того, чтобы создаваемые Rule File выглядели безобидными в них добавляют обычное описание (например, «follow HTML5 best practices»). Однако, рядом, используя разные манипуляции, помещают «дополнительные инструкции», которые могут быть не видны.

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

Подробности (примеры, описание, анализ поверхности атаки, способы противодействия) можно найти в статье от Pillar Security.