Безопасная разработка: Rust

Всем привет!

Мы неоднократно писали про материалы от Trail of Bits и их Security Handbook.

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

Он содержит разделы:
🍭 Security Overview. Общая информация о нюансах безопасности, характерных для Rust
🍭 Dynamic Analysis. Набор рекомендаций, как осуществлять динамический анализ, какие утилиты использовать
🍭 Static Analysis. Аналогично динамическому, но только для анализа исходных текстов
🍭 Supply Chain Security. Описание работы с пакетами и возможностей
cargo, которые могут пригодиться

Это далеко не всё, что есть в разделе посвящённом Rust. Как обычно, никакой воды, всё по делу, много примеров и рекомендаций.

Рекомендуем к ознакомлению!

AI-проекты для анализа ПО

Всем привет!

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

Всего рассматривается 3 «типа»:
🍭 Skill Boosting. Добавление skills к LLM, чтобы они «рассуждали», как исследователь безопасности ПО при его анализе
🍭 SAST с LLM. Использование результатов работы SAST «на вход» LLM для дальнейшей работы
🍭 Генерация exploit’ов. Использование AI-проектов в качестве «помощника» при генерации «доказательств актуальности уязвимости» за счёт генерации exploit’ов

Для каждого «типа» Автор приводит несколько open-source инструментов, которыми можно воспользоваться, их краткое описание.

Чтобы было проще подобрать инструмент «под себя», их разделили на «логические» блоки: для исследователей уязвимостей; для тех, кто часто работает с C/C++; для оптимизации процесса разметки и т.д.

Возможно, вы уже что-то из этого используете или планируете. Делитесь своим опытом в комментариях! ☺️

LLM Inference в Kubernetes

Всем привет!

Статья описывает опыт Автора, в которой он разворачивает LLM-модель локально, в своём кластере Kubernetes.

Для этого он использует следующие технологии: vLLM, KEDA, GAIE, llm-d, Karpenter и не только.

После небольшого взгляда на концептуальную архитектуру предлагаемого решения начинается самое интересное – реализация.

Автор описывает разделы:
🍭 Использование Karpenter для управления GPU-узлами
🍭 О чём важно помнить при работе с GPU в Kubernetes
🍭 Настройка Ingress и TLS с Istio и Cert Manager
🍭 Установка и настройка модели (qwen-3.6-27B-fp8)
🍭 Конфигурация автоматического масштабирования с использованием Keda и не только
🍭 Настройка мониторинга, контроль использования GPU

Весь путь, пройденный Автором, описан максимально детально: все команды, конфигурационные файлы, ссылки на инструментарий, важные уточнения (опыт, полученный на ошибках) – всё это есть в статье.

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

VulnHunter: анализ исходного кода с AI-агентами

Всем привет!

Недавно команда Capital One передала свой проект – VulnHunter – в open-source.

Согласно описанию, в отличие от «традиционных» SAST, полагающихся на определённые шаблоны/правила, VulnHunter «размышляет как злоумышленник», что возможно за счет использования AI.

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

Для этого используется 3 основных skill:
🍭 Hunt. Поиск «опасных конструкций» в исходном коде. После их выявления запускается многоступенчатый процесс, в результате которого пользователь получает только то, что на самом деле значимо
🍭 Fix. Создание эксплойта, тестов, подготовка исправления, повторный запуск тестов и, если всё хорошо, оформление PR
🍭 Verify. Read-only агент, задача которого – убедиться в том, что устранение уязвимости было осуществлено

Можно использовать разные модели, но лучше всего VulnHunter работает с Claude Opus.

Выглядит достаточно интересно, но как работает «по факту» - вопрос.

Возможно, что кто-то уже сталкивался с решением, как оно вам?

Создание OSS Kubernetes Console с MCP

Всем привет!

Решений, которые анализируют кластеры Kubernetes и запускаемые в них контейнеры на предмет ИБ-дефектов, очень много.

Многие из них дают очень хорошие результаты. Нюанс в наличие контекста.

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

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

С этими мыслями Автор статьи предлагает своё видение ответа на этот вопрос – OSS Kubernetes Console с MCP.

Он собирает следующий набор инструментов:
🍭 Falco для анализа запущенных контейнеров
🍭 Trivy для поиска уязвимостей в образах контейнеров
🍭 Kyverno в качестве Policy Engine
🍭 Kubescape для анализа конфигурации кластера

Результаты от всех решений «собираются вместе» и анализируются, обладая общим контекстом.

Важно(!): для анализа используется Claude Code (на случай, если вы захотите попробовать предлагаемый концепт)

Это позволяет превратить «В контейнере запущен shell» в нечто вроде «В Kubernetes-ресурсе, созданном из образа с известными уязвимостями, запущен shell. Конфигурация ресурса не соответствует принятым в компании политикам».

