VulnReach: композиционный анализ с учётом достижимости

Всем привет!

VulnReach – open-source проект, который комбинирует практики композиционного анализа, taint-анализа и анализ данных во время эксплуатации ПО.

На основе этих данных формируется RBoM – Runtime Bill Of Materials.

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

Для подтверждения своего «мнения», VulnReach предоставляет информацию о пути выполнения программы, который привёл к уязвимому методу.

На текущий момент поддерживается Python. Для Java, JavaScript реализован анализ call graphs, но функциональность всё ещё является экспериментальной.

В дальнейшем планируется добавление Golang, C# и PHP.

Подробнее о проекте можно прочесть в GitHub-репозитории или на официальном сайте.

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

Насколько хорошо LLM генерируют рекомендации по устранению ИБ-дефектов?

Всем привет!

Практика создания исправлений для ИБ-дефектов с использованием LLM становится всё более и более распространённой.

Но можно ли им полностью доверять?

Изменяют ли предлагаемые ими обновления поведение приложения? Могут ли они, исправляя одни ИБ-дефекты, добавлять другие?

Ответам на эти вопросы посвящена статья от Off-by-1 Labs (ИБ-команды 1Password).

Получилась следующая статистика для 6480 обновлений, подготовленных современными моделями:
🍭 Полностью устраняли ИБ-дефекты и сохраняли логику работы приложения: 26%
🍭 Полностью устраняли ИБ-дефект, но меняли логику работы приложения: 20,1%. Пример изменения логики: изменение allow list на deny list
🍭 Не устраняли ИБ-дефекты полностью и/или добавляли новые: 53,9%

Для формирования выборки использовались 6 «свежих» CVE, большинство из которых представляло собой RCE.

Каждая модель сгенерировала по 540 обновлений для каждой CVE: разные конфигурации, разные prompts.

После этого команда оценила результаты по «пятибальной» шкале: S1 – всё отлично, S5 – ИБ-дефект не устранён, появился новый.

Общий итог описан выше. Больше подробностей (статистики, описаний) можно найти в статье.

Кстати, в завершении команда приводит набор рекомендаций о том, как можно повысить качество генерируемых исправлений для ИБ-дефектов: всё так, human-in-the-loop в качестве «финального решения» 😅

P.S. Инструментарий, наборы данных и детальное описание статьи выложены для всеобщего рассмотрения. Найти их можно тут, тут и тут соответственно.

OWASP Agentic Skills: Top 10

Всем привет!

В приложении можно найти материал от OWASP (~ 66 страниц), посвящённый вопросам обеспечения ИБ при работе с агентами.

«По классике» представлены 10 наиболее значимых угроз:
🍭 Malicious Skills
🍭 Supply Chain Compromise
🍭 Over-Privileged Skills
🍭 Insecure Metadata
🍭 Untrusted External Instructions и не только

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

Приятного изучения!

Исследования рынков DevSecOps и MLSecOps

Привет, друзья! Предлагаем вашему вниманию целых три (!) исследования, которые мы запустили:
🍗Исследование рынка безопасной разработки и DevSecOps
🍗Исследование рынка средств контейнеризации
🍗Исследование рынка безопасности ИИ-систем (MLSecOps)
Они направлены на выявление реального положения дел в DevSecOps и MLSecOps, как наиболее хайповых и быстрорастущих направлениях в российском ИТ.

Предлагаем вам пройти все эти опросы и, конечно же, отвечать нужно честно - так статистика получится релевантной.

Среди всех участников каждого опроса 18 сентября в 14:00 проведём розыгрыш уникального мерча, где определим 3х случайных победителей!

В поле «Уникальный идентификатор» нужно указать ник в Telegram, электронную почту или номер телефона. Эти данные понадобятся только для связи с победителями, или если потребуется уточнить ответы.

Kubesplaining: анализ безопасности Kubernetes

Всем привет!

Зачастую информации о некорректной конфигурации может быть недостаточно. Хочется понять, «к каким последствиям это может привести? Можно ли этим воспользоваться?».

