🧠 AI, AI, AI, AI ... или документ по MLSec

Вот и пришло время опубликовать документ про MLSec, а то обещал. Этот документ представляет собой комплексное руководство по внедрению практик безопасности (ML Sec) в системах машинного обучения. Он охватывает все этапы жизненного цикла ML-систем - от проектирования и сбора данных до развертывания, мониторинга и поддержки в проде.

Ссылка на GitHub - ТЫК

Что внутри

🔵 Обзор
🔵 Архитектура ML Sec и немного Ops
🔵 Этапы внедрения
🔵 Методы тестирования моделей
🔵 Инструменты
🔵 Управление секретами, Threat Modeling, безопасность LLM-агентов

Что буду делать дальше

🟢 Завершить разделы по CI/CD и ML-платформам
🟢 Добавить кейсы безопасности LLM-агентов и атак
🟢 Перевести ключевые разделы на английский, сделать мультиязычную версию

#mlsec

🧠 Как я строил свой безопасный MCP с головной болью, страданием и желанием всё бросить и уйти на OnlyFans

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

Они выполняют команды, ходят по API, читают внутренние данные и всё это без слоёв изоляции, без валидации и без УВАЖЕНИЯ аудита.

Решил это попытаться исправить - собрать свой безопасный MCP, который регулирует, как модель взаимодействует с инструментами и данными.

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

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

🧩 LLM != API Gateway

Первая головная боль - большинство систем воспринимают LLM как просто клиент, которому можно выдавать токен и hope for the best.

❌ Ошибка ❌

LLM - это не клиент, это динамическая среда исполнения, и ей нужен control plane, который будет отвечать нашим требованиям:

🔵 посредничает между моделью и внешними ресурсами
🔵 валидирует вызовы (RBAC, ABAC, PoLP)
🔵 и протоколирует всё, что модель делает
🔵 ну и не выебывается

В итоге, я сделал отдельный шлюз - MCP-сервер, через который проходят все действия агентов.

Он подписывает запросы, вставляет контекст авторизации и валидирует payload до передачи инструменту.

😤 Проблема с безопасностью

Когда тестировал прототип, стало ясно, что LLM умеет обходить собственные фильтры.

Кто бы мог подумать 👀

В одном случае агент "убедил" MCP-шлюз, что ему нужен доступ к системному токену, просто потому что в prompt был "!admin".

Решение:

🟢 фильтрация входных данных до LLM
🟢 валидация действий после вывода (double-side checking)
🟢 строгая типизация всех ответов (JSON schema)

Теперь любое действие проходит по цепочке:

➡️ intent - validation - approval - execution - audit - слитые данные


💎 Изоляция инструментов

Второй сюрприз - сами тулзы.

Часто они работают в общей среде с агентом, а это минус со стороны иб.

Я вынес каждый инструмент в отдельный контейнер с seccomp и AppArmor, подписал манифесты через Sigstore (спасибо, что в какой-то момент пришлось с ним плотно поработать 😵‍💫) и ввёл валидацию версий.

Если кто-то решит заменить бинарь или добавить вредоносный инструмент - MCP сразу откажет по подписи.


😳 Аудит и наблюдаемость

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

LLM без логов - как SOC без SIEM

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

⚙️ Что в итоге получилось

🔵 Полная трассировка действий агента
🔵 RBAC и подписи для каждого инструмента
🔵 Валидация входных и выходных данных
🔵 Контейнерная изоляция с политиками безопасности
🔵 Частичная поддержка human-in-the-loop для критичных операций

Теперь любой LLM работает в управляемом и наблюдаемом контуре, а не как хаотичный ассистент с SSH-доступом.

🍄 Что рекомендую, если решите строить свой MCP

1️⃣ Не давайте LLM прямой доступ к API
2️⃣ Изолируйте инструменты
3️⃣ Добавьте аудит
4️⃣ Введите human-approval для важных моментов
5️⃣ Стройте доступы как код

Пусть OPA или Kyverno решают, LLM - только инициирует

👀 Выводы

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

Документ с деталями - ТЫК
Если хотите внести вклад или протестировать подход - присоединяйтесь к коммюнити.

Если всё надоело - канал сырника 👀

🔗 Fulcio, Cosign, Rekor - три кита против невидимых подмен

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

Современный CI/CD - это уже не сборка, а лабиринт доверия. Доверия к коллегам, коллегам из других отделов, разработчикам, к себе (тут вообще жуть). Git, runners, registry, helm-чарты, контейнеры, облачные кэши - каждый узел может быть точкой компрометации.

А теперь вопрос: "Откуда уверенность, что ваш контейнер в проде это тот же самый, что вы собрали на пайплайне?"

Если ответ - "мы верим CI", то, возможно, пора начать проверять, а не верить.


🧩 Что делает Sigstore

Sigstore - это открытая экосистема, которая превращает процесс сборки в криптографически доказуемую цепочку доверия.

Она подтверждает кем, где и из чего был собран артефакт: контейнер, бинарь, SBOM или даже модель ML.