Подробности предлагаемого Автором подхода можно найти в статье или в GitHub-репозитории.

Кстати, в GitHub-репозитории можно найти несколько skills, созданных Автором: от triage до remediation.

Nomos: контроль действий AI-агентов

Всем привет!

Использование AI-агентов постепенно становится общей практикой. При этом недоверие к ним всё равно остаётся – «а что если он сделает что-то не то?».

Чтобы несколько повысить уровень безопасности при работе с ними можно посмотреть на open-source проект Nomos.

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

Это нужно для того, чтобы:
🍭 Контролировать чтение чувствительной информации (секретов)
🍭 Влиять на потенциально опасные команды (rm -rf, kubectl delete, git push и т.д.)
🍭 Сканировать MCP-ответы на наличие потенциальных инъекций
🍭 Собирать свидетельства аудита (audit traces) и не только

«Из коробки» Nomos предоставляет несколько политик контроля. Их можно изменять и расширять по усмотрению пользователя.

Подробнее об архитектуре, запуске, настройке и результатах работы Nomos можно узнать в GitHub-репозитории проекта.

OpenAnt: поиск Иб-дефектов в ПО с использованием LLM

Всем привет!

OpenAnt – ещё один представитель класса решений, которые используют LLM для того, чтобы искать ИБ-дефекты в ПО и сокращать количество «шума».

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

Работает он примерно так:
🍭 Анализирует кодовую базу
🍭 Строит графы вызовов (call graphs)
🍭 Пытается выявить участки кода, доступные «извне»
🍭 Анализирует source/sink с использованием LLM
🍭 Пытается проверить сработки путём их эксплуатации

«Из коробки» реализована поддержка Anthropic, OpenAI и Google. В планах у ребят реализация поддержки большего количества моделей.

На текущий момент поддерживаются языки: Go, Python, JS/TS (beta), C/C++ (beta), PHP (beta), Ruby (beta), Zig (beta) и Swift (beta).

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

Важно (!): некоторая функциональность OpenAnt всё ещё находится в стадии «beta», т.к. проект активно развивается

Luxury Yacht: GUI для управления кластерами Kubernetes

Всем привет!

«Я попробовал разные GUI для Kubernetes, но не смог найти то, что нужно именно мне, поэтому сделал своё» - комментарий Автора о причине создания Luxury Yacht.

Как и большинство подобных решений она позволяет:
🍭 Получать сводную информацию по кластеру (утилизация ресурсов, количество узлов, последние events, данные о ресурсах и т.д.)
🍭 Управление несколькими кластерами их единого UI с возможностью «переключения»
🍭 Получение информации и поиск интересующих ресурсов
Возможность делать diff конфигураций
🍭 Делать port-forward,
exec
🍭 Редактировать yaml- файлы не покидая UI и не только

Так в чём же разница?

Автор выделяет несколько возможностей: максимально удобный просмотр логов, построение «карты взаимодействия/связности» ресурсов, возможность расположения объектов «под себя», управление узлами (cordon, drain, delete) и не только.

Выглядит Luxury Yacht достаточно приятно и ненагруженно. Посмотреть можно вот тут и в GitHub-репозитории проекта.

Довелось ли вам использовать этот GUI и что вы о нём думаете?

Deployah: «быстрый» deploy в Kubernetes

Всем привет!

Deployah – open-source утилита, которая упрощает процесс разворачивания приложений в кластере Kubernetes.

«Внутри» она содержит всё необходимое: helm, kubectl, kind. За счёт этого требуется всего лишь создать небольшой конфигурационный файл – deployah.yaml, а дальше она сама сделает всё необходимое.

Работает это примерно так:
🍭 Анализ конфигурации. Поиск ошибок и неточностей, чтобы устранить их заранее
🍭 Адаптация конфигурации. Выбор требуемой среды для разворачивания, подстановка необходимых переменных
🍭 Запуск. Создание Helm Values, установка Helm Release в выбранном кластере

Сама спецификация требует заполнения трех обязательных полей - apiVersion, project и components.

Для управления кластерами, в которых будут созданы ресурсы, используется ещё один конфигурационный файл - deployah.platform.yaml.

В нём необходимо указать основные параметры. Например, nodeSelector, securityContext, storageClass и т.д.

Используя эту информацию и данные о конфигурации запускаемого приложения Deployah как раз и создаст необходимые Values для установки Helm Chart.

Подробнее о возможностях утилиты, её настройках и сценариях использования можно прочесть в GitHub-репозитории проекта.

P.S. А если вам интересно "а зачем оно вообще надо", то ответ Автора, раскрывающий мотивацию создания Deployah можно найти тут ☺️

Awesome: LLM4Cybersecurity

Всем привет!

Сегодня хотим рассказать вам про ещё одну Awesome-подборку.

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

