Scanner de segredos de código aberto em Rust
Site · Documentação · Arquitetura · Mecanismo GPU Vyre
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. 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. |
| 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 documenta as tabelas residentes, o modelo de despacho limitado, o contrato de paridade e as evidências reproduzíveis de crossover.
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
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.
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 e o fluxo de trabalho de pre-commit para configuração completa, ciclo de vida da máquina de estados e automação de hooks.
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 e triagem em todo o sistema, use os guias dedicados, pois a cobertura e as regras de conclusão deles diferem de uma varredura normal de repositório.
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 para a proveniência dos concorrentes e a revocação por categoria.
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.
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.
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 |
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 |
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 |
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.
Gerado por make -C benchmarks readme-scaling a partir de benchmarks/reports/readme-scaling.json. O harness executou 3 tentativas medidas após 1 aquecimento com roteamento explícito simd e daemon desativado. O escalonamento de workers usa um cache de página de cliente aquecido para isolar o trabalho de CPU. As linhas de leitor, tamanho de corpus, armazenamento e partição solicitam evicção de página limpa com posix_fadvise onde a plataforma suporta; o snapshot registra a política em cada linha. Cada carga de trabalho é determinística em bytes e livre de descobertas.
Host: AMD Ryzen 9 9950X 16-Core Processor, 32 núcleos lógicos efetivos, 94.140 MiB de RAM, Linux 6.17.0-19-generic. Evidência: clean, binário 274b045489c4.
| Workers | Threads de leitor | Wall mediano | Wall p95 | Throughput | Speedup | Eficiência | Pico de RSS mediano |
|---|---|---|---|---|---|---|---|
| 1 | auto | 8.134,4 ms | 8.135,4 ms | 7,9 MiB/s | 1,00x | 100,0% | 47,0 MiB |
| 2 | auto | 4.398,2 ms | 6.906,7 ms | 14,6 MiB/s | 1,85x | 92,5% | 50,3 MiB |
| 4 | auto | 2.392,6 ms | 6.245,2 ms | 26,7 MiB/s | 3,40x | 85,0% | 57,2 MiB |
| 8 | auto | 1.816,3 ms | 6.117,6 ms | 35,2 MiB/s | 4,48x | 56,0% | 63,4 MiB |
| 16 | auto | 1.428,5 ms | 6.867,7 ms | 44,8 MiB/s | 5,69x | 35,6% | 78,4 MiB |
| 32 | auto | 1.862,8 ms | 5.939,1 ms | 34,4 MiB/s | 4,37x | 13,6% | 126,7 MiB |
| Workers de varredura | Threads de leitor | Wall mediano | Wall p95 | Throughput | Relativo a 1 leitor | Pico de RSS mediano |
|---|---|---|---|---|---|---|
| 32 | 1 | 1.898,7 ms | 1.922,1 ms | 33,7 MiB/s | 1,00x | 121,3 MiB |
| 32 | 2 | 1.881,7 ms | 1.887,5 ms | 34,0 MiB/s | 1,01x | 122,8 MiB |
| 32 | 4 | 1.874,2 ms | 1.891,2 ms | 34,1 MiB/s | 1,01x | 126,6 MiB |
| 32 | 8 | 1.873,2 ms | 1.885,7 ms | 34,2 MiB/s | 1,01x | 133,4 MiB |
| 32 | 16 | 1.856,8 ms | 1.868,5 ms | 34,5 MiB/s | 1,02x | 153,9 MiB |
| 32 | 32 | 1.877,3 ms | 1.880,4 ms | 34,1 MiB/s | 1,01x | 179,5 MiB |
| Corpus | Arquivos | Bytes exatos | Wall mediano | Wall p95 | Throughput | Pico de RSS mediano |
|---|---|---|---|---|---|---|
| pequeno | 256 | 8 MiB | 869,9 ms | 886,1 ms | 9,2 MiB/s | 111,1 MiB |
| médio | 1.024 | 64 MiB | 1.859,9 ms | 1.874,8 ms | 34,4 MiB/s | 126,3 MiB |
| grande | 2.048 | 256 MiB | 5.214,9 ms | 5.321,7 ms | 49,1 MiB/s | 137,1 MiB |
| Classe de armazenamento | Sistema de arquivos | ID do dispositivo | Wall mediano | Wall p95 | Throughput | Relativo ao primeiro armazenamento | Pico de RSS mediano |
|---|---|---|---|---|---|---|---|
| workspace | ext4 | 66305 | 1.847,4 ms | 1.863,4 ms | 34,6 MiB/s | 1,00x | 127,0 MiB |
| local-temp | tmpfs | 116 | 1.870,8 ms | 1.887,3 ms | 34,2 MiB/s | 0,99x | 124,9 MiB |
| Processos | Workers por processo | Workers agregados | Arquivos totais | Bytes totais | Wall mediano | Throughput agregado | Speedup | Pico de RSS somado mediano |
|---|---|---|---|---|---|---|---|---|
| 1 | 32 | 32 | 256 | 8 MiB | 871,9 ms | 9,2 MiB/s | 1,00x | 111,5 MiB |
| 2 | 16 | 32 | 512 | 16 MiB | 404,6 ms | 39,5 MiB/s | 4,31x | 134,0 MiB |
| 4 | 8 | 32 | 1.024 | 32 MiB | 571,1 ms | 56,0 MiB/s | 6,11x | 227,2 MiB |
Estas linhas são medições, não constantes universais de ajuste. Execute o gerador no host e no armazenamento de destino. Use o ponto de inflexão onde o throughput para de melhorar e, em seguida, reserve CPU e memória para o runner de CI ou a camada de orquestração.
Reproduza todos os quatro grupos de benchmarks com make -C benchmarks readme-matrix.
O comando mede a matriz necessária e falha se qualquer linha solicitada de CPU,
Hyperscan, CUDA, Metal, WGPU, predefinição, cache, daemon, thread, leitor, armazenamento, tamanho
de corpus ou partição estiver indisponível. Use
make -C benchmarks readme-matrix-check para verificar se ambos os snapshots, relatórios
e o README concordam.
Comece com a política padrão e o roteamento automático calibrado. Altere apenas um eixo quando o fluxo de trabalho exigir:
| Fluxo de trabalho | Política de detecção | Execução e reutilização | Controle adicional |
|---|---|---|---|
| Primeira varredura de repositório | Padrão | auto calibrado; --daemon=auto | Revise todas as descobertas antes de adicionar supressões. |
| Árvore local repetida ou varredura de CI | Padrão | auto calibrado; --incremental | Persista o cache incremental apenas entre varreduras da mesma árvore confiável. |
| Loop de feedback curto | --fast | auto calibrado; --incremental opcional | Aceite cobertura reduzida de decodificação, entropia e ML. Execute a política padrão antes do merge. |
| Recuperação de maior revocação | --deep | No processo | Deep é mutuamente exclusivo com fast e precision, e não é elegível para daemon. |
| Inventário grande de menor ruído | --precision | No processo para coleções de repositório, histórico e fontes de nuvem | A predefinição eleva os limites de confiança e desativa a descoberta de entropia. Pode perder credenciais de menor confiança. |
| Inventário de diretório, histórico, arquivo, remoto ou nuvem em escala de TB no Unix | Padrão | keyhog daemon start --mass, depois --daemon=mass | Lotes permanecem limitados a 8 MiB e 1.024 chunks. Preserve o relatório de cobertura do terminal e o recibo de execução de GPU. |
| Validação de credenciais ao vivo | Padrão | No processo | Adicione --verify explicitamente. A verificação envia solicitações derivadas de credenciais aos provedores. |
| Varredura Linux sem swap | Padrão mais --lockdown | No processo; cache incremental desativado | Lockdown recusa verificação, segredos em texto simples, modo rápido e switches que reduzem a completude. |
--fast, --deep e --precision são predefinições de detecção mutuamente exclusivas.
--lockdown é um modo de execução fail-closed, não uma quarta predefinição. Valores explícitos
de --backend são diagnósticos e substituições de benchmark. Eles não substituem
a evidência persistida de mais rápido-correto usada pelo roteamento automático. Consulte
Configuração,
calibração de autoroute,
daemon e varreduras aquecidas
e endurecimento para os
contratos completos.
O KeyHog compila seus 934 detectores em um plano compartilhado de gatilho e extração,
decodifica codificações aninhadas antes da correspondência e aplica pontuação, evidência
e supressão por detector. A CPU Pure-Rust (cpu-fallback) está sempre disponível.
A rota Hyperscan (simd-regex) usa Hyperscan quando esse recurso está presente;
builds portáteis usam a rota de CPU. CUDA (gpu-cuda-region-presence), Metal
(gpu-metal-region-presence) e WGPU (gpu-wgpu-region-presence) são pares
em um seletor de autoroute com prova, não uma cadeia de fallback. A calibração mede
cada par elegível e persiste a rota mais rápida cujas descobertas completas correspondem
à rota de referência para o binário, detector e estado de configuração exatos,
host, acelerador e classe de carga de trabalho. Uma decisão ausente, obsoleta, inválida ou incompleta
interrompe uma varredura automática antes da execução e relata como recalibrar.
Ela nunca substitui silenciosamente outro backend.
Consulte Arquitetura para o mapa do repositório, direção de dependências, pipeline de bytes-para-descoberta e pontos de entrada de perfilagem. Consulte Backends e roteamento para contratos de execução e Calibração de Autoroute para paridade, identidade de carga de trabalho, ciclo de vida do cache e procedimentos de reparo.
Documentação completa: santhreal.github.io/keyhog - instalação, primeira varredura, formatos de saída, internals de detecção, supressões, verificação, integração pre-commit + CI, referência de CLI, autoroute, códigos de saída, variáveis de ambiente e contribuição. Fonte em docs/.
Instale a versão atual do crates.io:```sh cargo install keyhog --locked
Construa o checkout do repositório quando precisar de uma alteração não lançada:```sh
cargo install --path crates/cli --locked
Confirme a compilação instalada:```sh keyhog --version --full keyhog doctor
Use o [guia de instalação](https://santhreal.github.io/keyhog/install.html) para
requisitos da toolchain Rust, perfis de recursos e dependências de runtime
específicas da plataforma.
## O que ele detecta
934 detectores embutidos com validação offline própria e acompanhantes:
- **Provedores de nuvem:** AWS (access key + secret + verificação STS),
Azure (subscription key, storage account key, SAS), GCP (service account,
API key), Cloudflare, Heroku, Vercel, Supabase.
- **Processadores de pagamento:** Stripe, Braintree, Razorpay, Paddle, Plaid,
Square e PayPal, com verificações próprias e acompanhantes opcionais ou
obrigatórios. Uma Razorpay key secret exige sua key ID próxima.
- **Forjas de código:** PATs do GitHub (com checksum CRC32), tokens do GitLab,
senhas de app do Bitbucket, tokens do npm (com checksum), Gitea / Forgejo
/ Codeberg.
- **Auth / SSO:** Okta, Auth0, Clerk, JumpCloud, Kinde.
- **Comunicação:** Slack, Discord, Twilio, SendGrid, Postmark, Mailgun,
Resend, Loops.
- **IA / ML:** OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio,
Cohere, Mistral, HuggingFace, Replicate. Credenciais de organização do
HuggingFace incluem tanto a forma atual `hf_` quanto os tokens legados
`api_org_`.
- **Gerenciadores de senhas:** chaves secretas de conta do 1Password (`A3-` seguido de
cinco ou seis componentes alfanuméricos maiúsculos segmentados).
- **Bancos de dados:** strings de conexão Postgres, MongoDB Atlas, Supabase
service-role, PlanetScale, Neon, Turso, MySQL, URLs Redis.
- **Genérico + descoberta por entropia:** `API_KEY=<blob-de-alta-entropia>` detecta
credenciais sem detector nomeado, limitado por limites de entropia por contexto
+ pontuação por ML.
- **Material criptográfico:** chaves privadas RSA / EC / SSH, blocos
privados PGP, segredos de assinatura JWT.
Cada detector é distribuído como um [arquivo TOML](https://github.com/santhreal/keyhog/blob/main/detectors) (dados, não código):
metadados do serviço, padrões regex, palavras-chave, validadores offline, política de entropia e ML,
campos de acompanhante e manipulador de verificação. Adicionar um novo detector é uma
única alteração TOML revisável;
o [guia do contribuidor](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md) explica o processo.
`keyhog explain <id>` despeja a especificação completa de qualquer detector: padrões, palavras-chave,
endpoint de verificação, além de um guia de rotação e remediação passo a passo
chaveado por serviço, para que uma descoberta nunca seja uma caixa-preta:
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat: despejo da especificação do detector (padrão ghp_[A-Za-z0-9]{36}, palavra-chave, URL de verificação) seguido do guia de rotação do github e remediação passo a passo" width="860" />
</p>
Navegue pela criação e inspeção de detectores na
[referência de detectores](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md), ou consulte o corpus instalado com
`keyhog detectors --search <termo> --verbose`.
## Por que maior recall, menos falsos positivos
- **Varredura com decodificação.** Manifestos `Secret` do Kubernetes, notebooks
Jupyter, payloads JWT, envs encapsulados em base64, valores Helm e blobs
`auth:` do docker-config. O pré-processador estruturado trata ações Helm balanceadas como
valores inertes de tempo de renderização e fecha delimitadores Jupyter ausentes no final do arquivo,
para que bytes literais e células de código completas permaneçam cobertos. Ele decodifica valores
estruturados no lugar e alimenta cada detector downstream com o texto simples. Os detectores
não precisam reimplementar a decodificação individualmente. Varreduras com decodificação habilitada também recuperam
expressões JavaScript de XOR de byte-array e AES-256-CBC sem efeitos colaterais quando
todo o material de recuperação está embutido, incluindo wrappers estritos de passphrase salgada CryptoJS/OpenSSL.
O KeyHog nunca executa a fonte.
- **Remontagem multilinha.** Continuação `"sk-proj-" + \` em JavaScript,
strings multilinha YAML, continuação com barra invertida em Makefile, saídas
modeladas por Helm / Jinja, tudo remontado antes da correspondência regex.
- **Validação de acompanhantes.** Acompanhantes obrigatórios limitam detectores de alto ruído. Uma
Twilio API key sem seu API secret é ignorada. Acompanhantes opcionais enriquecem
a pontuação de evidência ou a verificação. A detecção de AWS access-key não exige
seu secret, mas o secret é necessário para verificação ao vivo.
- **Resolução entre detectores.** O TOML do detector pode exigir, rejeitar ou absorver
descobertas limitadas de outro detector. A resolução permanece determinística em relação à
ordem de entrada, e alvos inválidos, contradições ou ciclos de dependência falham
na compilação do corpus.
- **Vereditos de evidência.** Cada descoberta carrega um nível exato `review`, `likely` ou
`confirmed` além de um código de motivo canônico. Checksum intrínseco ou prova de gramática,
acompanhantes obrigatórios e verificação ao vivo produzem evidência confirmada;
formato forte específico do fornecedor em um papel que carrega credencial produz evidência
provável; âncoras fracas, atribuições genéricas, candidatos apenas por entropia e
contextos de teste, documentação, regra ou identificador permanecem como evidência de revisão.
Um `evidence_score` opcional complementa o veredito quando medido.
O limite padrão `0.40` controla o piso interno de confiança do scanner
e permanece configurável com `--min-confidence`.
- **Calibração bayesiana por detector.** `keyhog calibrate --fp generic-api-key`
grava um posterior Beta(α,β). As varreduras o usam apenas quando `--calibration-cache`
ou `[system].calibration_cache` aponta para esse arquivo, então o ajuste de confiança é
explícito e reproduzível em vez de depender de estado de cache do host.
## Desempenho
Use o harness reproduzível em [`benchmarks/`](https://github.com/santhreal/keyhog/blob/main/benchmarks) para comparar KeyHog,
Betterleaks, Kingfisher, Nosey Parker, TruffleHog e Titus sob um único
contrato de pontuação. O harness exclui o manifesto de ground-truth de toda árvore de varredura.
As tabelas geradas permanecem vazias até que execuções com o esquema atual existam. Execute
`make -C benchmarks report` após a medição. Não edite tabelas geradas
manualmente.
### Ranking de detecção
<!-- BENCH:leaderboard:start -->
#### Corpus espelho sintético com formato SecretBench
Corpus: **mirror** - 15000 fixtures, 3000 positivos rotulados, 2.431.242 bytes. Cada scanner pontuado de forma idêntica (regra de sobreposição SecretBench); o manifesto com a chave de resposta é excluído da árvore de varredura.
| Rank | Scanner | F1 | Precisão | Recall | Descobertas | Wall | Pico 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 |
#### Corpus de regras do campo de origem / território do concorrente
Corpus: **homefield** - 2399 fixtures coletados de suítes de regras de ground-truth de concorrentes (regras Betterleaks e Kingfisher; 1.057 positivos rotulados, 1.342 negativos, 772.974 bytes). Avaliação entre ferramentas no ground-truth do concorrente.
| Rank | Scanner | F1 | Precisão | Recall | Descobertas | Wall | Pico 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 |
### Proveniência dos resultados
| Scanner | Versão do scanner / digest do executável | Identidade do corpus | Identidade do host | Data da execução |
|---|---|---|---|---|
| KeyHog | versão: KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Conjunto de detectores: 926 (926-4168e2c6c93a16ca)<br>Alvo de build: x86_64-linux<br>Versão do modelo ML: moe-v1-246a05b92bec9aa3<br>Cartão do modelo ML: registrado em 2026-07-15; 55 recursos; F1 sintético 0.971 / P 0.945 / R 0.999; F1 real 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; detectores com recall zero 2/32; diferencial de seis scanners indisponível<br>SHA-256 do executável: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:39Z |
| TruffleHog | versão: trufflehog 3.96.0<br>SHA-256 do executável: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:58Z |
| Kingfisher | versão: kingfisher 1.94.0<br>SHA-256 do executável: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:50Z |
| Titus | versão: Titus v1.1.20 (porta Go do NoseyParker)<br>SHA-256 do executável: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:30:03Z |
| Nosey Parker | versão: noseyparker 0.24.0 Configuração de build: Timestamp de build: 2025-05-08T21:11:15.600909923Z Timestamp de commit: 2025-05-08T17:04:47.000000000-04:00 Branch de commit: HEAD SHA de commit: 61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Recursos Cargo: color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Debug: true Optimization: 3 Target Triple: x86_64-unknown-linux-gnu Sistema de build: SO: Ubuntu Versão do SO: Linux (Ubuntu 22.04) Fornecedor da CPU: AuthenticAMD Marca da CPU: AMD EPYC 7763 64-Core Processor Núcleos da CPU: 2 Versão do rustc: 1.86.0 Canal do rustc: stable Host Triple do rustc: x86_64-unknown-linux-gnu Data do commit do rustc: 2025-03-31 SHA do commit do rustc: 05f9846f893b09a1be1fc8560e33fc3c815cfecb Versão LLVM do rustc: 19.1<br>SHA-256 do executável: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:53Z |
| Betterleaks | versão: betterleaks version dev<br>SHA-256 do executável: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15.000 fixtures; 3.000 positivos rotulados; 2.431.242 bytes | SHA-256/12 do hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->
### Velocidade e memória
<!-- BENCH:perf:start -->
#### Corpus espelho sintético com formato SecretBench
| Scanner | Config | Corpus | Wall | Throughput | Pico 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 |
#### Corpus de regras do campo de origem / território do concorrente
| Scanner | Config | Corpus | Wall | Throughput | Pico 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 -->
### Comparação de recall por categoria
<!-- BENCH:gaps:start -->
_Apenas fatia de recall diagnóstico. Precisão geral e F1 permanecem o contrato de comparação; falsos positivos são contados em suas categorias pontuadas._
| Categoria | KeyHog P/R/F1 | KeyHog TP/FN | Melhor concorrente P/R/F1 | Lacuna de recall |
|---|---|---|---|---|
| `generic-high-entropy-string` | 1.000 / 0.434 / 0.606 | 73/95 | Betterleaks 1.000 / 0.798 / 0.887 | +0.363 |
<!-- BENCH:gaps:end -->
### Telemetria de recuperação estática limitada
<!-- BENCH:recovery:start -->
Execução selecionada: scanner **KeyHog** `KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Conjunto de detectores: 926 (926-4168e2c6c93a16ca)<br>Alvo de build: x86_64-linux<br>Versão do modelo ML: moe-v1-246a05b92bec9aa3<br>Cartão do modelo ML: registrado em 2026-07-15; 55 recursos; F1 sintético 0.971 / P 0.945 / R 0.999; F1 real 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; detectores com recall zero 2/32; diferencial de seis scanners indisponível`; corpus **mirror** (15.000 fixtures, 2.431.242 bytes); gerado `2026-08-11T01:29:39Z`; artefato `mirror-keyhog-simd-nocache-nodaemon-full.json`.
Esquema de telemetria: `static-recovery-v1`.
| Disposição | Contagem exata |
|---|---:|
| Suportado | 0 |
| Não suportado | 0 |
| Erroneous | 0 |
| Motivo de rejeição | Contagem exata |
|---|---:|
| _nenhum_ | 0 |
<!-- BENCH:recovery:end -->
### Evidência Bloom de bigrama
<!-- BENCH:bloom:start -->
Esquema de evidência: `bloom-evidence-v1`.
| Campo | Resultado exato |
|---|---|
| Corpus | `samsung-creddata-fx-record-spans-v1` |
| Revisão do corpus | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| SHA-256 do corpus | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| SHA-256 do fixture | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| SHA-256 do executável | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| SHA-256 do corpus de detectores do workspace | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Digest de detectores do scanner | `8d789251e092959f` |
| SHA-256 do corpus de detectores | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Rejeição Bloom | **110/51794 (0,21%)**; 51684 admitidos |
| Disponibilidade externa | 51794 medidos; 0 explicitamente indisponíveis de 51794 declarados; motivos: |
| Descobertas habilitadas vs ignoradas | **IDÊNTICAS**; 977/977 descobertas |
| SHA-256 da identidade da descoberta | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Densidade/estado Bloom | 1793/65536 slots; `healthy`; saturação em 39322 |
A identidade da descoberta vincula detector, arquivo, linha, intervalo de bytes e SHA-256 da credencial; credenciais em texto simples nunca são registradas.
<!-- BENCH:bloom:end -->
Reproduza: `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
reexecuta o conjunto exato de execuções mirror do KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog e
Titus, incluindo o diferencial Bloom CredData vinculado ao executável,
`make -C benchmarks report` regenera as tabelas acima e
`benchmarks/reports/`. Consulte [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
para os corpora (mirror, território do concorrente, Samsung/CredData) e a
matriz de backend/cache/daemon/SO/GPU.
## Workers de daemon em massa com GPU
O daemon Unix de massa opcional mantém um scanner compilado e seu
estado de backend calibrado aquecidos. Varreduras de sistema de arquivos local enviam apenas a raiz canônica e
metadados de política de origem; o daemon lê e agrupa os arquivos em seu próprio
processo. Fontes Git, binárias, remotas e de nuvem que exigem credenciais
do lado do cliente usam frames de chunk limitados e protegidos.```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
--daemon=mass é uma rota obrigatória. Ela nunca faz novas tentativas em processo. Cada lote é
limitado a 8 MiB e 1.024 blocos, independentemente do tamanho total da entrada. Preserve
o envelope de cobertura, o status de saída e o recibo de execução do terminal para cada
partição do inventário.
sudo keyhog scan-system --space 50G sudo keyhog scan-system --include-network --output system-findings.json
`scan-system` é uma auditoria limitada do host local, não um substituto para o particionamento de inventário de repositório ou nuvem. Ela se limita pelo total de bytes verificados em vez de pelo caminho: `--space` é o teto, e sistemas de arquivos montados em rede são ignorados, a menos que você passe `--include-network`. Revise o comportamento de montagem, sistema de arquivos de rede, teto de espaço e privilégios antes de executá-la. Consulte
[triage em todo o sistema](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).
## Bloquear varreduras locais sensíveis
O `--lockdown` do Linux é um modo de proteção de processo com falha fechada:```sh
keyhog scan . --daemon=off --lockdown
Ele bloqueia a memória atual e futura, desativa dumps de núcleo e o cache incremental, permanece em processo e recusa verificação, saída em texto puro, modo rápido e opções que reduzem a completude. Ele falha em plataformas não suportadas ou com capacidade insuficiente de memória bloqueada. Consulte endurecimento e tratamento de dados.
use keyhog_core::{Chunk, ChunkMetadata, RawMatch}; use keyhog_scanner::CompiledScanner;
let detectors = keyhog_core::load_embedded_detectors_or_fail()?; let scanner = CompiledScanner::compile(detectors)?; let findings = scanner.scan(&Chunk { data: "TOKEN=sk_live_EXAMPLE…".into(), metadata: ChunkMetadata::default(), })?; let report_safe: Vec<_> = findings.iter().map(RawMatch::to_redacted).collect();
Os métodos padrão da biblioteca são referências de CPU portáteis determinísticas. Os métodos explícitos de backend retornam erros tipados em vez de encerrar o processo ou substituir silenciosamente outro mecanismo. Chunks e correspondências brutas podem conter texto simples. Converta-os com `RawMatch::to_redacted`, ou use valores finais de `VerifiedFinding`, antes de JSON, logs, disco ou limites de rede.
O [guia de arquitetura](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) define a propriedade de crates, contratos de backend, recibos de recuperação, auxiliares de fonte e limites seguros de relatórios. A documentação Rust em nível de crate detém a API completa.
## Configurar política com precedência explícita
A política do repositório fica em `.keyhog.toml`:```toml
verify = false
[scan]
severity = "high"
incremental = true
[system]
gpu = "auto"
A ordem de resolução é padrões embutidos, configuração do usuário, configuração
do repositório, ambiente quando documentado e, em seguida, substituições explícitas via CLI.
Chaves desconhecidas e combinações inválidas falham antes da varredura. Execute
keyhog config --effective para inspecionar a política resolvida sem expor
credenciais de proxy.
Entradas após expires falham no carregamento da allowlist antes da varredura.
Consulte configuração e precedência para cada chave e variáveis de ambiente para entradas de credenciais e tempo de execução.
O KeyHog mantém a orquestração na borda e o comportamento de domínio em bibliotecas:```text sources -> scanner -> suppression/evidence -> reporting -> optional verifier CLI and Action own process, transport, and exit semantics.
Detector definitions remain data under `detectors/`. `keyhog-core` owns
detector and finding types, `keyhog-scanner` owns matching and execution
backends, `keyhog-sources` owns input acquisition, `keyhog-verifier` owns live
checks, and `keyhog-cli` owns operator workflows.
Start with the [architecture guide](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) for the repository
map, dependency direction, bytes-to-finding pipeline, routing ownership, and
profiling entrypoints.
## Inspect and extend the installation```sh
keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh
A referência da CLI
lista todos os comandos, flags, padrões gerados e status de saída. Use
keyhog --help e keyhog <comando> --help para a versão exata instalada.
detectors/, abra um
PR. O guia do contribuidor (CONTRIBUTING.md)
contém o esquema e um exemplo prático.crates/scanner/tests/contracts/.main incrementa a versão
patch, gera changelogs e publica todas as seis crates no crates.io.
Adicione um fragmento opcional em changes/ para uma nota precisa.
O guia de release cobre
a transação automática e a recuperação de uploads com falha.[email protected]; PGP não é obrigatório.O KeyHog se apoia em trabalhos anteriores de varredura de segredos. Ideias emprestadas de:
Agradecemos a esses projetos e seus contribuidores.
Licença: MIT OR Apache-2.0.
Termos: MIT e Apache-2.0. Esta licença dupla cobre o código e os TOMLs de detectores. Uso comercial, incorporação, forks e serviços hospedados são permitidos sob qualquer uma das licenças.
Gerado a partir de observações UTC da contagem pública de estrelas do GitHub. O repositório armazena o primeiro ponto e cada transição de contagem posterior. Reexecuções no mesmo dia substituem o ponto daquele dia, e contagens inalteradas não geram commit.