💎 Как zero-shot модель помогает мне искать реальные утечки секретов

Всё чаще секреты утекают не из кода, а из внутренних систем типа Confluence, Jira, корпоративных вики и мессенджеров (НЕ МАКСА). Пароли, токены, приватные ключи могут "скрываться" в комментариях, конфигурациях или прошлых версиях страниц. На самом деле, удивительно наблюдать на старые версии страниц, которые не затирают и в которых очень много интересного, но сейчас не об этом. Сегодня пойдет речь не про сам самописный инструмент, т.к. я думаю такое есть уже у всех компаний, а про хайповую тему с ЛЛМ (надеюсь ещё хайповую 👀)

⚙️ Как работает стандартный инструмент

1. Сканирование контента
2. Эвристика/шаблоны/LSP
3. Результат

Но с чем мы сталкиваемся, разбирая выхлоп?

- С проблемами😎

Да, вот и появляется куча FP и структуры, которые нам совершенно не подходят. Вот тут и появляется идея сделать фильтрацию через ИИ. Но упс, а что нам теперь, скармливать все наши данные в нейронку, даже если локальную, то представьте сколько это данных и контекста. Тут нам и приходят на помощь zero-shot модели.

💩 Локальная zero-shot модель

🔵 Используется pipeline("zero-shot-classification") с моделью typeform/mobilebert-uncased-mnli. Я протестировал с 20 различных моделей и остановился на ней.

🤗Ссылка - ТЫК

🔵 Модель решает задачу бинарной классификации: _secret_ vs _non-secret_

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

🔵 Финальное решение
- Кандидат признаётся "секретом", если:
- сработало сильное правило или высокая уверенность эвристики, или/и
- zero-shot модель оценила вероятность ≥ порога.

🥲 Зачем добавлять zero-shot

Регулярки и энтропия дают точные, но ограниченные результаты, они видят только то, что явно похоже на известные токены (GitHub, Slack, AWS и т.п.).

Zero-shot модель добавляет гибкость и контекст. Она умеет распознавать скрытые или "словесно замаскированные" секреты, например, когда пароль указан в тексте без префиксов или когда он указан как тестовый (ага, те самые тестовые пароли, идущие в прод 🧠)

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

↗️ О точности и оценке
Рекомендация простая - создать небольшой «золотой» набор размеченных страниц и посчитать precision / recall / F1 до и после включения пост-верификации.

На практике zero-shot модель даёт заметный прирост точности без серьёзной потери полноты при корректной настройке порога (на тестах мне удалось достичь точности определения валидного секрета, с отсеиванием тестовых и фп в 98.4%)

🖌Практические советы, после болезненных тестов и бессоных ночей
🟢 Расширяйте сигнатуры - это улучшает охват.
🟢 Подбирайте пороги:
🔘 ⬆️ повышает точность
🔘 ⬇️ повышает полноту
🟢Для LLM-валидации держите temperature=0 и контролируйте JSON-ответ.
🟢 Сохраняйте результаты и метрики, чтобы отслеживать эффект изменений.

⚠️ Ограничения
🟣 Не работает с изображениями и вложениями.
🟣 Большие дампы требуют препроцессинга.
🟣 Высокоэнтропийные, но безопасные строки всё ещё могут вызывать ложные срабатывания, но с меньшей вероятностью (1.99%-5%)

Zero-shot классификация не заменяет ручной контроль, но превращает поиск утечек в управляемый и воспроизводимый процесс, а не в хаотичный ручной grep по страницам. А как итог, отмечу, что Вы можете достаточно быстро привести ранее затруднительные задачи в ML-powered AppSec и без использования "нанытой видеокарты".

Спасибо за внимание и буду рад, если накидаете моделей на тесты ❤️

🔴 Zero-shot модели для поиска конф данных в логах

Долгое время я думал, что в AppSec и так хватает тем и я не буду залезать на поприща смежных тем, но тут, возникла идея - "А что если в сок добавить чуточку магии?" И именно тут, я начал глубоко изучать тему с классификаторами, секретами и ML в частности. Вот Вы и читаете этот пост.

Чтож, если раньше soc-аналитики вручную проверяли логи или через сиемки (тут могла быть стебная шутка про то, что если выключить сием, то они ничего сделать не смогут, но она не прошла цензор), искали токены, session-id и приватные данные в инцидентах, то сегодня это можно отдать ML-модели.

Не в смысле "заменить человека", а в смысле - сделать анализ логов осмысленным и контекстным.

