<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="Сканирование KeyHog с указанием серьёзности, доказательств, файла и строки, способов устранения, результатов и статуса покрытия" width="900" />
</p>

## Сканер секретов, построенный вокруг GPU

KeyHog не передаёт несколько регулярных выражений в универсальный вычислительный шейдер.
Его GPU-путь построен на [Vyre](https://github.com/santhreal/vyre) — Rust GPU
вычислительной подложке, разработанной вместе с KeyHog. Триггеры детекторов компилируются в
неизменяемые таблицы, размещаемые в GPU. Ограниченные исходные пакеты дают полные позиции
совпадений для того же конвейера подтверждения, подавления, сбора доказательств и отчётности,
который используется в CPU- и Hyperscan-маршрутах.

- **Три физических GPU-пира.** CUDA, нативный Metal и портативный WGPU
  подключаются, измеряются и учитываются независимо.
- **Точное совпадение результатов.** Калибровка отклоняет кандидата, чья
  идентичность находки отличается от эталонного маршрута. Более быстрый неверный ответ никогда не попадает
  в таблицу маршрутизации.
- **Постоянные доказательства маршрута.** KeyHog записывает бинарный файл, корпус детекторов,
  конфигурацию, класс рабочей нагрузки, хост, ускоритель, драйвер и измеренные временные
  показатели. Обычные сканирования не выполняют бенчмаркинг на горячем пути.
- **Резидентное выполнение.** Фоновые рабочие процессы демона поддерживают скомпилированные детекторы и состояние
  ускорителя в тёплом виде для повторяющихся пакетов файлов, архивов, истории, удалённых и облачных источников.
- **Нет скрытого запасного пути на CPU.** Явно выбранный ускоритель, который не может
  инициализироваться или выполнить диспетчеризацию, завершается с видимой ошибкой, а не возвращает находки CPU под
  меткой GPU.

Установка crates.io по умолчанию использует портативный чисто-Rust CPU-маршрут, поэтому она работает
на чистом Rust-хосте. Включите три GPU-пира без приобретения Hyperscan:```sh
cargo install --locked keyhog --no-default-features --features portable,gpu

Запустите диагностику продакшен-бэкенда, затем проверьте измеренный маршрут:```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Первая команда сохраняет просмотренные находки и завершается с кодом `0`, не выводя
их. Зафиксируйте этот файл, затем используйте вторую команду, чтобы сообщать только о новых
идентификаторах находок. Базовая запись сопоставляется по детектору и значению учётных данных,
но никогда по пути к файлу, поэтому перемещение записанного секрета не приводит к сбою проверки, а вот
его ротация — приводит. Изменённые учётные данные и неполное покрытие остаются видимыми.
Полный путь, включая разделы монорепозитория, описан в разделе [Сбой только при новых
секретах](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets).

Для следующего сканирования используйте [поваренную книгу
рецептов](https://santhreal.github.io/keyhog/recipes.html) или копируемые
команды из раздела [Выберите подходящий рабочий процесс](#choose-the-right-workflow). Вы можете
сканировать историю Git, образы контейнеров, облачные хранилища, коллекции репозиториев,
URL-адреса и целую машину, не меняя инструменты.

### Защита репозиториев для быстрых pre-commit сканирований

Зарегистрируйте репозиторий в постоянном демоне KeyHog для быстрого
обнаружения секретов перед коммитом (требуется Unix; в Windows используйте внутрипроцессный `keyhog scan`):```sh
# 1. Start the daemon (accelerated by CUDA, Metal, WGPU, or SIMD)
keyhog guard up

# 2. Guard your repository (indexes baseline and installs pre-commit hook in one step)
keyhog guard add /path/to/repo

# 3. Every staged commit checks only changed blobs against in-memory attestations
keyhog scan --git-staged

# 4. View all active guarded repositories and their states
keyhog guard list

# 5. Turn the daemon on and off cleanly without losing registrations or durable index
keyhog guard down

Действие сканирует извлечённое дерево, завершается с ошибкой при обнаружении находок уровня `high` или `critical`, загружает SARIF в Code Scanning и сохраняет отчёт как артефакт рабочего процесса. Сбои установки, покрытия, бэкенда и публикации отчёта также приводят к провалу задания.

Используйте [руководство по GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) для получения информации о входных данных, выходных данных, принятии базовой линии, разбиении монорепозиториев, проверке и поведении при сбоях. Используйте [руководство по CI](https://santhreal.github.io/keyhog/workflows/ci.html) для GitLab, CircleCI, Jenkins, Buildkite и универсальных shell-заданий. Используйте [руководство по массовому сканированию](https://santhreal.github.io/keyhog/guides/mass-scanning.html) для организации репозиториев, размещённых Git-групп, облачных хранилищ и сегментированных инвентаризаций.

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

KeyHog сканирует байты на границе, где они могут утечь, а не только отслеживаемые исходные файлы. Используйте один отчёт на границу, чтобы CI сохранял точное покрытие и состояние сбоя.

| Поверхность воздействия | Пример |
|---|---|
| Финальный артефакт пакета | Выполните `npm pack`, затем просканируйте полученный `.tgz` с помощью `keyhog scan package.tgz`. Распаковка архива проверяет сгенерированные файлы, source maps, фикстуры и метаданные, отсутствующие в ожидаемом дереве исходников. |
| Развёрнутое браузерное приложение | `keyhog scan --url https://app.example.com/assets/app.js` выполняет ограниченное декодирование JavaScript, source-map, WASM и ответов, не превращая сканер в неограниченный краулер. |
| GitHub issues, pull requests, обсуждения, вики и gists | `keyhog scan --github-collaboration owner/repo --github-all` сканирует все поверхности совместной работы за пределами извлечённого дерева. |
| Конфигурация AI-агентов и MCP | `keyhog scan ~/.config ~/.claude ~/.codex` применяет тот же конвейер детекторов, декодирования, доказательств и отчётов к локальной конфигурации инструментов. |
| Слои контейнерных образов | `keyhog scan --docker-image registry.example.com/team/app:v1` сканирует содержимое образа, которое будет запущено, включая файлы, добавленные во время сборки. |
| Инвентаризации облачных объектов | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` или `--azure-container-url URL` сохраняет пагинацию провайдера, объекты и ограничения по байтам в терминальном отчёте. |
| Весь хост разработки | `sudo keyhog scan-system --space 50G` обнаруживает смонтированные файловые системы и достижимую историю Git в рамках жёсткого бюджета хранилища. |

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

## Выберите правильный рабочий процесс

Сначала выберите границу источника. Пресет меняет работу обнаружения, а бэкенд — способ выполнения. Ни то, ни другое не расширяет сканирование рабочего дерева до истории Git, инвентаризации провайдера, облачного хранилища или аудита хоста.

Не существует честного ярлыка `scan everything`. Полный обзор окружения запускает соответствующие границы ниже как отдельные задания и сохраняет каждый отчёт `json-envelope` с его исходным кодом выхода.

| Потребность | Начните с | Пропускная способность и повторное использование | Граница покрытия |
|---|---|---|---|
| Быстрая локальная обратная связь | `keyhog scan . --fast --incremental` | Повторно использует хэши неизменённых файлов. Быстрый пресет пропускает работу по декодированию, энтропии и ML. | Запустите политику по умолчанию перед слиянием, потому что быстрый режим намеренно уже. |
| Полное сканирование репозитория | `keyhog scan .` | Калиброванный `auto` и стандартное количество рабочих процессов по числу ядер CPU. Добавьте `--incremental` для повторных сканирований одного и того же доверенного дерева. | Только текущие файлы. История Git не добавляется. |
| Шлюз для staged-коммитов | `keyhog scan --git-staged` или `keyhog hook install` | Читает точные blob-объекты индекса, поэтому незакоммиченные правки не могут изменить результат. | Только staged-содержимое. Запустите сканирование рабочего дерева отдельно, если важны локальные незакоммиченные байты. |
| Постоянная защита репозитория | `keyhog guard add . --mode repo`, затем `keyhog guard status .` | Демон-резидентный корневой реестр с 7-состояний машиной, чистым кэшем аттестаций и отслеживанием идентичности политики. | Требуется запущенный демон. Guard дополняет, а не заменяет сканирование staged и рабочего дерева. |
| Шлюз GitHub pull request | `santhreal/keyhog@v0` | Action устанавливает, сканирует, публикует SARIF и артефакт, затем сохраняет статус KeyHog. | Один извлечённый путь. Для организации используйте сканирование инвентаризации провайдера. |
| GitLab, Jenkins, Buildkite или shell CI | `keyhog scan . --format json-envelope --output keyhog.json` | Сохраняйте отчёт и код выхода при успехе, находках и ошибках. Используйте `--git-diff <base>` только для явно более узкого шлюза изменённых строк. | Байты, присутствующие в извлечённом дереве, или выбранный diff. |
| Принятие репозитория с известными находками | Создайте `.keyhog-baseline.json`, закоммитьте его, затем сканируйте с `--baseline .keyhog-baseline.json`. | Существующие идентичности остаются видимыми в базовой линии, а шлюз проваливают только новые находки. | Базовая линия не подавляет изменённые учётные данные или неполное покрытие. |
| Рекурсивное восстановление Git | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | Калибруйте глубокую политику один раз на класс рабочих процессов. Запускайте в процессе. | Один репозиторий. `--git-history` покрывает только предков текущего извлечённого дерева, поэтому ветка, которую вы никогда не извлекали, пропускается без пробела покрытия; `--git-blobs` также достигает висячих blob-объектов, коммитов, удалённых через amend, stash, заметок, сообщений аннотированных тегов и упакованных ссылок. |
| Проверка контейнера или архива | `keyhog scan --docker-image registry/app:v1` или `keyhog scan incoming/` | Сохраняйте отчёт-конверт, чтобы пропущенные, повреждённые, зашифрованные, небезопасные или слишком большие элементы оставались видимыми. | Только выбранный образ или путь файловой системы и поддерживаемые вложенные форматы. |
| Проверка URL, ответа или HAR | `keyhog scan --url https://api.example.com/config` или `keyhog scan capture.har` | Используйте ограниченные лимиты источника и сохраняйте терминальный конверт. | Только полученные ответы или записи захвата. Это не краулер. |
| Инвентаризация организации или облака | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | Разделяйте по провайдеру, владельцу или bucket. Запускайте независимые разделы параллельно с одним отчётом и статусом для каждого. | Одна выбранная инвентаризация провайдера на задание. Лимиты пагинации или объектов остаются границами покрытия. |
| Подтверждение, активны ли подходящие находки | `keyhog scan . --verify` | Параллелизм провайдера и контроль скорости отделены от рабочих процессов сканера. | Отправляет запросы, производные от учётных данных, на объявленные конечные точки провайдера. Не каждый детектор поддерживает проверку. |
| Проверка здоровья всего хоста | `sudo keyhog scan-system --space 50G` | По умолчанию использует все ядра CPU и сканирует обнаруженную историю Git после данных файловой системы. | Локальные смонтированные файловые системы. Сетевые монтирования — по желанию, а потолок пространства жёсткий. |
| Каталог, история, архив, удалённый источник или облачная инвентаризация с GPU на Unix | Калибруйте autoroute, запустите `keyhog daemon start --mass`, затем выполните `keyhog scan --daemon=mass <SOURCE>`. | Потоковая передача ограниченных пакетов через один скомпилированный CPU, Hyperscan, CUDA, Metal или WGPU-рабочий процесс. Добавьте `--incremental` для тёплых неизменённых деревьев файловой системы. Терминальная квитанция сообщает точные итоги и GPU-пакеты, чанки, байты, долю GPU и пропускную способность. | Базовые линии, проверка, lockdown, пресеты, оверлеи и другие изменения политики сканера отклоняются до сбора. Инкрементальное состояние применяется только к локальным корням файловой системы демона. |

### Сканируйте каждую поддерживаемую границу источника

Используйте одну команду на границу. Сохраняйте отчёт `json-envelope` и исходный статус выхода для каждого раздела инвентаризации.

| Источник или вариант использования | Команда |
|---|---|
| Несколько локальных корней | `keyhog scan services/api services/web deploy/` |
| Постоянно изменяемые файлы | `keyhog watch services/api deploy/` |
| Staged-байты, изменённые строки, достижимая история или blob-объекты | `keyhog scan --git-staged`, `--git-diff main`, `--git-history .` или `--git-blobs .` |
| Нативные бинарники и строки прошивки | `keyhog scan --binary firmware.bin` (обычное сканирование каталога пропускает бинарники и всё равно завершается с кодом `0`) |
| Архивы и сжатые источники | `keyhog scan incoming/` (поддерживаемые элементы распаковываются автоматически) |
| Слои Docker-образов | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, source maps, WASM или ответ конечной точки | `keyhog scan --url https://api.example.com/config` |
| Захваты HTTP-запросов и ответов | `keyhog scan capture.har` |
| GitHub issues, pull requests, обсуждения, вики и gists | `keyhog scan --github-collaboration owner/repo --github-all` |
| Инвентаризации GitHub, GitLab или Bitbucket | `--github-org ORG`, `--gitlab-group GROUP` или `--bitbucket-workspace WORKSPACE` |
| Инвентаризации S3, GCS или Azure Blob | `--s3-bucket BUCKET`, `--gcs-bucket BUCKET` или `--azure-container-url URL` |
| Ограниченный поток из другого инструмента | `producer \| keyhog scan --stdin` (используйте `set -o pipefail`, чтобы сбой продюсера отображал собственную ошибку, а не сканирование нулевого размера) |

Обычное сканирование каталога не читает нативные бинарники. Каждый из них становится пробелом покрытия `binary (extension or content sniff)`, сканирование всё равно завершается с кодом `0`, и `--no-default-excludes` этого не меняет, поэтому передавайте `--binary`, когда скомпилированные артефакты входят в область действия. Этот флаг требует сборки с функцией `binary`, которая есть в стандартной установке crates.io и отсутствует в облегчённой функции `ci`.

Извлечение нативных бинарников сообщает полные учётные данные, удовлетворяющие явному контракту формы именованного детектора. Оно подавляет короткие фрагменты префиксов и строки общего вида присваивания из скомпилированных секций данных, потому что эти байты не сохраняют контекст источника.

Получение конечных точек ограничено и защищено от SSRF. Это не краулер. Частные облачные конечные точки и пересылка учётных данных требуют явных флагов доверия. Токены провайдера должны находиться в документированных переменных окружения, а не в аргументах процесса.

Используйте [выбор рабочего процесса](https://santhreal.github.io/keyhog/capabilities.html) для деталей источника и политики, [руководство по GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) для поддерживаемого шлюза репозитория, [прямое руководство по CI](https://santhreal.github.io/keyhog/workflows/ci.html) для долговечных отчётов и обработки кодов выхода, а [руководство по массовому сканированию](https://santhreal.github.io/keyhog/guides/mass-scanning.html) для разделения и агрегации. [Кулинарная книга рецептов](https://santhreal.github.io/keyhog/recipes.html) охватывает контейнеры, архивы, URL, контент совместной работы GitHub и облачные источники.

### Скорость и параллелизм без догадок

Начните со значений по умолчанию. Cargo не может выполнить KeyHog после `cargo install`, поэтому выполните команды ниже один раз после установки многобэкендной сборки Cargo и снова после изменения хоста, бинарника, корпуса детекторов, драйвера или классов рабочей нагрузки:```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Для общего раннера, где заданию выделено четыре рабочих процесса сканера и один
рабочий процесс чтения:```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

Соберите репозиторий из исходников, когда вам нужна невыпущенная правка:```sh
cargo install --path crates/cli --locked

Используйте [руководство по установке](https://santhreal.github.io/keyhog/install.html) для
требований к инструментарию Rust, профилям функций и зависимостям времени выполнения
для конкретных платформ.


## Что он обнаруживает

934 встроенных детектора с автономной валидацией и компаньонами, принадлежащими детекторам:

- **Облачные провайдеры:** AWS (ключ доступа + секрет + проверка STS),
  Azure (ключ подписки, ключ учётной записи хранения, SAS), GCP (сервисный
  аккаунт, ключ API), Cloudflare, Heroku, Vercel, Supabase.
- **Платёжные процессоры:** Stripe, Braintree, Razorpay, Paddle, Plaid,
  Square и PayPal, с проверками, принадлежащими детекторам, и необязательными или
  обязательными компаньонами. Секрет ключа Razorpay требует расположенный рядом идентификатор ключа.
- **Хостинги исходного кода:** GitHub PAT (с контрольной суммой CRC32), токены GitLab,
  пароли приложений Bitbucket, токены npm (с контрольной суммой), Gitea / Forgejo
  / Codeberg.
- **Auth / SSO:** Okta, Auth0, Clerk, JumpCloud, Kinde.
- **Коммуникации:** Slack, Discord, Twilio, SendGrid, Postmark, Mailgun,
  Resend, Loops.
- **AI / ML:** OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio,
  Cohere, Mistral, HuggingFace, Replicate. Учётные данные организации
  HuggingFace включают как текущую форму `hf_`, так и устаревшие токены `api_org_`.
- **Менеджеры паролей:** секретные ключи учётной записи 1Password (`A3-` с последующими
  пятью или шестью сегментированными прописными буквенно-цифровыми компонентами).
- **Базы данных:** строки подключения Postgres, MongoDB Atlas, сервисная роль
  Supabase, PlanetScale, Neon, Turso, MySQL, URL-адреса Redis.
- **Общие + обнаружение энтропии:** `API_KEY=<высокоэнтропийный блок>` обнаруживает
  учётные данные без именованного детектора, ограниченные порогами энтропии
  для каждого контекста + оценкой ML.
- **Криптографические материалы:** закрытые ключи RSA / EC / SSH, закрытые блоки
  PGP, секреты подписи JWT.

Каждый детектор поставляется в виде [TOML-файла](https://github.com/santhreal/keyhog/blob/main/detectors) (данные, а не код):
метаданные сервиса, шаблоны регулярных выражений, ключевые слова, автономные валидаторы, политика энтропии и ML,
поля компаньонов и обработчик проверки. Добавление нового детектора — это
одно проверяемое изменение TOML;
[руководство для участников](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md) проведёт вас по этому процессу.

`keyhog explain <id>` выводит полную спецификацию любого детектора: шаблоны, ключевые слова,
конечную точку проверки, а также руководство по ротации и пошаговому
устранению, привязанное к сервису, так что находка никогда не остаётся чёрным ящиком:

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat: дамп спецификации детектора (шаблон ghp_[A-Za-z0-9]{36}, ключевое слово, URL проверки), за которым следует руководство по ротации github и пошаговое устранение" width="860" />
</p>

Просматривайте создание и проверку детекторов в
[справочнике детекторов](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md) или запрашивайте установленный корпус с помощью
`keyhog detectors --search <термин> --verbose`.

## Почему выше полнота, меньше ложных срабатываний

- **Сканирование с декодированием.** Манифесты `Secret` Kubernetes, блокноты
  Jupyter, полезные нагрузки JWT, окружения в base64, значения Helm и блоки
  `auth:` в docker-config. Структурированный препроцессор рассматривает сбалансированные действия Helm как
  инертные значения времени рендеринга и закрывает отсутствующие разделители Jupyter в конце файла,
  поэтому литеральные байты и полные ячейки кода остаются покрытыми. Он декодирует структурированные
  значения на месте и передаёт каждому последующему детектору открытый текст. Детекторам
  не нужно заново реализовывать декодирование. Сканирование с включённым декодированием также восстанавливает
  выражения XOR байтовых массивов JavaScript и AES-256-CBC без побочных эффектов, когда
  весь материал для восстановления встроен, включая строгие обёртки паролей с солью CryptoJS/OpenSSL.
  KeyHog никогда не выполняет исходный код.
- **Пересборка многострочных значений.** Продолжение `"sk-proj-" + \` в JavaScript,
  многострочные строки YAML, продолжение с обратной косой чертой в Makefile, выводы с
  шаблонами Helm / Jinja — всё пересобирается перед сопоставлением с регулярным выражением.
- **Проверка компаньонов.** Обязательные компаньоны ограничивают детекторы с высоким уровнем шума. Ключ
  API Twilio без его секрета API пропускается. Необязательные компаньоны обогащают
  оценку доказательств или проверку. Обнаружение ключа доступа AWS не требует
  его секрета, но секрет необходим для живой проверки.
- **Разрешение между детекторами.** TOML детектора может требовать, отклонять или поглощать
  ограниченные находки другого детектора. Разрешение остаётся детерминированным независимо от
  порядка входных данных, а недопустимые цели, противоречия или циклы зависимостей приводят к сбою
  компиляции корпуса.
- **Вердикты доказательств.** Каждая находка несёт точный уровень `review`, `likely` или
  `confirmed` плюс канонический код причины. Внутренняя контрольная сумма или грамматическое
  доказательство, обязательные компаньоны и живая проверка дают подтверждённые доказательства;
  сильная специфичная для вендора форма в роли, несущей учётные данные, даёт вероятные
  доказательства; слабые якоря, общие присваивания, кандидаты только по энтропии и контексты
  тестов, документации, правил или идентификаторов остаются доказательствами уровня review.
  Необязательный `evidence_score` дополняет вердикт, когда он измерен.
  Порог по умолчанию `0.40` управляет внутренним минимальным уровнем уверенности сканера
  и остаётся настраиваемым с помощью `--min-confidence`.
- **Байесовская калибровка для каждого детектора.** `keyhog calibrate --fp generic-api-key`
  записывает апостериорное распределение Beta(α,β). Сканирования используют его только когда `--calibration-cache`
  или `[system].calibration_cache` указывает на этот файл, поэтому настройка уверенности
  явная и воспроизводимая, а не зависит от случайного состояния кэша хоста.

## Производительность

Используйте воспроизводимый стенд в [`benchmarks/`](https://github.com/santhreal/keyhog/blob/main/benchmarks) для сравнения KeyHog,
Betterleaks, Kingfisher, Nosey Parker, TruffleHog и Titus по единому контракту
оценки. Стенд исключает манифест с эталонными ответами из каждого дерева сканирования.
Сгенерированные таблицы остаются пустыми, пока не существуют прогоны с текущей схемой. Запустите
`make -C benchmarks report` после измерений. Не редактируйте сгенерированные таблицы
вручную.

### Таблица лидеров по обнаружению

<!-- BENCH:leaderboard:start -->
#### Синтетический зеркальный корпус в форме SecretBench
Корпус: **mirror** — 15000 фикстур, 3000 размеченных положительных, 2 431 242 байта. Каждый сканер оценён одинаково (правило пересечения SecretBench); манифест с ключом ответов исключён из дерева сканирования.

| Ранг | Сканер | F1 | Точность | Полнота | Находки | Время | Пиковый RSS |
|---|---|---|---|---|---|---|---|
| 1 | **KeyHog** | **0.9328** | 0.9651 | 0.9027 | 2816 | 1.05s | 416 MB |
| 2 | TruffleHog | 0.5294 | 1.0000 | 0.3600 | 1080 | 1.59s | 300 MB |
| 3 | Kingfisher | 0.4683 | 0.3877 | 0.5913 | 5255 | 4.81s | 402 MB |
| 4 | Titus | 0.4207 | 0.3381 | 0.5567 | 5151 | 2.86s | 115 MB |
| 5 | Nosey Parker | 0.4186 | 0.3511 | 0.5183 | 4529 | 0.82s | 285 MB |
| 6 | Betterleaks | 0.3498 | 0.2241 | 0.7970 | 11113 | 0.74s | 198 MB |

#### Корпус правил конкурентов на их «домашнем поле»
Корпус: **homefield** — 2399 фикстур, собранных из эталонных наборов правил конкурентов (правила Betterleaks и Kingfisher; 1057 размеченных положительных, 1342 отрицательных, 772 974 байта). Кросс-инструментальная оценка на эталонных данных конкурентов.

| Ранг | Сканер | F1 | Точность | Полнота | Находки | Время | Пиковый RSS |
|---|---|---|---|---|---|---|---|
| 1 | **KeyHog** | **0.9214** | 0.9582 | 0.8874 | 979 | 0.72s | 384 MB |
| 2 | Betterleaks | 0.9056 | 0.9130 | 0.8984 | 1040 | 0.58s | 192 MB |
| 3 | Kingfisher | 0.8842 | 0.9250 | 0.8468 | 968 | 2.14s | 390 MB |
| 4 | TruffleHog | 0.4812 | 0.9850 | 0.3226 | 345 | 1.22s | 280 MB |
| 5 | Titus | 0.4635 | 0.3810 | 0.5913 | 1640 | 2.15s | 110 MB |
| 6 | Nosey Parker | 0.4520 | 0.3950 | 0.5280 | 1412 | 0.68s | 265 MB |
### Происхождение результатов

| Сканер | Версия сканера / дайджест исполняемого файла | Идентичность корпуса | Идентичность хоста | Дата запуска |
|---|---|---|---|---|
| KeyHog | версия: KeyHog v0.5.70<br>Коммит: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Набор детекторов: 926 (926-4168e2c6c93a16ca)<br>Целевая сборка: x86_64-linux<br>Версия ML-модели: moe-v1-246a05b92bec9aa3<br>Карточка ML-модели: записана 2026-07-15; признаков 55; синтетический F1 0.971 / P 0.945 / R 0.999; реальный F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; детекторов с нулевой полнотой 2/32; шестисканирующий дифференциал недоступен<br>SHA-256 исполняемого файла: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:39Z |
| TruffleHog | версия: trufflehog 3.96.0<br>SHA-256 исполняемого файла: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:58Z |
| Kingfisher | версия: kingfisher 1.94.0<br>SHA-256 исполняемого файла: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:50Z |
| Titus | версия: Titus v1.1.20 (Go-порт NoseyParker)<br>SHA-256 исполняемого файла: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:30:03Z |
| Nosey Parker | версия: noseyparker 0.24.0 Конфигурация сборки: Временная метка сборки:    2025-05-08T21:11:15.600909923Z Временная метка коммита:   2025-05-08T17:04:47.000000000-04:00 Ветка коммита:      HEAD SHA коммита:         61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Возможности Cargo:     color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Отладка:              true Оптимизация:       3 Целевая тройка:      x86_64-unknown-linux-gnu Система сборки: ОС:                 Ubuntu Версия ОС:         Linux (Ubuntu 22.04) Производитель CPU:         AuthenticAMD Марка CPU:          AMD EPYC 7763 64-Core Processor Ядер CPU:          2 Версия rustc:      1.86.0 Канал rustc:      stable Целевая тройка rustc:  x86_64-unknown-linux-gnu Дата коммита rustc:  2025-03-31 SHA коммита rustc:   05f9846f893b09a1be1fc8560e33fc3c815cfecb Версия LLVM rustc: 19.1<br>SHA-256 исполняемого файла: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:53Z |
| Betterleaks | версия: betterleaks version dev<br>SHA-256 исполняемого файла: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15 000 фикстур; 3 000 размеченных положительных; 2 431 242 байта | SHA-256/12 имени хоста: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->

### Скорость и память

<!-- BENCH:perf:start -->
#### Синтетический зеркальный корпус в форме SecretBench

| Сканер | Конфигурация | Корпус | Время | Пропускная способность | Пиковый RSS |
|---|---|---|---|---|---|
| Betterleaks | `default-nocache-nodaemon-no-validate` | mirror | 0.74s | 3.1 MB/s | 198 MB |
| Nosey Parker | `default-nocache-nodaemon-no-git-history` | mirror | 0.82s | 2.8 MB/s | 285 MB |
| KeyHog | `simd-nocache-nodaemon-full` | mirror | 1.05s | 2.2 MB/s | 416 MB |
| TruffleHog | `default-nocache-nodaemon-no-verify` | mirror | 1.59s | 1.5 MB/s | 300 MB |
| Titus | `default-nocache-nodaemon-no-validate` | mirror | 2.86s | 0.8 MB/s | 115 MB |
| Kingfisher | `default-nocache-nodaemon-low-no-validate` | mirror | 4.81s | 0.5 MB/s | 402 MB |

#### Корпус правил конкурентов на их «домашнем поле»

| Сканер | Конфигурация | Корпус | Время | Пропускная способность | Пиковый RSS |
|---|---|---|---|---|---|
| Betterleaks | `default-nocache-nodaemon-no-validate` | homefield | 0.58s | 1.3 MB/s | 192 MB |
| Nosey Parker | `default-nocache-nodaemon-no-git-history` | homefield | 0.68s | 1.1 MB/s | 265 MB |
| KeyHog | `simd-nocache-nodaemon-full` | homefield | 0.72s | 1.1 MB/s | 384 MB |
| TruffleHog | `default-nocache-nodaemon-no-verify` | homefield | 1.22s | 0.6 MB/s | 280 MB |
| Titus | `default-nocache-nodaemon-no-validate` | homefield | 2.15s | 0.4 MB/s | 110 MB |
| Kingfisher | `default-nocache-nodaemon-low-no-validate` | homefield | 2.14s | 0.4 MB/s | 390 MB |
<!-- BENCH:perf:end -->

### Сравнение полноты по категориям

<!-- BENCH:gaps:start -->
_Диагностический срез полноты. Общая точность и F1 остаются контрактом сравнения; ложные срабатывания учитываются в своих категориях оценки._

| Категория | KeyHog P/R/F1 | KeyHog TP/FN | Лучший конкурент P/R/F1 | Разрыв по полноте |
|---|---|---|---|---|
| `generic-high-entropy-string` | 1.000 / 0.434 / 0.606 | 73/95 | Betterleaks 1.000 / 0.798 / 0.887 | +0.363 |
<!-- BENCH:gaps:end -->

### Телеметрия ограниченного статического восстановления

<!-- BENCH:recovery:start -->
Выбранный прогон: сканер **KeyHog** `KeyHog v0.5.70<br>Коммит: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Набор детекторов: 926 (926-4168e2c6c93a16ca)<br>Целевая сборка: x86_64-linux<br>Версия ML-модели: moe-v1-246a05b92bec9aa3<br>Карточка ML-модели: записана 2026-07-15; признаков 55; синтетический F1 0.971 / P 0.945 / R 0.999; реальный F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; детекторов с нулевой полнотой 2/32; шестисканирующий дифференциал недоступен`; корпус **mirror** (15 000 фикстур, 2 431 242 байта); сгенерирован `2026-08-11T01:29:39Z`; артефакт `mirror-keyhog-simd-nocache-nodaemon-full.json`.

Схема телеметрии: `static-recovery-v1`.

| Статус | Точное количество |
|---|---:|
| Поддержано | 0 |
| Не поддержано | 0 |
| Ошибочно | 0 |

| Причина отклонения | Точное количество |
|---|---:|
| _нет_ | 0 |
<!-- BENCH:recovery:end -->

### Доказательства биграммного фильтра Блума

<!-- BENCH:bloom:start -->
Схема доказательств: `bloom-evidence-v1`.

| Поле | Точный результат |
|---|---|
| Корпус | `samsung-creddata-fx-record-spans-v1` |
| Ревизия корпуса | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| SHA-256 корпуса | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| SHA-256 фикстуры | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| SHA-256 исполняемого файла | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| SHA-256 корпуса детекторов рабочей области | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Дайджест детекторов сканера | `8d789251e092959f` |
| SHA-256 корпуса детекторов | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Отклонение фильтром Блума | **110/51794 (0.21%)**; 51684 принято |
| Внешняя доступность | 51794 измерено; 0 явно недоступно из 51794 объявленных; причины:  |
| Включённые и обойдённые находки | **ИДЕНТИЧНЫ**; 977/977 находок |
| SHA-256 идентичности находки | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Плотность/состояние фильтра Блума | 1793/65536 слотов; `healthy`; насыщение на 39322 |

Идентичность находки связывает детектор, файл, строку, диапазон байтов и SHA-256 учётных данных; открытые тексты учётных данных никогда не записываются.
<!-- BENCH:bloom:end -->

Воспроизведение: `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
повторно запускает точный набор прогонов KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog и
Titus на зеркальном корпусе, включая привязанный к исполняемому файлу дифференциал Bloom CredData,
`make -C benchmarks report` перегенерирует таблицы выше и
`benchmarks/reports/`. См. [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
для корпусов (mirror, домашнее поле конкурентов, Samsung/CredData) и
матрицы бэкенд/кэш/демон/ОС/GPU.

## Массовые фоновые рабочие процессы с поддержкой GPU

Необязательный массовый Unix-демон поддерживает один скомпилированный сканер и его калиброванное
состояние бэкенда в тёплом виде. Сканирование локальной файловой системы отправляет только канонический корневой
и исходно-политический метаданные; демон читает и пакетирует файлы в собственном
процессе. Источники Git, бинарные, удалённые и облачные, требующие учётных данных
на стороне клиента, используют защищённые ограниченные кадры блоков.```sh
# Terminal 1
keyhog calibrate-autoroute --policy default
keyhog daemon start --mass

# Terminal 2, after the daemon prints its ready line
keyhog scan --daemon=mass /srv/inventory/team-a \
  --format json-envelope --output team-a.json
keyhog daemon stop

`scan-system` — это ограниченный локальный аудит хоста, а не замена репозиторию или
облачному разбиению инвентаря. Он ограничивает себя общим количеством просканированных байт, а не
путём: `--space` — это потолок, а сетевые файловые системы
пропускаются, если вы не передадите `--include-network`. Проверьте поведение монтирования, сетевых файловых систем,
потолка пространства и привилегий перед запуском. См.
[системный триаж](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).

## Ограничение чувствительных локальных сканов

`--lockdown` в Linux — это режим защиты процессов с отказом по умолчанию (fail-closed):```sh
keyhog scan . --daemon=off --lockdown

Методы библиотеки по умолчанию являются детерминированными переносимыми ссылками на CPU. Явные
методы бэкенда возвращают типизированные ошибки вместо завершения процесса или
молчаливой подстановки другого движка. Сырые фрагменты и совпадения могут содержать
открытый текст. Преобразуйте их с помощью `RawMatch::to_redacted` или используйте итоговые
значения `VerifiedFinding` перед границами JSON, журналов, диска или сети.

[Руководство по архитектуре](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) определяет владение крейтами,
контракты бэкендов, квитанции восстановления, вспомогательные функции источников и безопасные
границы отчетности. Документация Rust на уровне крейтов содержит полный API.

## Настройка политики с явным приоритетом

Политика репозитория хранится в `.keyhog.toml`:```toml
verify = false

[scan]
severity = "high"
incremental = true

[system]
gpu = "auto"

Определения детекторов остаются данными в `detectors/`. `keyhog-core` владеет
типами детекторов и находок, `keyhog-scanner` владеет бэкендами сопоставления и
исполнения, `keyhog-sources` владеет получением входных данных, `keyhog-verifier` владеет
живыми проверками, а `keyhog-cli` владеет рабочими процессами оператора.

Начните с [руководства по архитектуре](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) для карты
репозитория, направления зависимостей, конвейера «байты → находки», владения маршрутизацией и
точек входа для профилирования.

## Проверьте и расширьте установку```sh
keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh