Як новий сканер секретів GitHub ловить більше витоків з меншою кількістю ложних спрацьовувань?

Чому загальні секрети створюють проблему

Структуровані облікові дані мають відомий префікс, фіксовану довжину, визначений алфавіт чи контрольну суму. У загальних секретів таких маркерів немає.

Як працює сканер

Новий сканер використовує двостадійний конвеєр. Першою йде генерація кандидатів. Регулярні вирази швидко і детерміновано шукають потенційні секрети з високим recall. Цей етап охоплює широкі родини схожих на облікові дані шаблонів. Далі — контекстно-залежна класифікація. Налаштований класифікатор ModernBERT оцінює кожного кандидата та його оточення. Він розпізнає сигнали, що відокремлюють реальні секрети від ложних спрацьовувань: заповнювачі, приклади, уривки документації. Згенерований контент і нечутливі ідентифікатори теж враховуються. Модель невелика та ефективна на інфраструктурі виводу GitHub. Її обслуговування коштує значно дешевше, а масштабування простіше, ніж у конвеєрах на базі LLM. Модель не замінює детерміноване сканування. Вона його доповнює. Регулярні вирази залишаються правильним інструментом для швидкого пошуку кандидатів. Класифікатор бере на себе те, де машинне навчання дає найбільший ефект: розрізнення «виглядає як секрет» і «є реальним секретом».

Прискорення та економія

Компактна модель скоротила медіанний час сканування після push на 86 % порівняно з попереднім LLM-конвеєром. Така ефективність дозволила розширити виявлення загальних секретів на push protection — результат повертається до розробників до відправки змін, а не лише після коміту. Витрати на обслуговування впали понад на 98 % порівняно з віддаленими викликами LLM. Навчена модель експортується у формат ONNX з 8-бітною квантизацією для швидкого виводу. У виробничому A/B-тесті зважена прийнятність власниками репозиторіїв зросла на 11,5 %. Зважування власниками зменшує вплив клієнтів, які масово закривають великі обсяги сповіщень, спотворюючи простий середній. Офлайн-оцінка на тому самому публічному трафіку показала на 13 % вищу точність і на 19 % вищий recall, ніж попередній LLM-конвеєр.

Навчання на плутаних прикладах

Складність полягала у пошуку репрезентативних даних для випадків, де синтаксис лише плутає. Стратегія поєднує три джерела: приклади з продуктів GitHub, зворотний зв'язок від виявлення секретів та додаткова людська валідація.

Що далі

GitHub зосереджується на двох напрямках. Створення безперервного циклу покращення, що використовує виробничі петлі зворотного зв'язку для виявлення нових false negatives та false positives. Реальні сигнали перетворюються на дані вищої якості для навчання та оцінки. Дослідження нових архітектур моделей, що виконують виявлення та витягування секретів у одному кроці. Це скорочує складність конвеєра при збереженні точності та масштабу. Поєднання швидкості regex та навченого розуміння контексту перевершує кожен підхід окремо для цих обмежень продукту. Менша налаштована класифікатор — правильна відповідь, коли задача вузька, межа рішення вимірювана, а ефективність обслуговування критична. Кандидати від регулярних виразів з високим recall з даних репозиторіїв GitHub — з людськими анотаціями та слабкими мітками для розширення покриття. Синтетичні приклади для рідкісних і складних випадків: секрети в документації, тестові фікстури, публічні ключі. Контрольні суми, структуровані подібники, пари «майже влучили». Синтетичні рядки проходять детерміновану валідацію та перевірку якості моделлю перед включенням. Навчання акцентує увагу на реальних секретах, реалістичних ложних спрацьовуваннях. Важкі негативи, що плутають regex-підходи, теж входять у вибірку. Кожен вхід моделі містить значення кандидата, шлях до файлу, тип секрету. Обмежений обсяг контексту додається окремо. Перед розбиттям даних рядки, що мають спільний репозиторій, значення кандидата чи приклад, групувалися. Це запобігає потраплянню майже дублікатів одночасно у навчання та оцінку. Найважливіший принцип — показати моделі плутані приклади. Класифікатор вчиться контекстним відмінностям з позначених прикладів, а не вимагає від інженерів закодувати кожне виняткове правило окремо. Їхній синтаксис перекривається з ідентифікаторами збірок, контрольними сумами, хешами активів, прикладами значень та іншими нечутливими рядками. Контекст стає вирішальним сигналом. Пароль поруч із URL виробчої бази даних — справжній. Той самий парольоподібний фрагмент у тестовому фікстурі — безпечний. Рядок підключення у конфігурації розгортання має значення. Рядок до localhost у посібнику — ні. Це важкі негативи: рядки, що відповідають шаблону облікових даних, але не є робочими секретами. Додаткові правила придушують частину. Кожне виняткове правило ризикує приховати реальний секрет.