😈 Secret scanning, который наконец-то понимает смысл Я уже писал, как использую zero-shot модель как пост-верификатор для утечек из Confluence/Jira: сначала "шумный сбор", потом "умная фильтрация" SpecterOps в DeepPass2 сделали похожую философию, но гораздо жёстче технически, они вытаскивают пароль как сущность (span extraction), а не классифицируют "секрет/не секрет" и это уже другой уровень Сразу тык на само исследование - ТЫК Их главная идея - большинство secret scanners хорошо ловят структурированные токены (JWT, ключи, API tokens), потому что у них есть формат. А вот пароли... они могут быть словом, фразой, месяцем, временем года "ILoveWinter2026", и никакая энтропия/regex нас тут не спасут  🔴 Архитектура Они прямо фиксируют multi-tier пайплайн: 1️⃣ NoseyParker rules (regex) - быстро выносит всё, что легко матчится по сигнатурам 2️⃣ Document cleaning - найденные structured secrets вырезаются из текста, чтобы дальше не грузить модель и не "загрязнять" контекст. Меньше мусора = меньше FP у extraction-модели 3️⃣ BERT-token-classification - основная часть, модель делает sequence labeling и помечает токены "Password/Non-Password" 4️⃣ LLM verification - второй фильтр для снижения FP, в LLM отправляется _только_ то, что уже извлекла BERT-модель + соответствующий chunk контекста То есть LLM здесь не "сканер", а верификатор гипотез, как я предлагал ещё в далеком посте про zero-shot модели 🧠 Почему именно BERT/Roberta, а не "маленькая LLM" SpecterOps отдельно подчёркивают, что генеративные модели - это generative, а им нужно extractive. LLM склонны галлюцинировать пароли и "додумывать" то, чего нет, плюс они тяжелее и медленнее. Поэтому базовая модель у них — xlm-roberta-base (~278M параметров) в режиме token classification, дообученная через LoRA (r=64, target_modules: query/key/value/dense). Такой стек реально крутить локально/дёшево по ресурсам, и это уже ближе к "реальному AppSec", а не "пойдём купим ещё GPU или оплатим ещё токенов". У модели max_len 512 токенов, поэтому документ режется на чанки 300–400 токенов + overlap  И здесь тонкость, что chunking для них это: - они явно упоминают, что длинные входы у LLM страдают от position bias, поэтому система работает chunk-level - возможность вернуть не только "пароль найден", а "пароль найден + ближайший контекст", чтобы triage не превращался в поиск незнамо чего 💡 Датасет - самый интересный кусок С данными у них честно "боль" - редкий кейс, мало реальных размеченных документов. Поэтому они сделали гибрид: - LLM генерирует ~2k длинных документов (2000+ токенов), половина с паролями, половина без. - затем эти длинные документы режутся на чанки 300–400 - проблема: LLM генерирует примитивные пароли (P@55W0RD, vaultKey2025!), и модель на них учится "слишком легко" - чтобы поймать "невинные" пароли типа ILoveMyCity, они добавляют breached passwords + usernames, создают 1000 "скелетных" предложений и вставляют реальные пары user/pass в логичные места текста В итоге обучающий сет: 23k примеров, 2200 на тест.  Это, по-хорошему, то, что большинство команд не делает вообще: они либо гоняют regex, либо надеются на LLM "на глаз". 👀 Они поняли, что "accuracy" = ловушка Они вводят две модели оценки: - Strict Accuracy: попадание 1:1 по всем извлечённым паролям в чанке - Overlap Accuracy: достаточно перекрытия >30% (потому что subword-tokenization может “съесть” символы/границы) По результатам: - Strict Accuracy: 86.67% (BERT) / 85.79% (LLM) - Overlap Accuracy: 97.72% (BERT) / 95.35% (LLM)  И самое показательное - password-level confusion matrix: - FP: 49 (BERT) vs 57 (LLM) - FN: 138 (BERT) vs 211 (LLM)  Т.е. BERT у них банально лучше по recall и FP, но LLM они всё равно оставляют "в контуре" как слой доп валидации 📕 Вывод DeepPass2 - это редкий случай, когда "ML для секретов" сделан не как хайп (так ещё модно говорить?), а как инженерный пайплайн: - structured secrets отдаются regex-ам - free-form passwords - extraction модели - LLM то