🥳 Как работает механизм доверия

1️⃣ Сборка

Runner получает краткоживущий сертификат через OIDC-провайдера (например, Keycloak или Dex).

Cosign подписывает артефакт, прикладывая:
🔘 SHA256-хэш
🔘 issuer и subject (OIDC claims)
🔘 время подписи и provenance (commit, ref, build job ID)

2️⃣ Публикация

Подпись и метаданные отправляются в журнал Rekor, который обеспечивает неизменяемость данных. Даже администратор не может "стереть" запись - хэш уже зафиксирован в дереве.

3️⃣ Верификация

Policy Controller при деплое проверяет подпись:
🔘 совпадает ли issuer с разрешённым
🔘 существует ли запись в Rekor
🔘 соответствует ли subject утверждённому pipeline

Если хоть одно нет - деплой останавливается.


🛠 Пример self-hosted реализации

Для компаний, где внешний интернет запрещён, Sigstore можно развернуть внутри контура.

Пример инфраструктуры:

# Развёртывание self-hosted Sigstore
git clone https://github.com/sigstore/helm-charts
helm install fulcio ./helm-charts/charts/fulcio \
  --set config.oidcIssuer=https://keycloak.company.local/auth/realms/ci \
  --set config.ca.type=self-signed

helm install rekor ./helm-charts/charts/rekor
helm install cosign-policy ./helm-charts/charts/policy-controller

Подпись и проверка выполняются так:

# Подписываем артефакт локально
COSIGN_EXPERIMENTAL=1 cosign sign \
  --fulcio-url https://fulcio.company.local \
  --rekor-url https://rekor.company.local \
  registry.company.local/backend@sha256:123...

# Проверяем подпись перед деплоем
cosign verify \
  --rekor-url https://rekor.company.local \
  registry.company.local/backend@sha256:123...

Результат содержит issuer, subject и время подписи - всё, что нужно для внутреннего аудита.


😑 Почему это важно для AppSec

🔵 Целостность артефакта подтверждается криптографически
🔵 Происхождение (кто собрал, когда и из чего) становится проверяемым фактом
🔵 Журнал Rekor обеспечивает доказательную базу для SOC и аудиторов
🔵 Kubernetes-policy превращает верификацию в обязательный шаг деплоя

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


❌ Практические нюансы, с которыми точно столкнетесь

🔘 OIDC-провайдер должен быть отдельным для Dev/Staging/Prod
🔘 Необходимо подписывать не только контейнер, но и SBOM, provenance и Helm-чарты
🔘 Проверка в policy-controller должна быть enforce, а не “audit”
🔘 Отдельный Rekor-журнал для каждой среды снижает риск сквозной подмены


👀 Итог

Sigstore и Cosign это не про подписи ради галочки. Это инструмент, который делает supply chain доказуемым, воспроизводимым и проверяемым.

В self-hosted варианте он превращается в вашу внутреннюю PKI-инфраструктуру нового поколения - лёгкую, автоматическую и привязанную к идентичности CI.

Если вы всё ещё деплоите контейнеры "на доверии", то это не DevSecOps - это просто вера в чудеса.

✈️ #offense #mobile #события

➡Ваш бот принимает оплату звёздами? Этот пост – очередное напоминание вам и всем, почему нужно читать документацию и почему нужно вводить дополнительные проверки; Особенно когда дело касается денег! 💸

ℹ️ Ремарка о том, как работают платежи в Telegram ⬇️

🔗 core.telegram.org/bots/payments
🔗 core.telegram.org/bots/payments-stars


0️⃣ Пользователь запускает процесс оплаты
1️⃣ Telegram на клиентской стороне проверяет баланс пользователя:
▪️не хватает – говорит пополнить
▪️достаточно* – шлёт боту статус pre_checkout_query
2️⃣ Бот обязан ответить на pre_checkout_query в течение 10 секунд, если он готов предоставить товар / услугу, иначе – отмена
3️⃣ Производится оплата
4️⃣ Telegram шлёт боту чек со статусом successful_payment


*Что такое достаточно? Это либо "хватает звёзд", либо "платит картой" (но на этом этапе неизвестно, есть ли деньги на карте)

Есть такой неофициальный Telegram клиент – exteraGram – и он предоставляет пользователям возможность дополнять свою функциональность кастомными плагинами, написанными на Python;

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


💻 Небольшая выдержка из исходного кода одного из таких плагинов:

...
from org.telegram.tgnet.tl import TL_stars
...
StarsController = find_class("org.telegram.ui.Stars.StarsController").getClass()
...
class Plugin(BasePlugin):
    DEFAULT_BALANCE = 999999
    SETTINGS_INFINITE = "infinite_mode"
    ...
    def _handle_payment(self, response, error):
        ...
        # Create fake success response
        TL_payments_paymentResult = find_class("org.telegram.tgnet.TLRPC$TL_payments_paymentResult")
        TL_updates = find_class("org.telegram.tgnet.TLRPC$TL_updates")
        ...
        return HookResult(strategy=HookStrategy.MODIFY_FINAL, response=fake_result)
   ...
