keyhog

<p align="center">
  <img src="https://raw.githubusercontent.com/santhreal/keyhog/HEAD/docs/assets/keyhog-banner.svg" alt="KeyHog scanner de segredos open-source acelerado por GPU para código, histórico Git, nuvem, contêineres, ativos de navegador e CI" width="960" />
</p>

<p align="center">
  <a href="https://crates.io/crates/keyhog"><img src="https://img.shields.io/crates/v/keyhog?style=flat-square&amp;color=ffd60a&amp;label=crates.io&amp;labelColor=0a0a0a" alt="KeyHog no crates.io" /></a>&nbsp;
  <a href="https://santhreal.github.io/keyhog/"><img src="https://img.shields.io/badge/docs-KeyHog-ffd60a?style=flat-square&amp;labelColor=0a0a0a" alt="Documentação do KeyHog" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/actions"><img src="https://img.shields.io/github/actions/workflow/status/santhreal/keyhog/ci.yml?style=flat-square&amp;label=CI&amp;labelColor=0a0a0a" alt="CI" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-MIT%20OR%20Apache--2.0-9aa0b4?style=flat-square&amp;labelColor=0a0a0a" alt="MIT OR Apache-2.0" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/blob/main/metrics/stars.svg"><img src="https://img.shields.io/github/stars/santhreal/keyhog?style=flat-square&amp;color=ffd60a&amp;label=stars&amp;labelColor=0a0a0a" alt="Estrelas do GitHub e histórico de estrelas de propriedade do repositório" /></a>
</p>

<p align="center">
  <strong><a href="https://santh.dev/keyhog/">Site</a></strong> ·
  <strong><a href="https://santhreal.github.io/keyhog/">Documentação</a></strong> ·
  <strong><a href="https://santh.dev/blog/keyhog/">Arquitetura</a></strong> ·
  <strong><a href="https://github.com/santhreal/vyre">Mecanismo GPU Vyre</a></strong>
</p>

# KeyHog: scanner de segredos acelerado por GPU para código, nuvem e CI

**KeyHog é um scanner de segredos open-source em Rust que encontra e verifica
chaves de API, tokens, senhas e credenciais vazadas em código-fonte, histórico
Git, contêineres, armazenamento em nuvem, ativos de navegador, conteúdo de
colaboração e sistemas em execução.**