Именно на эти вопросы может ответить Kubesplaining.

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

Это достигается за счёт анализа:
🍭 Настроек RBAC
🍭 Конфигурации pod, Admission Controller’ов
🍭 Секретов
🍭 Используемых Service Accounts
🍭 Сетевого взаимодействия и не только

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

Подробности – установка, настройка, работа с исключением – всё это есть в GitHub-репозитории проекта.

Snyk: VulnBench

Всем привет!

Недавно мы писали про исследование команды Snyk, посвященное тому, насколько хорошо LLM ищут уязвимости в исходном коде и насколько идемпотентные результаты можно получить.

Чтобы было проще посмотреть и проанализировать результаты, Snyk подготовил VulnBench.

Фактически – та же сама информация, представленная в виде интерактивного сайта, в котором можно углубиться в исследование.

Доступны такие разделы как:
🍭 Summary
🍭 Repeatability
🍭 Coverage
🍭 Efficiency
🍭 Findings

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

В том числе можно посмотреть на то, как именно LLM выносили вердикт и какое обоснование они формировали.

Если вас заинтересовала статья, то VulnBench вам точно понравится!

Agentic Access Model

Всем привет!

Вопрос управления доступом – задача крайне непростая. Особенно непростой она становится при работе с агентами.

Для того, чтобы комплексно подойти к вопросу, ребята из Cloudflare предложили своё видение – Agentic Access Model (AAM).

В её основе лежат 5 принципов:
🍭 Учетные данные краткосрочны и ограничены
🍭 Политики применяются именно там, где осуществляется действие или сетевая активность
🍭 Подтверждение действия со стороны человека
🍭 Шаблоны выполняемых задач не должны быть общими
🍭 Осуществляется контроль полномочий

Для того, чтобы реализовать эти принципы, Авторы предлагают концепт архитектуры, который состоит из: Identity Broker, Access Engine, Mediation Layer и Trust Ratchet.

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

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

Подпись образов контейнеров

Всем привет!

Задача контроля целостности становится актуальнее год от года. В том числе при работе с образами контейнеров.

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

Материал содержит разделы:
🍭 Что такое подпись образов и как она работает
🍭 Что такое аттестации, какие бывают и для чего используются
🍭 Подпись и аттестация образа с использованием Cosign
🍭 Проверка полученных результатов с использованием Kyverno и не только

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

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

Если вы искали с чего начать изучение вопроса подписи образов, то эта статья то, что нужно!

Управление секретами с Kloak

Всем привет!

Самым распространенным способом управления секретами является использованием Secret Management решений. Ярким представителем которых является HashiCorp Vault.

Концепт такой что все секреты помещаются в единое надежное хранилище и выдаются на основании логики работы Vault’a.

А что если хочется чего-то иного? Например, подстановки самого значения секрета в момент установки соединения за счёт использования eBPF?

Как раз эту задачу и реализует Kloak.

Работает он примерно так:
🍭 Создаётся секрет в Kubernetes
Kloak автоматически создаёт shadow secret, в котором указывается placeholder
🍭 Настраивается взаимосвязь pod с Kloak через аннотации
🍭 Webhook мутирует pod заменяя значение оригинального секрета на shadow secret, созданный Kloak
🍭 В момент запуска pod и установки соединения указывается настоящее значение секрета, полученное из связки shadow secret – оригинальный секрет

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

Однако сам секрет всё равно «материализован» в кластере Kubernetes.

Подробнее о Kloak и его возможностях можно узнать в GitHub-репозитории или в официальной документации.

Warden: управление доступом AI-агентов

Всем привет!

Использование агентов крайне удобно. Особенно когда надо получить быстрый результат для понятной рутинной задачи.

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

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