Awesome разбит на разделы:
🍭 LLM Assisted Defense
🍭 Vulnerability Detection
🍭 Program/Vulnerability Repair
🍭 FUZZ
🍭 Insecure Code Generation и не только

Для каждого раздела собраны ссылки на релевантные материалы по теме. В среднем получается около 50 ссылок на каждую.

Внутри можно найти материалы в том числе по безопасной разработке: использование LLM для поиска ИБ-дефектов, для устранения или для подтверждения возможности эксплуатации того, что было найдено.

XSS Laboratories

Всем привет!

XSS Laboratories – open-source проект, в котором неожиданно! собраны лабораторные работы, обучающие тому, что такое XSS и какие они бывают.

Всего доступно 9 лабораторных:
🍭 Introduction to XSS Basics
🍭 Stored XSS Attacks
🍭 DOM-based XSS
🍭 Advanced XSS Techniques
🍭 Edit/View Functionality XSS и не только

Итого – 5 Reflected, 3 Stored и 1 DOM XSS.

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

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

Drogonsec: комплексный анализ ПО

Всем привет!

Drogonsec – open-source сканер, который объединяет в себе сразу несколько типов анализа: Secrets, SAST и SCA.

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

Secrets анализирует как текущую директорию, так и историю (при необходимости можно отключить) на наличие чувствительных данных.

Для SAST поддерживается более 20 языков, среди которых: Python, Java, JS, TS, Golang, Kotlin, C/C++ и не только. Суммарно доступно более 150 правил, которые можно добавлять самостоятельно.

SCA по классике – анализ манифестов и определение «подходящих» CVE. При необходимости Drogonsec позволяет выгрузить SBoM-файл.

Для формирования рекомендаций по устранению идентифицированных ИБ-дефектов, помимо того, что описано в правилах, можно использовать LLM.

Доступно «подключение» как к локальной LLM (Ollama, DeepSeek Coder), так и к внешним (Anthropic, OpenAI, Azure и т.д.).

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

Поиск ИБ-дефектов с LLM: идемпотентность

Всем привет!

«Может ли LLM найти один и тот же ИБ-
дефект дважды?» - именно этот вопрос задала себе команда Snyk.

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

Один и тот же исходный код. Один и тот же prompt. Один и тот же harness. Несколько раз.

Что получилось? Ответ можно найти в достаточно объемной статье (~ 29 минут на прочтение).

tl;dr – результаты могли отличаться от запуска к запуску.

А если хочется деталей, то они есть внутри и «разбиты» на разделы:
🍭 Результат №1. Повторяемость LLM варьируется от конфигурации
🍭 Результат №2. LLM-агенты и SAST нашли разные ИБ-дефекты
🍭 Результат №3. Более дорогие LLM не всегда показывали лучшие результаты

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

Проводили ли вы у себя подобные исследования и какие были результаты?

KubeShark: использование LLM в Kubernetes

Всем привет!

KubeShark – skill для работы с Kubernetes. Основная его задача – генерировать и/или исправлять конфигурации в ресурсах.

Основная проблема, которую пытался решить Автор – галлюцинации, которые зачастую случаются при работе LLM с Kubernetes.

Для этого он реализовал следующий подход:
🍭 Изучение контекста. Версия кластера, используемый namespace, окружение, тип ресурса
🍭 Анализ failure modes. Поиск наиболее подходящего из 6 сценариев (небезопасная конфигурация, некорректная работа с ресурсами, проблемы с сетью и т.д.)
🍭 Загрузка сценариев. На основании предыдущего шага выбирается набор подходящих инструкций для диагностики
🍭 Формирование рекомендаций. Предложение по тому, как можно решить выявленные проблемы
🍭 Генерация артефактов. Создание манифестов, Helm Charts, политик и т.д., в которых реализовано предложенное исправление
🍭 Проверка. Dry-run, валидация наработок, проверка консистентности

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

Такой подход, по мнению Автора, сильно сокращает вероятность того, что LLM «добавит что-то от себя».

Примеры задач, которые поможет решить KubeShark: создай `deployment` с N репликами, `requests/limits` и `ingress`; проверь конфигурацию на наличие проблем безопасности; создай роль с минимальными привилегиями, для сервиса X, который должен уметь делать Y и т.д.

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

JavaScript Analysis for Pentesters

Всем привет!

В статье можно найти достаточно объёмное и подробное руководство о том, на что обращать внимание при анализе JavaScript-приложений.

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

Материал разбит на части:
🍭 Static Analysis
🍭 Dynamic Analysis
🍭 (De) obfustation
🍭 Bypass Code Protection и не только

В каждом разделе приводится много теории, примеров и пояснений.

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

Кстати, помимо этой, у Автора можно найти ещё много интересных статей, посвященных информационно безопасности приложений.

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

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-репозитории проекта.