Как мне кажется, zero-shot модели -естественный следующий этап эволюции взрослеющего SOC, который начинает или уже задумался о подключении логов приложений и тех, кто предоставляет эти услуги. (Я конечно не прошу процент с будущих успешных сделок, но вы всегда можете меня отблагодарить чашкой кофе)

⚙️ Почему именно логи

Логи - это огромный, сырой и несовершенный поток внутренней информации.

В них можно найти:
🔘 токены доступа и refresh-ключи,
🔘 user/session identifiers,
🔘 stack traces с чувствительными payload’ами,

Regex тут бессилен, слишком много форматов, а чувствительность не всегда выражена словами “password” или “secret”, есть также куча нюансов по тому, как попадают логи и в каком формате лежат. Без глубоких познаний в архитектуре приложения, наши бравые L1(алладины🧞), L2 и L3 не смогут быстро и точечно детектировать что что-то не так или быстро искать нужные данные при инцидентах.

Поэтому, вместо бесконечных фильтров, я решил попробовать применить zero-shot классификацию, как это было в предыдущем посте.

💡 Идея

Используем pipeline(zero-shot-classification) и ставим задачу:

"Определи, содержит ли этот лог чувствительные данные."

Модель не ищет конкретные токены - она будет оценивать контекст: фраза, тип поля, значение, соседние строки, похожие проблемы.

Классы - "contains sensitive data" и "safe".

Это универсальный подход, не требующий обучения под конкретный формат логов.

🧃 Что это даёт SOC

🟢 Ловит контекстные утечки, которые regex игнорирует:

2025-10-07 03:12:45,212 [debug] Internal audit event: user=svc_billing_01 executed task "ExportMonthlySummary" 
using temp credentials issued via ephemeral STS session. 
Token issued for role arn:aws:iam::934812734812:role/BillingReportAccess expires in 900 seconds.

Тут у нас:
- Нет самого секрета
- Фраза «temp credentials» не уникальна
- Энтропия нулевая
- Regex-подход без контекста не отличит «audit info» от реальной утечки.

🟢 Ускоряет triage инцидентов - модель подсказывает, какие логи стоит анализировать вручную.
🟢 Снижает шум при корреляции алертов и артефактов.
🟢 Работает без переобучения, просто через inference.

⛏️ Практические нюансики

🟢 Модели, показавшие хорошие результаты:

Прошу простить вашего админа, так как я не имею доступа к реальным большим логам, чтобы всё протестировать более детально

typeform/mobilebert-uncased-mnli - ТЫК
MoritzLaurer/deberta-v3-large-zeroshot-v1 - ТЫК
facebook/bart-large-mnli - ТЫК

🟢 Для скорости — нарезайте логи на чанки и прогоняйте параллельно.

🟢 CPU-инференс чаще всего достаточно, GPU не обязателен.

🟢 Обязательно сохраняйте контекст вокруг найденной строки - иначе ревью превращается в угадайку.

⚠️ Ограничения

🟣 Бинарные данные и hex без контекста не определяются
🟣 Модель может ошибаться на технических фразах ("token bucket", "auth middleware").
🟣 PII внутри сериализованных структур (JSON, Base64) требует дополнительного препроцессинга.

❓ Почему это важно

Zero-shot подход делает SOC-анализ умнее и масштабируемее, что помогает всему отделу безопасности. Из принципа, теперь можно не просто реагировать на сигнатуру, а понимать смысл лога и сразу видеть собранные/подходящие данные. И в этом, будет наша главная победа: от паттерн-matching-а к контекстному security-анализу.

Да, regex по-прежнему нужен, но теперь он не единственный инструмент на вооружении сока.

⚠️ CVE-2025-49844 (RediShell)

В Redis обнаружена критическая уязвимость CVE-2025-49844 (RediShell). Use-after-free в Lua-движке, присутствовавший в кодовой базе с момента встраивания Lua ~13 лет. Эксплуатация позволяет выполнить произвольный код в контексте процесса Redis при наличии права на запуск Lua-скриптов.

❌ Что ломается

🔘 Уязвимость связана с парсером Lua (функции вроде luaY_parser / chunk name handling) и тем, как chunk name управляется на стеке Lua до/после вызова. При обработке специально сконструированного скрипта парсер может вызвать garbage collector в момент, когда ссылка на строку уже считалась ненужной, но код парсера всё ещё держит указатель на эту строку. В результате возникает use-after-free или по нормальному - освобождённая TString используется повторно.

🔘 Опасность UAF состоит в том, что при корректной последовательности действий злоумышленник может управлять освобождённой областью и подменить управляемые структуры/указатели, что приводит к исполнению кода в процессе Redis, по сути - RCE.

✉️ Известные PoC

Тестировать только в изолированной среде

🔵 Лаба с практической средой и PoC-демо - raminfp/redis_exploit (ТЫК)
🔵 dwisiswant0/CVE-2025-49844 (ТЫК) - содержит разбор luaY_parser / chunk name GC-race

🧃 Конкретные индикаторы и артефакты soc

🔵 В логах Redis присутствуют непонятные EVAL/EVALSHA/SCRIPT LOAD вызовы от неизвестных клиентов, последовательности команд, которые загружают/исполняют скрипты
🔵 Необычные процессы/сигнатуры на хосте после взаимодействия с Redis (подмена процессов, новые сокеты, нетипичная сеть)
🔵 Вызовы EVAL с скриптами, содержащими необычные chunk-names или многократные попытки вызвать тяжелые парс-операции (triage: считать инцидентом)

📝 Митигейшены

🔘 Обновить Redis до версии с исправлением (Redis 8.2.2 или позже)
🔘 Если немедленный патч невозможен, то нужно отключить исполнение Lua - ограничить EVAL/EVALSHA через ACL (запретить соответствующие привилегии) или конфигурацию, пока не обновитесь

redis-cli ACL SETUSER service_user off >somepassword ~* -EVAL -EVALSHA -SCRIPT

🔘 Найти все инстансы (public и private), убедиться, что Redis не развернут публично без проксирования
🔘 Ротация учётных данных и ключей, если есть подозрение на компрометацию (особенно если Redis использовался для хранения сессий/токенов)
🔘 Добавить детекции в SIEM по EVAL/SCRIPT LOAD, аномалиям аутентификации и всплескам активности

🌐 Ссылки на источники

RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score - ТЫК
Security Advisory: CVE-2025-49844 - ТЫК
CVE-2025-49844 Detail - ТЫК

Всем доброй ночи 🐈

🔔 Почему in-house SOC лучше аутсорса

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

Есть одна "уважаемая" компания. По связям проталкивает свои soc-услуги куда угодно: «мы быстрее, мы дешевле, у нас лучший MDR». А по факту - отсутствие экспертизы у интеграторов и неспособность оперативно решать ошибки подключения источников/нормализации/корреляции, проблемные агенты/их отсутствие, отговорки по типу "у нас нет данных", универсальные плейбуки, которые не знают ни вашего кода, ни ваших релизов. Красивые презентации - да, имеются. Практической пользы - минимум. Долги по SLA копятся быстрее, чем закрываются инциденты. И да, все "настройки под вас" упираются в договор и "в следующем квартале".

Главное слово для soc - адаптивность. Это когда корреляцию можно править сегодня, а не после совещаний, подтверждений или когда-нибудь потом. Когда у SOC есть доступ к репозиториям правил, к смбд, к релиз-планам и он понимает контекст событий. Адаптивность не покупается - её собирают внутри. Особенно при условии, что более менее здоровый и адаптированный под вашу инфраструктуру и контекст soc вырастает спустя год-полтора после начала работ

❌ Что обсёр аутсорсёр не даст

И это очень критично

🟣 Универсальные детекты не видят ваши бизнес-правила, а значит путают "норму" с инцидентом. FP не режется без знания архитектуры и данных.

🟣 Любая новая фича ломает "общие" правила. Внешний чендж-контроль = задержки в развитии. In-house меняет парсер/корреляцию в тот же спринт, если не в тот же день.

🟣 Когда TTP нестандартны, нужны инженеры, которые знают сервис изнутри, а не колл-центр по скрипту и отговорками по типу "у нас недостаточно даных"

🟣Своевременное реагирование в случае критичных инцидентов. Аутсорс, к сожалению, может только сказать "Вас вот тут ебут, смотрите" и развести руками


🧩 Почему свой SOC адаптивнее

🟢 Парсеры, нормализация (ECS/OTel), обогащения (CMDB, владельцы, релизы) - в одном репо. Можно выстроить процесс с другими командами иб и контролировать всё, начиная с пул реквестов и заканчивая деплоем релиза в прод.

🟢 Dev/SRE/SOC в одном канале, с едиными on-call и плейбуками. Нет прослоек из тикетов к внешним NOC.


🆗 Как изгнать нахлебников-аутсорсников из вашей сети

🔘Начните с инвентаризации вторжений.
Проверьте, куда эти "аудиторы" уже пролезли.
Доступы, vpn-токены, ssh-ключи, сервисные аккаунты в siem или интеграции, почтовые алерты на их домен - вычистите всё.
Если кто-то с внешнего адреса получает копии ваших инцидентов - это не партнёр, это наблюдатель с зарплатой из вашего бюджета.

🔘Заберите контроль над телеметрией.
Разверните свои пайплайны логов, сделайте свой брокер событий. Когда поток идёт через вас - вы решаете, что и в каком виде уходит наружу.

🔘Переопределите "их" зоны ответственности.
Никаких "общих" алертов, которые висят неделями.
Всё, что связано с продуктом, пользователями и кодом - только ваша зона.

🔘Перехватите коммуникации.
SOC-чат, инцидент-менеджмент, оповещения — всё через ваши каналы.
Когда инцидент сначала уходит внешнему диспетчеру, а потом вам — вы уже проиграли.
Аутсорс должен получать только то, что вы решили передать, а не наоборот.

👩‍💻 Что мы слышим и что отвечаем

🟡 "Мы дешевле" - дешёвый мониторинг равен дорогому инциденту.

🟡 "У нас экспертиза" - универсальная экспертиза без знания вашей инфраструктуры = красивые отчёты про "подозрительные события"

🟡 "24×7 спасёт" - круглосуточный просмотр fp - всё ещё fp. Спасает не часовая стрелка, а адаптивность

🟡 "Заполните excel таблицу о вашей инфраструктуре и мы скажем где у вас проблема" - я так проходил тесты "какой ты хлеб?" или "кто ты из феечек винкс?"

✏️ Вывод

Своя команда SOC - это не про "делать всё самим". Это про право быстро меняться, видя систему изнутри. Аутсорс можно использовать как усилитель покрытия и ночной мониторинг. Но ядро - внутри. Иначе вы отдаёте на сторону не "мониторинг", а способность принимать решения. И это самый дорогой актив безопасности в 2025 году.

🐾 Пост для тех, кто любит котиков, а не политику

- Женя Белкин, по поводу канала с фотками сырника - будет? Одна фраза, от вас зависит...
- Не будет.
- Не будет... Твердо и четко?
- Твердо и четко. И не просто это я придумываю. Или фантазия. Или не хотел бы. Нет, это всё просчитано...

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

Ссылка на моего любимца, он теперь медиа-создание - ТЫК

👀 EdgeAI for Beginners или как думать локально

Есть репозиторий от микромягких - ТЫК

На вид - курс "для самых маленьких", на деле - дорожная карта, как строить и запускать EdgeAI-модели

EdgeAI - это подход, при котором искусственный интеллект выполняет обработку и принятие решений на самих устройствах: камерах, шлюзах, сенсорах, пк - без передачи данных в облако, что снижает задержки, повышает приватность и автономность систем

Звучит прям круто, но, как всегда, дьявол кроется в деталях 💥


🔎 Что внутри

🔹 01-03 - основы ML, inference и оптимизация (ONNX, quantization, Olive)

🔹 04 - перенос моделей в edge-формат (Llama.cpp, OpenVINO)

🔹 05-06 - интеграция и маршрутизация агентов, работа с api и sdk

🔹 07-08 - Production: контейнеризация, обновления, ci/cd


💎 Что реально полезно

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

🟢 Quantization, pruning, mixed precision, Llama.cpp - всё, что делает inference доступным даже на малинке (raspberry pi)

🟢 Edge-агенты, которые могут переключаться между моделями в зависимости от задачи и контекста

🟢 Проект не для рекламы, а для тех, кто реально хочет руками запустить edge-проект


❌ Где зарыты риски

🟣 В курсе ни слова о защите моделей от извлечения и подмены

Edge без харденинга превращается в лёгкую добычу: достаточно подменить файл .onnx или подгрузить свой агент

🟣 Модели стареют быстрее, чем устройства. Без централизованного ci/cd вы получите зоопарк несовместимых версий

🟣 Локальный inference спасает от утечек, но требует чёткого контроля, кто и как обучает модель на устройстве

🟣 Да, quantization снижает латентность, но без ручной оптимизации под железо результат непредсказуем


↗️ Как можно применить в ибешечке

💡 Edge-soc. Модели аномалий крутятся локально, не передавая логи наружу

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

💡 Контекстная фильтрация трафика. Модели на сетевых узлах классифицируют пакеты по смыслу, а не по сигнатуре

💡 Privacy-by-design. Локальный inference = меньше PII в облаке, меньше комплаенс-боли


👀 Что вынести из всего этого

Edge-модели позволяют работать там, где latency, регуляции и здравый смысл не дают слать всё в AI-облако.

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

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

TL;DR: изучить, адаптировать, не доверять без ревью, и да - ставить апдейты руками