Это реализуется следующим образом:
🍭 В конфигурации Warden указываются URL, к которым происходят обращения
🍭 Настраиваются данные для аутентификации
🍭 Для каждой конфигурации определяются роли и их возможности
🍭 Создаётся набор skills, в которых описаны возможности ролей и их базовые действия
🍭 Далее все взаимодействие осуществляется через Warden. Например, «use the warden mcp server to list the roles I can assume»

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

На текущий момент в качестве «целевых систем» Warden поддерживает MCP-серверы, LLM, VCS (GitHub, GitLab и т.д.), Observability (Grafana, Prometheus и т.д.) и не только.

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

Защита CI/CD: опыт Cilium

Всем привет!

Защита цепочки поставки и окружения сборки/доставки максимально актуальна в настоящее время.

Для команды Cilium это крайне важно, т.к. их продуктами пользуются множество компаний по всему миру.

Поэтому они достаточно серьёзно подошли к вопросу. И, заодно, поделились своим опытом со всеми желающими.

В статье затрагиваются темы:
🍭 Кто может запускать сборки, где они осуществляются
🍭 Использование CODEOWNERS для контроля изменений
🍭 Работа с зависимостями (pinning, обновления и т.д.)
🍭 Статический анализ
🍭 Работа с учётными данными и не только

Если нет времени читать всю статью, то вначале есть очень ёмкий tl;dr. Он описывает (в общем) подходы и практики, которые применяет Cilium.

Многое «завязано» на возможности GitHub Actions, однако это можно повторить и в других CI-решениях, если сам подход вам понравился.

AI агенты для SRE-операций

Всем привет!

Эксплуатация чего бы то ни было задача непростая, особенно когда возникают инциденты и их приходится решать. Особенно ночью. Или в выходные.

При этом процесс (зачастую) носит достаточно системный характер: посмотреть журналы событий, проанализировать метрики, уточнить что было установлено, какие были изменения и т.д.

И проблема далеко не всегда в сложности задачи или отсутствии данных для анализа. Скорее наоборот – данных слишком много и тратится много времени на поиск ответов.

Это приводит к мысли об автоматизации. Хотя бы в части понимания причины и возможных действий по её устранению.

Именно этому и посвящена статья.

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

Для этого предлагается 5-и уровневая архитектура:
🍭 Layer 1. Данные. Журналы, метрики, события и т.д.
🍭 Layer 2. Инструменты. Системы мониторинга, логирования, непрерывной сборки, оркестрации контейнеров и т.д.
🍭 Layer 3. «Специалисты». Агенты для работы с инструментами
🍭 Layer 4. Оркестрация. Управление работой агентов
🍭 Layer 5. Люди. Принятие решений, аналитика, отчётность

С использованием этой архитектуры Автор реализовал 8 шагов, который автоматизируют процесс работы с инцидентами.

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

Qwen 2.5 7B: «тонкая» настройка для ответов на ИБ-вопросы

Всем привет!

Автор статьи работает над собственным решением – Valqore. Его задача состоит в сканировании Kubernetes, Terraform и облачных ресурсов для поиска ошибок различного рода: от ИБ до несоответствия требованиям.

В качестве основы используется «движок» с детерминированным набором правил: он не галлюцинирует и даёт идемпотентный результат.

Для удобства пользователя Автор захотел добавить ИИ, который смог бы объяснить просто и понятно: «Что не так и как это исправить?».

И тут возникла проблема: ответы AI могли быть корректными, но общими. Она хорошо «подсказывала» в вопросах, связанных с облаками. Однако, ответы резко становились хуже, если вопросы были именно про Valqore.

Решением стало обучение Qwen 2.5 7B:
🍭 Создание набора данных о правилах (что проверяет, в чём проблема, как исправить и т.д.)
🍭 Создание набора данных о «доменах» (Kubernetes, Terraform, CIS Benchmarks и т.д.)
🍭 Тренировка

В результате Автору получилось добиться желаемого результата. Примеры «до» и «после» можно найти в статье.

Кроме того, там перечислены его «ошибки» и «гипотезы, которые не сработали».

А в завершение статьи представлена общая статистика обучения: от количества тестовых данных до времени обучения.