A maioria dos scanners de segredos para em correspondências de regex na CPU em um checkout de repositório.
O KeyHog combina **934 detectores específicos por serviço**, decodificação para
credenciais ocultas, evidência e supressão sensíveis ao contexto, verificação
ao vivo com provedores e execução de primeira classe em **CUDA, Metal e WGPU
através do [Vyre](https://github.com/santhreal/vyre)**. A calibração mede cada
backend elegível de CPU pura em Rust, Hyperscan/SIMD e GPU. O roteamento
automático então usa a rota mais rápida comprovada por paridade para o host e a
classe de carga de trabalho exatos.

| GPU é um backend real | Examine a superfície de ataque real | Separe o sinal do ruído | Aja sobre o resultado |
|---|---|---|---|
| CUDA, Metal nativo e WGPU são pares medidos, não uma cadeia de fallback silenciosa. | Examine histórico Git, camadas Docker, arquivos, buckets em nuvem, source maps, WASM, capturas HAR, coleções Git hospedadas e sistemas inteiros. | Decodifique base64, hex, URL, protobuf, multiline e configuração estruturada antes de aplicar evidência, supressão de exemplos e linhas de base. | Verifique credenciais elegíveis com APIs de provedores, emita SARIF ou envelopes estruturados e preserve cobertura exata e semântica de saída. |```sh
cargo install --locked keyhog
keyhog scan .
```
<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="Digitalização do KeyHog mostrando gravidade, evidência, arquivo e linha, correção, resultados e estado de cobertura" width="900" />
</p>

## Um scanner de segredos construído em torno da GPU

O KeyHog não entrega algumas expressões regulares a um compute shader genérico.
Seu caminho de GPU é construído sobre o [Vyre](https://github.com/santhreal/vyre), um
substrato de computação GPU em Rust desenvolvido em conjunto com o KeyHog. Os gatilhos
dos detectores são compilados em tabelas imutáveis residentes na GPU. Lotes de
origem limitados produzem posições de correspondência completas para o mesmo pipeline
de confirmação, supressão, evidência e relatório usado pelas rotas de CPU e Hyperscan.

- **Três peers físicos de GPU.** CUDA, Metal nativo e WGPU portátil são
  adquiridos, medidos e relatados de forma independente.
- **Paridade exata de resultados.** A calibração rejeita um candidato cuja
  identidade de descoberta difere da rota de referência. Uma resposta errada mais
  rápida nunca entra na tabela de roteamento.
- **Evidência persistente de rota.** O KeyHog registra o binário, o corpus de
  detectores, a configuração, a classe de carga de trabalho, o host, o acelerador,
  o driver e as evidências de tempo medidas. Digitalizações normais não fazem
  benchmark no caminho crítico.
- **Execução residente.** Workers daemon mantêm o estado compilado de detectores e
  aceleradores aquecido para lotes repetidos de arquivos, arquivos compactados,
  histórico, remotos e de nuvem.
- **Sem escotilha de escape oculta para CPU.** Um acelerador explicitamente
  selecionado que não consegue inicializar ou despachar falha visivelmente em vez de
  retornar descobertas de CPU sob um rótulo de GPU.

A instalação padrão do crates.io usa a rota de CPU pura em Rust portátil para que
funcione em um host Rust limpo. Ative os três peers de GPU sem adquirir o Hyperscan:```sh
cargo install --locked keyhog --no-default-features --features portable,gpu
```
Ative o peer de regex SIMD Hyperscan ou Vectorscan:```sh
cargo install --locked keyhog --no-default-features --features portable,simd
```
Execute o diagnóstico do backend de produção e, em seguida, inspecione a rota medida:```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
```
O [guia de backend](https://santhreal.github.io/keyhog/backends.html) documenta
as tabelas residentes, o modelo de despacho limitado, o contrato de paridade e as
evidências reproduzíveis de crossover.

## Comece por aqui

### Instale e execute sua primeira varredura

Os dois comandos acima instalam a versão mais recente do crates.io e varrem a
árvore atual com a rota portátil puramente em Rust.

Fixar um ambiente de CI a uma versão exata com
`cargo install --locked --version '=0.5.86' keyhog`. O KeyHog requer Rust 1.89
ou mais recente. Consulte o [guia de instalação](https://santhreal.github.io/keyhog/install.html)
para perfis de GPU, Hyperscan, CI, portátil e compilação a partir do código-fonte.

O KeyHog sai com código `1` quando uma descoberta bloqueia a política de evidências ativa. A política
padrão bloqueia descobertas `likely` e `confirmed`, mantendo descobertas `review`
visíveis com saída `0`; `--evidence-policy paranoid` bloqueia todas as camadas. Revise
a camada de evidência exata, o código de motivo, o arquivo, a linha, o detector e a
remediação de cada descoberta. Outros códigos diferentes de zero descrevem falhas de entrada, sistema, verificação ou
cobertura; consulte a
[referência de códigos de saída](https://santhreal.github.io/keyhog/reference/exit-codes.html).

O contrato completo do processo é:

| Saída | Significado |
|---|---|
| `0` sucesso | Nenhuma descoberta bloqueia a política de evidências ativa e nenhuma falha de cobertura ocorreu. Descobertas de camada de revisão podem permanecer visíveis sob a política padrão. |
| `1` descobertas bloqueantes | Pelo menos uma descoberta bloqueia a política de evidências ativa, mas nenhuma foi confirmada como ativa. |
| `2` erro do operador | Corrija os argumentos, a configuração, o corpus de detectores ou a entrada corrigível pelo operador. |
| `3` erro do sistema | Repare ou tente novamente o executor. Isso inclui E/S de baixo nível, serviço de daemon fatal, cache incremental e falhas de SIMD explicitamente selecionadas. |
| `4` falha de saúde/autoteste | Uma verificação de saúde `doctor` ou `backend --self-test` não estava saudável. |
| `10` credenciais ativas | Pelo menos uma credencial foi confirmada como ativa. |
| `11` pânico do scanner | Descarte o resultado da varredura porque o estado do scanner não é confiável. |
| `12` falha de GPU obrigatória | Um caminho de GPU explicitamente selecionado ou obrigatório não pôde ser executado. |
| `13` cobertura incompleta | Uma fonte solicitada falhou ou a cobertura de entrada estava incompleta, e nenhum resultado de descoberta teve precedência. |
| `130` interrompido | SIGINT ou Ctrl-C interrompeu o processo. |

**Filtrar, formatar, bloquear:**

Crie uma linha de base antes de usá-la como filtro:```sh
keyhog scan . --create-baseline .keyhog-baseline.json
keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json
```
O primeiro comando captura os achados revisados e sai com código `0` sem imprimi-los.
Faça o commit desse arquivo e, em seguida, use o segundo comando para relatar apenas as novas identidades de achados. Uma entrada de linha de base corresponde ao detector e ao valor da credencial, nunca ao caminho do arquivo, portanto, mover um segredo registrado não reprova a verificação, mas rotacioná-lo reprova. Credenciais alteradas e cobertura incompleta permanecem visíveis. O caminho completo, incluindo partições de monorepo, está em [Falhar apenas em novos segredos](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets).

Para a próxima varredura, use o [livro de receitas](https://santhreal.github.io/keyhog/recipes.html) ou os comandos copiáveis em [Escolha o fluxo de trabalho certo](#choose-the-right-workflow). Você pode verificar o histórico do Git, imagens de contêineres, buckets na nuvem, coleções de repositórios, URLs e uma máquina inteira sem trocar de ferramentas.

### Proteja repositórios para varreduras rápidas de pré-commit

Registre um repositório com o daemon perpétuo do KeyHog para detecção rápida de segredos no pré-commit (requer Unix; no Windows, use `keyhog scan` em processo):```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
```
Consulte o [guia de guarda perpétua](https://santhreal.github.io/keyhog/workflows/guard.html)
e o [fluxo de trabalho de pre-commit](https://santhreal.github.io/keyhog/workflows/precommit.html)
para configuração completa, ciclo de vida da máquina de estados e automação de hooks.

### Adicione-o ao GitHub Actions

Crie `.github/workflows/keyhog.yml`:```yaml
name: keyhog
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
  security-events: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: santhreal/keyhog@v0
        with:
          path: .
          severity: high
```
A ação verifica a árvore de trabalho, falha em achados de nível `high` ou `critical`, envia SARIF para o Code Scanning e mantém o relatório como artefato do workflow. Falhas de instalação, cobertura, backend e publicação do relatório também fazem o job falhar.

Use o [guia do GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) para entradas, saídas, adoção de baseline, partições de monorepo, verificação e comportamento de falha. Use o [guia de CI](https://santhreal.github.io/keyhog/workflows/ci.html) para GitLab, CircleCI, Jenkins, Buildkite e jobs shell genéricos. Use o [guia de varredura em massa](https://santhreal.github.io/keyhog/guides/mass-scanning.html) para organizações de repositórios, grupos Git hospedados, buckets em nuvem e inventários particionados.

## Superfícies de varredura que outras ferramentas tratam como produtos separados

O KeyHog varre bytes na fronteira onde podem vazar, não apenas arquivos de origem rastreados. Use um relatório por fronteira para que a CI retenha cobertura e estado de falha exatos.

| Superfície de exposição | Exemplo |
|---|---|
| Artefato final do pacote | Execute `npm pack` e depois varra o `.tgz` gerado com `keyhog scan package.tgz`. A expansão do arquivo verifica arquivos gerados, source maps, fixtures e metadados ausentes na árvore de origem esperada. |
| Aplicação de navegador implantada | `keyhog scan --url https://app.example.com/assets/app.js` segue decodificação limitada de JavaScript, source-map, WASM e resposta sem transformar o scanner em um crawler ilimitado. |
| Issues, pull requests, discussões, wikis e gists do GitHub | `keyhog scan --github-collaboration owner/repo --github-all` varre toda superfície de colaboração fora do checkout. |
| Configuração de agente de IA e MCP | `keyhog scan ~/.config ~/.claude ~/.codex` aplica o mesmo pipeline de detector, decodificação, evidência e relatório à configuração local de ferramentas. |
| Camadas de imagem de contêiner | `keyhog scan --docker-image registry.example.com/team/app:v1` varre o conteúdo da imagem que será executado, incluindo arquivos introduzidos durante o build. |
| Inventários de objetos em nuvem | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` ou `--azure-container-url URL` preserva paginação do provedor, objeto e limites de bytes no relatório do terminal. |
| Host de desenvolvimento inteiro | `sudo keyhog scan-system --space 50G` descobre sistemas de arquivos montados e histórico Git alcançável sob um orçamento rígido de armazenamento. |

Essas rotas compartilham um único contrato de detecção e relatório. Uma falha específica de fonte não pode silenciosamente se transformar em uma varredura local mais estreita.

## Escolha o workflow certo

Escolha a fronteira da fonte primeiro. Um preset muda o trabalho de detecção, enquanto um backend muda a execução. Nenhum deles expande uma varredura da árvore de trabalho para histórico Git, inventário de provedor, armazenamento em nuvem ou auditoria de host.

Não existe um atalho honesto de `scan everything`. Uma revisão completa do patrimônio executa as fronteiras relevantes abaixo como jobs separados e retém cada relatório `json-envelope` com seu código de saída bruto.

| Necessidade | Comece com | Throughput e reuso | Fronteira de cobertura |
|---|---|---|---|
| Feedback local rápido | `keyhog scan . --fast --incremental` | Reusa hashes de arquivos inalterados. O preset fast pula trabalho de decodificação, entropia e ML. | Execute a política padrão antes do merge porque fast é intencionalmente mais estreito. |
| Varredura completa do repositório | `keyhog scan .` | `auto` calibrado e o padrão de workers por núcleo de CPU. Adicione `--incremental` para varreduras repetidas da mesma árvore confiável. | Apenas arquivos atuais. Não adiciona histórico Git. |
| Gate de commit em estágio | `keyhog scan --git-staged` ou `keyhog hook install` | Lê blobs exatos do index, então edições não encenadas não podem alterar o resultado. | Apenas conteúdo encenado. Execute uma varredura da árvore de trabalho separadamente quando bytes locais não encenados importam. |
| Guarda perpétua do repositório | `keyhog guard add . --mode repo` e depois `keyhog guard status .` | Registro raiz residente em daemon com máquina de 7 estados, cache de atestação limpo e rastreamento de identidade de política. | Requer daemon em execução. A guarda complementa, não substitui, varreduras encenadas e da árvore de trabalho. |
| Gate de pull request do GitHub | `santhreal/keyhog@v0` | A Action instala, varre, publica SARIF e um artefato e preserva o status do KeyHog. | Um caminho de checkout. Use varredura de inventário de provedor para uma organização. |
| GitLab, Jenkins, Buildkite ou shell CI | `keyhog scan . --format json-envelope --output keyhog.json` | Persista o relatório e o código de saída em sucesso, achados e erros. Use `--git-diff <base>` apenas para um gate de linhas alteradas explicitamente mais estreito. | Os bytes presentes no checkout ou o diff selecionado. |
| Adotar um repositório com achados conhecidos | Crie `.keyhog-baseline.json`, faça commit e depois varra com `--baseline .keyhog-baseline.json`. | Identidades existentes permanecem visíveis no baseline enquanto apenas novos achados fazem o gate falhar. | Um baseline não suprime credenciais alteradas ou cobertura incompleta. |
| Recuperação recursiva de Git | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | Calibre a política deep uma vez por classe de worker. Execute em processo. | Um repositório. `--git-history` cobre apenas a ancestralidade do checkout atual, então uma branch que você nunca fez checkout é perdida sem lacuna de cobertura; `--git-blobs` também alcança blobs órfãos, commits removidos por amend, stashes, notas, mensagens de tags anotadas e refs empacotadas. |
| Inspeção de contêiner ou arquivo | `keyhog scan --docker-image registry/app:v1` ou `keyhog scan incoming/` | Mantenha um relatório envelope para que membros pulados, corrompidos, criptografados, inseguros ou superdimensionados permaneçam visíveis. | Apenas a imagem ou caminho de sistema de arquivos selecionado e formatos aninhados suportados. |
| Inspeção de URL, resposta ou HAR | `keyhog scan --url https://api.example.com/config` ou `keyhog scan capture.har` | Use limites de fonte limitados e preserve o envelope do terminal. | Apenas respostas buscadas ou entradas de captura. Isso não é um crawler. |
| Inventário de organização ou nuvem | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | Particione por provedor, proprietário ou bucket. Execute partições independentes concorrentemente com um relatório e status cada. | Um inventário de provedor selecionado por job. Limites de paginação ou objetos permanecem fronteiras de cobertura. |
| Confirmar se achados elegíveis estão ativos | `keyhog scan . --verify` | Concorrência e controles de taxa do provedor são separados dos workers do scanner. | Envia requisições derivadas de credenciais a endpoints declarados do provedor. Nem todo detector suporta verificação. |
| Varredura de saúde do host inteiro | `sudo keyhog scan-system --space 50G` | Usa todos os núcleos de CPU por padrão e varre histórico Git descoberto após dados do sistema de arquivos. | Sistemas de arquivos montados localmente. Montagens de rede são opt-in e o teto de espaço é rígido. |
| Diretório, histórico, arquivo, remoto ou inventário em nuvem com GPU no Unix | Calibre a autoroute, inicie `keyhog daemon start --mass` e depois execute `keyhog scan --daemon=mass <SOURCE>`. | Transmite lotes limitados por um worker compilado de CPU, Hyperscan, CUDA, Metal ou WGPU. Adicione `--incremental` para árvores de sistema de arquivos inalteradas e quentes. O recibo do terminal relata totais exatos e lotes de GPU, chunks, bytes, participação de GPU e throughput. | Baselines, verificação, lockdown, presets, overlays e outras mudanças de política do scanner são rejeitados antes da aquisição. Estado incremental aplica-se apenas a raízes de sistema de arquivos locais do daemon. |

### Varra toda fronteira de fonte suportada

Use um comando por fronteira. Mantenha um relatório `json-envelope` e o status de saída bruto para cada partição de inventário.

| Fonte ou caso de uso | Comando |
|---|---|
| Várias raízes locais | `keyhog scan services/api services/web deploy/` |
| Arquivos alterados continuamente | `keyhog watch services/api deploy/` |
| Bytes encenados, linhas alteradas, histórico alcançável ou blobs | `keyhog scan --git-staged`, `--git-diff main`, `--git-history .` ou `--git-blobs .` |
| Binários nativos e strings de firmware | `keyhog scan --binary firmware.bin` (uma varredura de diretório simples pula binários e ainda sai com `0`) |
| Arquivos e fontes compactadas | `keyhog scan incoming/` (membros suportados expandem automaticamente) |
| Camadas de imagem Docker | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, source maps, WASM ou resposta de endpoint | `keyhog scan --url https://api.example.com/config` |
| Capturas de requisição e resposta HTTP | `keyhog scan capture.har` |
| Issues, pull requests, discussões, wikis e gists do GitHub | `keyhog scan --github-collaboration owner/repo --github-all` |
| Inventários GitHub, GitLab ou Bitbucket | `--github-org ORG`, `--gitlab-group GROUP` ou `--bitbucket-workspace WORKSPACE` |
| Inventários S3, GCS ou Azure Blob | `--s3-bucket BUCKET`, `--gcs-bucket BUCKET` ou `--azure-container-url URL` |
| Um fluxo limitado de outra ferramenta | `producer \| keyhog scan --stdin` (use `set -o pipefail` para que um produtor com falha exponha seu próprio erro, não uma varredura de zero bytes) |

Uma varredura de diretório simples não lê binários nativos. Cada um se torna uma lacuna de cobertura `binary (extension or content sniff)`, a varredura ainda sai com `0` e `--no-default-excludes` não muda isso, então passe `--binary` quando artefatos compilados estiverem no escopo. Essa flag precisa de um build com o recurso `binary`, que a instalação padrão do crates.io tem e o recurso enxuto `ci` não tem.

A extração de binários nativos relata credenciais completas que satisfazem o contrato explícito de forma de um detector nomeado. Ela suprime fragmentos curtos de prefixo e strings genéricas em forma de atribuição de seções de dados compilados porque esses bytes não retêm contexto de origem.

A busca de endpoints é limitada e protegida contra SSRF. Não é um crawler. Endpoints privados em nuvem e encaminhamento de credenciais exigem suas flags explícitas de confiança. Tokens de provedor pertencem às variáveis de ambiente documentadas, não a argumentos de processo.

Use o [seletor de workflow](https://santhreal.github.io/keyhog/capabilities.html) para detalhes de fonte e política, o [guia do GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) para o gate de repositório mantido, o [guia de CI direto](https://santhreal.github.io/keyhog/workflows/ci.html) para relatórios duráveis e tratamento de saída, e o [guia de varredura em massa](https://santhreal.github.io/keyhog/guides/mass-scanning.html) para particionamento e agregação. O [livro de receitas](https://santhreal.github.io/keyhog/recipes.html) cobre contêineres, arquivos, URLs, conteúdo de colaboração do GitHub e fontes em nuvem.

### Velocidade e concorrência sem adivinhação

Comece com os padrões. O Cargo não pode executar o KeyHog após `cargo install`, então execute os comandos abaixo uma vez após instalar um build Cargo multi-backend e novamente após o host, binário, corpus de detectores, driver ou classes de carga de trabalho mudarem:```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
```
| Control | Use para | Mantenha este invariante |
|---|---|---|
| `--backend auto` calibrado | CPU, Hyperscan ou seleção de GPU de rotina. | Um backend explícito é uma substituição de diagnóstico, não um padrão mais rápido. |
| `--threads <N>` | Reservar capacidade de CPU em um runner compartilhado. Hosts dedicados normalmente devem deixá-lo desdefinido para que o KeyHog use os núcleos disponíveis. | Todo valor deve ser positivo. Vários processos KeyHog concorrentes possuem cada um um pool de workers, então divida o orçamento do host entre as partições. |
| `--reader-threads <N>` | Pipelines de armazenamento medidos onde o trabalho do leitor, não a varredura, é o gargalo. | O padrão deriva do pool de workers de varredura. Deixe-o desdefinido até que a criação de perfil mostre um gargalo no leitor. |
| `--incremental` e `--incremental-cache <PATH>` | Varreduras repetidas da mesma árvore confiável. | Não compartilhe um índice entre repositórios não relacionados ou jobs não confiáveis. |
| Partições de provedor ou repositório | Varredura concorrente do patrimônio e novas tentativas independentes. | Preserve um envelope de terminal e código de saída bruto por partição. Não concatene descobertas e descarte o estado de cobertura. |
| `--verify-concurrency`, `--verify-rate` e `--verify-batch` | Limitar verificações ao vivo do provedor independentemente da varredura de arquivos. | A verificação envia solicitações derivadas de credenciais. Os limites de taxa do provedor, não a contagem de CPU, controlam essa concorrência. |
| Daemon em massa | Fluxos de diretório, histórico, arquivo, remoto ou nuvem em escala de TB em um único worker Unix. | Cada quadro é limitado a 8 MiB e 1.024 chunks. O daemon serializa o estado do fragmento e retorna um recibo exato de execução CPU/GPU. |
| `--fast`, padrão, `--deep` ou `--precision` | Selecionar uma política explícita de custo de detecção e recall. | Esses predefinidos são mutuamente exclusivos e alteram a cobertura. Não são botões de velocidade intercambiáveis. |

Inspecione a política resolvida com `keyhog config --effective`. Use `--profile`
para medir estágios fixos do scanner e a execução completa do operador antes de alterar
os controles de leitor, lote ou profundidade de canal. O relatório de baixa sobrecarga registra
fonte, backend, cache, carga de trabalho, thread, entrada, transição de estado, tempo de CPU,
pico de memória, SHA-256 exato do binário, SHA-256 de recursos habilitados, triple de destino, perfil de
build, compilador, alocador, SHA-256 do backend vinculado, SHA-256 do corpus do detector,
BLAKE3 do detector habilitado, BLAKE3 do plano compilado, proveniência do detector com hash,
BLAKE3 da configuração resolvida completa, BLAKE3 da política de desempenho, predefinido,
estado de proteção aplicado, adaptadores de fonte, BLAKE3 do alvo de fonte com hash,
BLAKE3 da partição de fonte com hash, bytes brutos da fonte, fanout da unidade de fonte,
bytes derivados da decodificação, bytes concluídos do despacho do backend e buckets estáveis de tamanho/fanout.
Domínios de bytes que seu adaptador de fonte ainda não consegue distinguir permanecem
explicitamente indisponíveis em vez de se tornarem zeros medidos. O relatório não
registra conteúdo da fonte, valores de credenciais, caminhos brutos, URLs brutos ou valores brutos de
configuração. Use `--perf-trace` apenas para contadores de diagnóstico caros por padrão e por backend.
Mantenha os controles avançados de pipeline desdefinidos, a menos que uma medição reproduzível no
worker de destino mostre uma melhoria.

Para uma varredura recorrente completa do repositório:```sh
keyhog scan . --incremental \
  --format json-envelope --output keyhog.json
```
Para um runner compartilhado onde o job recebe quatro workers de scanner e um
worker de leitor:```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json
```
O segundo comando é um orçamento de recursos, não um ótimo universal. Meça o
host de destino antes de escolher contagens explícitas de workers.

Para [recuperação profunda](https://santhreal.github.io/keyhog/guides/deep-recovery.html)
e [triagem em todo o sistema](https://santhreal.github.io/keyhog/guides/system-wide-triage.html),
use os guias dedicados, pois a cobertura e as regras de conclusão deles diferem
de uma varredura normal de repositório.

## Benchmarks do scanner de segredos

Estes painéis comparam a política de detecção, solicitações de execução de CPU e GPU,
comportamento do cache incremental e solicitações de daemon aquecido. Cada valor é gerado
a partir do snapshot de benchmark verificado. O snapshot vincula a versão do scanner,
o digest do executável, o digest do detector, o corpus, o host e o timestamp da execução. Use a
[evidência completa do benchmark](#performance) para a proveniência dos concorrentes e
a revocação por categoria.

### Precisão de detecção

<!-- BENCH:accuracy:start -->
O KeyHog `KeyHog v0.5.70` escaneou o corpus **mirror**: 15.000 fixtures, 3.000 positivos rotulados e 2.431.242 bytes de entrada. O manifesto do gabarito de respostas foi excluído da árvore de varredura. A linha usa a política padrão na rota explícita Hyperscan/SIMD em **AMD Ryzen 9 9950X 16-Core Processor**.

| Precisão | Revocação | F1 | Verdadeiros positivos | Falsos positivos | Falsos negativos |
|---:|---:|---:|---:|---:|---:|
| 0.9651 | 0.9027 | 0.9328 | 2.708 | 98 | 292 |

A árvore de origem rastreada estava limpa.
<!-- BENCH:accuracy:end -->

### Rotas de execução, predefinições e cache

<!-- BENCH:config:start -->
Medido em **AMD Ryzen 9 9950X 16-Core Processor** com **NVIDIA GeForce RTX 5090**, 32 núcleos lógicos, 15.000 fixtures, 3.000 positivos rotulados e 2.431.242 bytes de entrada. Scanner: `KeyHog v0.5.70`. A árvore de origem rastreada estava limpa.

#### Varredura completa por rota de execução

Todas as linhas usam a política de detecção padrão com cache incremental e daemon desativado. A linha automática registra a política solicitada, mas o resultado do benchmark não vincula a rota persistida selecionada, portanto não é prova de roteamento. As linhas de GPU incluem aquisição e inicialização completa do scanner neste pequeno corpus; elas não são medições de crossover de kernel de GPU.

| Rota solicitada | Wall | Throughput | Pico de RSS | F1 |
|---|---:|---:|---:|---:|
| Hyperscan/SIMD | 860 ms | 2,70 MB/s | 416 MiB | 0.9328 |
| CPU Pure-Rust | 903 ms | 2,57 MB/s | 509 MiB | 0.9328 |
| CUDA | 2,03 s | 1,14 MB/s | 963 MiB | 0.9328 |
| WGPU | 1,97 s | 1,18 MB/s | 1264 MiB | 0.9328 |
| Automática | 1,46 s | 1,59 MB/s | 634 MiB | 0.9328 |

#### Política de detecção em Hyperscan/SIMD

A rota, o cache, o estado do daemon, o corpus e o host permanecem fixos. As predefinições alteram o trabalho de detecção, portanto compare precisão e revocação além do tempo.

| Política | Wall | Precisão | Revocação | F1 | Descobertas |
|---|---:|---:|---:|---:|---:|
| Rápida | 737 ms | 0.9700 | 0.8837 | 0.9248 | 2.738 |
| Padrão | 860 ms | 0.9651 | 0.9027 | 0.9328 | 2.816 |
| Profunda | 861 ms | 0.9645 | 0.9067 | 0.9347 | 2.845 |
| Precisão | 849 ms | 0.9590 | 0.6397 | 0.7674 | 2.001 |

#### Reexecução incremental aquecida

O benchmark popula o índice Merkle BLAKE3 e, em seguida, cronometra a segunda varredura idêntica. A pequena árvore sintética muda pouco porque a inicialização do scanner domina; meça seu repositório antes de reivindicar aceleração.

| Política padrão Hyperscan/SIMD | Wall | Throughput | Pico de RSS |
|---|---:|---:|---:|
| Cache desativado | 860 ms | 2,70 MB/s | 416 MiB |
| Cache incremental aquecido | 617 ms | 3,76 MB/s | 457 MiB |
<!-- BENCH:config:end -->

### Solicitações de daemon aquecido

<!-- BENCH:daemon:start -->
Um arquivo regular determinístico de 8 MiB (`sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5`) foi escaneado uma vez no processo e uma vez por meio de um daemon próprio após uma solicitação de aquecimento. O tempo do daemon é a solicitação do cliente; o RSS do daemon pertence ao servidor residente.

| Rota explícita | No processo | Daemon aquecido | Aquecido / one-shot | RSS no processo | RSS do daemon |
|---|---:|---:|---:|---:|---:|
| Hyperscan/SIMD | 323 ms | 106 ms | 0,33× | 63 MiB | 74 MiB |
| CPU Pure-Rust | 278 ms | 109 ms | 0,39× | 62 MiB | 66 MiB |
| CUDA | 1,65 s | 232 ms | 0,14× | 674 MiB | 666 MiB |
| WGPU | 1,33 s | 237 ms | 0,18× | 596 MiB | 600 MiB |

Estas linhas cobrem a rota de arquivo único aquecida. A rota de massa também aceita lotes limitados de diretório e de origem remota; seu caminho de sistema de arquivos incremental é medido separadamente.
<!-- BENCH:daemon:end -->
<!-- BENCH:scaling:BEGIN -->
### Escalonamento de CPU, leitor, armazenamento, tamanho e partição

---

[Read more](https://github.com/santhreal/keyhog)