...
class _GetBalanceHook(MethodReplacement):
    ...
    def replace_hooked_method(self, param):
        ...
        # Return fake balance
        return self._create_stars_amount(self.plugin.balance)

    def _create_stars_amount(amount):
        # Create StarsAmount object
        try:
            return TL_stars.StarsAmount.ofStars(int(amount))
   ...
...

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


➡️Но, как это часто бывает, оказалось, что некоторые боты (даже с десятками тысяч пользователей) не ждут статус successful_payment, а отдают товар / услугу уже на этапе pre_checkout_query, несмотря на официальную документацию. Ну а просто действительно, чего мы ждём, если оплата только в звёздах, да и звёзды уже лежат на столе?

Те, кто подсуетились – зачистили магазины и накупили подписок, набрали себе аккаунтов, авторегов и всего подряд на миллионы (!) звёзд, а учитывая, что многие услуги подразумевают также денежные затраты со стороны продавца (например, те же API вызовы к LLM) – на много чужих денег; Благо разработчики ботов тоже подсуетились и многих перебанили.


➡️В конечном итоге эти плагины стали публиковать, чтобы в стресс-формате обратить внимание разработчиков на дыры в их творениях, если кто не докрутил проверки ⚡️


   @HaHacking  🐇

💎 LLM против уязвимостей, я против шизы

Лирическое отступление:

С праздником всех причастных!

ПРОПАГАНДА LLM 🍌

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

Но как только появляется LLM, эта парадигма рушится.

Модели больше не ищут паттерн, они строят причинно-следственные связи - от источника данных до точки использования. Они понимают, где контекст реально опасен, и могут подтвердить это исполняемым доказательством.

SAST размечает текст, LLM проверяет гипотезу. Разные задачи, разные единицы измерения, кто бы мог подумать (ну вы поняли коламбур - "LLM - подумать"... не смешно? Вот и мне чет не смешно 😵‍💫)

Понятно, что можно просто вогнать репозиторий в агент и попросить его найти баги, он найдет... но не все 👀


🥳 Что реально делает LLM - пишет рецепт мяса с маслом

1️⃣ Контекст уровня репозитория, не файла.

LLM не ограничивается функцией - он восстанавливает цепочку input -> обёртки -> санитайзеры -> sink -> 🗿

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

2️⃣ Нейро-символический подход.

На практике работает гибридно:
🔵 LLM формирует предположения о потоках данных
🔵 статанализ подтверждает путь
🔵 автотест или PoC доказывает эксплуатируемость

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

3️⃣ Агентный анализ.

Модель с ReAct-петлёй делает то, что SAST не умеет: строит гипотезу и проверяет её тестом (взял отсюда - ТЫК).

Если тест падает до фикса и проходит после - это не FP, это факт. Без такой верификации всё остальное - просто красивая эвристика.


❓ Почему метрики SAST больше не работают

🔵 У SAST - “сработало правило”. У LLM - "построена и подтверждена гипотеза". Это не предупреждение, а артефакт с доказательством - тест, PoC или патч - ТЫК

🔵 SAST живёт на уровне функции, LLM работает на уровне репозитория и цепочек данных. Метрики “на файле” теряют смысл, если дефект живёт на границе микросервиса

🔵 Золотые наборы устаревают. LLM сталкивается с живыми багами и часто находит те, что отсутствуют в датасете

🔵 В безопасности важнее минимизировать FN, чем "косметически улучшать precision", как дизайнерский ремонт в халупе с тараканами. FP можно фильтровать, а вот пропущенные RCE - нет

🔵 Рост вайб-кодеров пораждает говно код, который в парадигме хуже, чем у мидла


🔍 Exploit-Backed Evaluation (EBE)

Вместо "сработало правило"

➡️

"доказано исполнением"

EBE оценивает не совпадение, а факт, что дефект можно подтвердить и безопасно устранить.

Ключевые метрики:
- EVP (Exploit-Validated Precision) - доля находок с воспроизводимым тестом или PoC
- AVR (Attack-surface Validated Recall) - доля найденных и подтверждённых уязвимостей из тестируемого набора
- PVR (Patch Verification Rate) - тесты падают до фикса, проходят после
- EBC (Evidence Bundle Completeness) - полнота доказательной цепочки
- TCI (Triage Cost Index) - сколько шагов нужно, чтобы воспроизвести баг


❕ Ограничения

🟣 EBE требует инфраструктуры
🟣 Ценник 💲
🟣 Не всё можно автоматизировать (особенно сложные инпуты и API)
🟣 Но PoC-подтверждение сокращает стоимость триажа на порядок - ложных алертов почти не остаётся


📕 Итог

LLM не заменяет SAST - он поднимает уровень анализа

Попробовать - ТЫК

Exploit-Backed Evaluation превращает уязвимость из абстрактного предупреждения в проверенный факт. И если у вас всё ещё измеряют качество “количеством алертов”, - значит, вы всё ещё живёте в мире статических правил, а не исполняемых доказательств.