Сканер секретов Betterleaks: архитектура и ключи
Обнаружение секретной информации в репозиториях за последние годы значительно изменилось. Раньше достаточно было искать подозрительные строки или ключи с высокой энтропией в коде. Сегодня ситуация иная: большие репозитории, более быстрые конвейеры CI/CD и, прежде всего, растущий объем кода, генерируемого автоматизированными инструментами или моделями искусственного интеллекта.
Это имеет практическое последствие: проблема заключается уже не только в обнаружении секретов, но и в отделении действительно опасного от того, что лишь кажется таковым. Многие команды обнаруживают, что реальная стоимость этих сканеров заключается не в проведении анализа, а в проверке сотен ложных срабатываний.
Архитектура обнаружения: что меняется с появлением Betterleaks?
Betterleaks появляется именно в этом контексте. Он не пытается полностью переосмыслить секретное сканирование, но бросает вызов широко распространенному предположению: что обнаружения закономерностей достаточно.
Во многих современных репозиториях это не так.
Проект, разработанный Заком Райсом и поддерживаемый при поддержке айкидо, предлагает несколько иной подход. Вместо того чтобы сосредотачиваться исключительно на обнаружении совпадений, он пытается проверить, имеет ли обнаруженное совпадение смысл, прежде чем передать его в качестве оповещения.
Это может показаться незначительной деталью, но она существенно меняет динамику в больших командах. Когда система сканирования генерирует слишком много нерелевантных оповещений, естественная реакция команды — игнорировать их. А в сфере безопасности игнорирование оповещения может быть хуже, чем его отсутствие.
Для решения этой проблемы Betterleaks внедряет два интересных технических решения: проверку с использованием CEL (Common Expression Language) и метрику под названием «Эффективность токенов», основанную на токенизации BPE.
Идея заключается в том, что не всё, что кажется секретом, на самом деле им является. Некоторые строки с высокой энтропией представляют собой просто хеши, идентификаторы или автоматически сгенерированные фрагменты. Цель системы — уменьшить этот «шум».
В документации проекта приводится сравнение, в котором токенизация BPE достигает показателя полноты 98,6% по сравнению с 70,4%, полученными при использовании энтропии в наборе данных CredData. Как и в случае с любым бенчмарком, эти цифры являются ориентировочными. Они хорошо служат в качестве точки отсчета, но не заменяют тестирование в реальных репозиториях.
Источник: GitHub
Компоненты, которые имеют решающее значение
Анализ характеристик проекта позволяет выделить четкое направление: упростить развертывание в реальных условиях без излишнего усложнения технических аспектов.
К числу наиболее заметных элементов относятся:
- Проверка, определяемая правилами, с использованием CEL (Common Expression Language)
- Сканирование эффективности токенов на основе токенизации BPE, а не энтропии, достигло 98,6% полноты по сравнению с 70,4% при использовании энтропии на наборе данных CredData.
- Реализация на чистом Go (без зависимостей от CGO или Hyperscan).
- Автоматическая обработка секретов с двойным/тройным кодированием.
- Расширен набор правил для большего числа поставщиков услуг.
- Параллельное сканирование Git для более быстрого анализа репозитория
Хотя этот список может показаться всего лишь набором технических улучшений, интересно то, как они влияют на повседневное использование.
Например, полноценная реализация на Go без нативных зависимостей значительно упрощает интеграцию в конвейеры CI/CD. Во многих командах именно такие мелочи определяют, будет ли инструмент использоваться или забыт в репозитории.
Токенизация BPE также предлагает иной подход. Вместо простого измерения случайности цепочки, она анализирует шаблоны токенов, которые более точно отражают реальную структуру современных учетных данных.
Что происходит, когда сканер что-то обнаруживает?
Когда Betterleaks обнаруживает потенциальную тайну, процесс на этом не заканчивается.
Сначала контекст оценивается с использованием правил, определенных в CEL. Это позволяет добавлять дополнительные условия: например, проверять, соответствует ли формат ожидаемому поставщику, или отбрасывать шаблоны, которые часто встречаются в примерах или фиктивных данных.
Этот шаг может показаться тривиальным, но он имеет существенное практическое значение. Ложные срабатывания не только отнимают время, но и снижают доверие команды к системе оповещения.
Ещё один интересный аспект — автоматическая обработка секретов, закодированных несколько раз. В некоторых репозиториях учетные данные отображаются преобразованными с использованием base64 или других схем кодирования, что усложняет их обнаружение.
Тем не менее, стоит помнить о том, что иногда упускается из виду: ни один сканер не может полностью заменить проверку человеком. Обнаружение секрета — это только начало; решение о том, что с ним делать (отозвать, сменить, игнорировать или расследовать), остается контекстным.
Управление и человекоцентрированный подход/Искусственный интеллект
Betterleaks распространяется под лицензией MIT и включает в себя внешние материалы от таких организаций, как Royal Bank of Canada, Red Hat и Amazon.
Проект также пытается адаптироваться к реальности, которая все чаще встречается в современных репозиториях: смешению кода, написанного разработчиками, и кода, сгенерированного автоматизированными инструментами.
В этом контексте инструмент призван эффективно функционировать как в рабочих процессах, выполняемых человеком, так и в автоматизированных системах, которые проверяют целые репозитории. Это соответствует растущему использованию автоматизация и инструменты которые анализируют код или генерируют автоматические обзоры.
В дорожную карту также включены интересные идеи: интеграция с источники данных помимо GitПоддержка языковых моделей для классификации результатов и механизмы автоматического отзыва разрешений через API поставщиков услуг.
Это порождает интересную дискуссию. Автоматизация отзыва учетных данных может сократить время реагирования на инцидент, но это также означает, что приходится полагаться на точность системы классификации.
Если автоматическое аннулирование не удается или происходит по ошибке, это может иметь значительные последствия для работы системы.
Практические последствия и ограничения
С операционной точки зрения, Betterleaks привлекателен для команд, стремящихся уменьшить количество ложных срабатываний и упростить развертывание.
Но также важно помнить о некоторых ограничениях:
- Показатели полноты зависят от используемого набора данных и могут значительно различаться в разных репозиториях.
- Для автоматизации таких действий, как аннулирование ключей, требуются дополнительные средства контроля и журналы аудита.
- Скрытые сканеры остаются лишь одним из уровней защиты в рамках более широкой стратегии.
Во многих случаях решение о внедрении такого инструмента зависит не столько от его теоретической точности, сколько от чего-то более простого: насколько хорошо он интегрируется в рабочий процесс команды.
Высокоточный сканер, создающий слишком большое трение, обычно отбрасывается. Достаточно точный сканер, который легко интегрировать, обычно сохраняется.
В этом смысле Betterleaks пытается найти баланс. Он не обещает полностью исключить ложные срабатывания или заменить существующие процессы обеспечения безопасности, но стремится уменьшить информационный шум и облегчить интеграцию в современные системы мониторинга.
Проект доступен на GitHub. Представленный подход является развитием метода, используемого Gitleaks, и призван адаптироваться к репозиториям, где автоматизация, аналитические агенты и код, генерируемый языковыми моделями, являются неотъемлемой частью процесса разработки.
