<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="Scansione KeyHog che mostra gravità, evidenza, file e riga, rimedio, risultati e stato di copertura" width="900" />
</p>

## Uno scanner di segreti costruito attorno alla GPU

KeyHog non affida poche espressioni regolari a un generico compute shader.
Il suo percorso GPU è basato su [Vyre](https://github.com/santhreal/vyre), un
substrato di calcolo GPU in Rust sviluppato insieme a KeyHog. I trigger dei
rilevatori vengono compilati in tabelle immutabili residenti nella GPU. Lotti
di sorgenti limitati producono posizioni di corrispondenza complete per la
stessa pipeline di conferma, soppressione, evidenza e reporting utilizzata
dai percorsi CPU e Hyperscan.

- **Tre peer GPU fisici.** CUDA, Metal nativo e WGPU portabile vengono
  acquisiti, misurati e riportati in modo indipendente.
- **Parità esatta dei risultati.** La calibrazione rifiuta un candidato la cui
  identità di rilevamento differisce dal percorso di riferimento. Una risposta
  errata più veloce non entra mai nella tabella di routing.
- **Evidenza persistente del percorso.** KeyHog registra il binario, il corpus
  dei rilevatori, la configurazione, la classe di carico di lavoro, l'host,
  l'acceleratore, il driver e l'evidenza temporale misurata. Le scansioni
  normali non eseguono benchmark nel percorso critico.
- **Esecuzione residente.** I worker daemon mantengono caldi lo stato compilato
  dei rilevatori e dell'acceleratore per lotti ripetuti di file, archivi,
  cronologia, remoti e cloud.
- **Nessuna via di fuga CPU nascosta.** Un acceleratore selezionato
  esplicitamente che non riesce a inizializzarsi o a eseguire il dispatch
  fallisce in modo visibile invece di restituire risultati CPU sotto
  un'etichetta GPU.

L'installazione predefinita da crates.io utilizza il percorso CPU portabile
puramente in Rust, quindi funziona su un host Rust pulito. Abilita i tre peer
GPU senza acquisire Hyperscan:```sh
cargo install --locked keyhog --no-default-features --features portable,gpu

Esegui la diagnostica del backend di produzione, quindi ispeziona la route misurata:```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Il primo comando salva le findings esaminate ed esce con `0` senza stamparle.
Esegui il commit di quel file, poi usa il secondo comando per segnalare solo le nuove identità delle findings. Una voce di baseline corrisponde al rilevatore e al valore della credenziale, mai al percorso del file, quindi spostare un segreto registrato non fa fallire il gate, ma ruotarlo sì. Le credenziali modificate e la copertura incompleta restano visibili. Il percorso completo, incluse le partizioni dei monorepo, è [Fail only on new secrets](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets).

Per la scansione successiva, usa il [recipes cookbook](https://santhreal.github.io/keyhog/recipes.html) o i comandi copiabili in [Choose the right workflow](#choose-the-right-workflow). Puoi scansionare la cronologia Git, le immagini dei container, i bucket cloud, le raccolte di repository, gli URL e un'intera macchina senza cambiare strumento.

### Proteggi i repository per scansioni pre-commit rapide

Registra un repository con il daemon perpetuo di KeyHog per la rilevazione rapida dei segreti pre-commit (richiede Unix; su Windows usa `keyhog scan` in-process):```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

L'azione esegue la scansione dell'albero estratto, fallisce in caso di risultati a livello `high` o `critical`, carica il SARIF su Code Scanning e conserva il report come artefatto del workflow. Anche gli errori di installazione, copertura, backend e pubblicazione del report causano il fallimento del job.

Consulta la [guida all'azione GitHub](https://santhreal.github.io/keyhog/workflows/github-action.html) per input, output, adozione della baseline, partizioni monorepo, verifica e comportamento in caso di errore. Usa la [guida CI](https://santhreal.github.io/keyhog/workflows/ci.html) per GitLab, CircleCI, Jenkins, Buildkite e job shell generici. Usa la [guida alla scansione di massa](https://santhreal.github.io/keyhog/guides/mass-scanning.html) per organizzazioni di repository, gruppi Git ospitati, bucket cloud e inventari partizionati.

## Superfici di scansione che altri strumenti trattano come prodotti separati

KeyHog esegue la scansione dei byte nel punto in cui possono fuoriuscire, non solo dei file sorgente tracciati. Usa un report per ogni confine, così la CI conserva la copertura esatta e lo stato di errore.

| Superficie di esposizione | Esempio |
|---|---|
| Artefatto del pacchetto finale | Esegui `npm pack`, poi scansiona il `.tgz` prodotto con `keyhog scan package.tgz`. L'espansione dell'archivio controlla file generati, source map, fixture e metadati assenti dall'albero sorgente previsto. |
| Applicazione browser distribuita | `keyhog scan --url https://app.example.com/assets/app.js` segue la decodifica limitata di JavaScript, source-map, WASM e risposte senza trasformare lo scanner in un crawler illimitato. |
| Issue GitHub, pull request, discussioni, wiki e gist | `keyhog scan --github-collaboration owner/repo --github-all` esegue la scansione di ogni superficie collaborativa al di fuori del checkout. |
| Configurazione di agenti AI e MCP | `keyhog scan ~/.config ~/.claude ~/.codex` applica lo stesso pipeline di rilevamento, decodifica, evidenza e report alla configurazione locale degli strumenti. |
| Layer di immagini container | `keyhog scan --docker-image registry.example.com/team/app:v1` esegue la scansione del contenuto dell'immagine che verrà eseguito, inclusi i file introdotti durante la build. |
| Inventari di oggetti cloud | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` o `--azure-container-url URL` conserva la paginazione del provider, gli oggetti e la copertura dei limiti di byte nel report del terminale. |
| Intero host di sviluppo | `sudo keyhog scan-system --space 50G` rileva i filesystem montati e la cronologia Git raggiungibile sotto un budget di archiviazione rigido. |

Questi percorsi condividono un unico contratto di rilevamento e report. Un errore specifico della sorgente non può trasformarsi silenziosamente in una scansione locale più ristretta.

## Scegli il workflow giusto

Scegli prima il confine della sorgente. Un preset cambia il lavoro di rilevamento, mentre un backend cambia l'esecuzione. Nessuno dei due estende una scansione dell'albero di lavoro alla cronologia Git, a un inventario del provider, allo storage cloud o a un audit dell'host.

Non esiste una scorciatoia onesta per `scan everything`. Una revisione completa del patrimonio esegue i confini pertinenti di seguito come job separati e conserva ogni report `json-envelope` con il suo codice di uscita grezzo.

| Esigenza | Inizia con | Throughput e riutilizzo | Confine di copertura |
|---|---|---|---|
| Feedback locale rapido | `keyhog scan . --fast --incremental` | Riutilizza gli hash dei file invariati. Il preset fast salta il lavoro di decodifica, entropia e ML. | Esegui la policy predefinita prima del merge perché fast è intenzionalmente più ristretto. |
| Scansione completa del repository | `keyhog scan .` | `auto` calibrato e default worker basato su core CPU. Aggiungi `--incremental` per scansioni ripetute dello stesso albero attendibile. | Solo file correnti. Non aggiunge la cronologia Git. |
| Gate di commit staged | `keyhog scan --git-staged` o `keyhog hook install` | Legge i blob esatti dell'indice, quindi le modifiche non staged non possono cambiare il risultato. | Solo contenuto staged. Esegui una scansione dell'albero di lavoro separatamente quando i byte locali non staged contano. |
| Guardia perpetua del repository | `keyhog guard add . --mode repo` poi `keyhog guard status .` | Registro root residente nel daemon con macchina a 7 stati, cache di attestazione pulita e tracciamento dell'identità della policy. | Richiede un daemon in esecuzione. La guardia integra, non sostituisce, le scansioni staged e dell'albero di lavoro. |
| Gate per pull request GitHub | `santhreal/keyhog@v0` | L'azione installa, esegue la scansione, pubblica SARIF e un artefatto, poi conserva lo stato di KeyHog. | Un percorso estratto. Usa la scansione dell'inventario del provider per un'organizzazione. |
| GitLab, Jenkins, Buildkite o shell CI | `keyhog scan . --format json-envelope --output keyhog.json` | Conserva il report e il codice di uscita su successo, risultati ed errori. Usa `--git-diff <base>` solo per un gate esplicitamente più ristretto sulle righe modificate. | I byte presenti nel checkout o il diff selezionato. |
| Adotta un repository con risultati noti | Crea `.keyhog-baseline.json`, committalo, poi esegui la scansione con `--baseline .keyhog-baseline.json`. | Le identità esistenti restano visibili nella baseline mentre solo i nuovi risultati fanno fallire il gate. | Una baseline non sopprime credenziali modificate o copertura incompleta. |
| Recupero Git ricorsivo | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | Calibra la policy deep una volta per classe di worker. Esegui in-process. | Un repository. `--git-history` copre solo l'ascendenza del checkout corrente, quindi un branch mai estratto viene mancato senza gap di copertura; `--git-blobs` raggiunge anche blob orfani, commit rimossi con amend, stash, note, messaggi di tag annotati e ref impacchettati. |
| Ispezione di container o archivi | `keyhog scan --docker-image registry/app:v1` o `keyhog scan incoming/` | Conserva un report envelope così i membri saltati, corrotti, crittografati, non sicuri o sovradimensionati restano visibili. | Solo l'immagine o il percorso filesystem selezionato e i formati annidati supportati. |
| Ispezione di URL, risposta o HAR | `keyhog scan --url https://api.example.com/config` o `keyhog scan capture.har` | Usa limiti di sorgente limitati e conserva l'envelope del terminale. | Solo risposte recuperate o voci di cattura. Non è un crawler. |
| Inventario di organizzazione o cloud | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | Partiziona per provider, proprietario o bucket. Esegui partizioni indipendenti in concorrenza con un report e uno stato ciascuna. | Un inventario del provider selezionato per job. I limiti di paginazione o oggetti restano confini di copertura. |
| Conferma se i risultati idonei sono attivi | `keyhog scan . --verify` | La concorrenza del provider e i controlli di frequenza sono separati dai worker dello scanner. | Invia richieste derivate dalle credenziali agli endpoint dichiarati del provider. Non tutti i rilevatori supportano la verifica. |
| Scansione sanitaria dell'intero host | `sudo keyhog scan-system --space 50G` | Usa tutti i core CPU per impostazione predefinita e scansiona la cronologia Git rilevata dopo i dati del filesystem. | Filesystem montati locali. I mount di rete sono opt-in e il tetto di spazio è rigido. |
| Directory, cronologia, archivio, remoto o inventario cloud con GPU su Unix | Calibra l'autoroute, avvia `keyhog daemon start --mass`, poi esegui `keyhog scan --daemon=mass <SOURCE>`. | Trasmette batch limitati attraverso un worker compilato CPU, Hyperscan, CUDA, Metal o WGPU. Aggiungi `--incremental` per alberi filesystem caldi invariati. La ricevuta del terminale riporta totale esatto e batch GPU, chunk, byte, quota GPU e throughput. | Baseline, verifica, lockdown, preset, overlay e altre modifiche alla policy dello scanner vengono rifiutate prima dell'acquisizione. Lo stato incrementale si applica solo alle radici filesystem locali del daemon. |

### Scansiona ogni confine di sorgente supportato

Usa un comando per confine. Conserva un report `json-envelope` e lo stato di uscita grezzo per ogni partizione dell'inventario.

| Sorgente o caso d'uso | Comando |
|---|---|
| Più radici locali | `keyhog scan services/api services/web deploy/` |
| File modificati in continuazione | `keyhog watch services/api deploy/` |
| Byte staged, righe modificate, cronologia raggiungibile o blob | `keyhog scan --git-staged`, `--git-diff main`, `--git-history .` o `--git-blobs .` |
| Binari nativi e stringhe firmware | `keyhog scan --binary firmware.bin` (una scansione di directory semplice salta i binari ed esce comunque con `0`) |
| Archivi e sorgenti compressi | `keyhog scan incoming/` (i membri supportati si espandono automaticamente) |
| Layer di immagini Docker | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, source map, WASM o risposta di un endpoint | `keyhog scan --url https://api.example.com/config` |
| Catture di richieste e risposte HTTP | `keyhog scan capture.har` |
| Issue GitHub, pull request, discussioni, wiki e gist | `keyhog scan --github-collaboration owner/repo --github-all` |
| Inventari GitHub, GitLab o Bitbucket | `--github-org ORG`, `--gitlab-group GROUP` o `--bitbucket-workspace WORKSPACE` |
| Inventari S3, GCS o Azure Blob | `--s3-bucket BUCKET`, `--gcs-bucket BUCKET` o `--azure-container-url URL` |
| Uno stream limitato da un altro strumento | `producer \| keyhog scan --stdin` (usa `set -o pipefail` così un producer fallito fa emergere il proprio errore, non una scansione a zero byte) |

Una scansione di directory semplice non legge i binari nativi. Ognuno diventa un gap di copertura `binary (estensione o sniff del contenuto)`, la scansione esce comunque con `0` e `--no-default-excludes` non lo cambia, quindi passa `--binary` quando gli artefatti compilati sono in scope. Quel flag richiede una build con la feature `binary`, che l'installazione crates.io predefinita ha e la feature snella `ci` non ha.

L'estrazione di binari nativi riporta credenziali complete che soddisfano il contratto di forma esplicito di un rilevatore nominato. Sopprime frammenti brevi di prefisso e stringhe generiche a forma di assegnazione dalle sezioni dati compilate perché quei byte non conservano il contesto sorgente.

Il recupero degli endpoint è limitato e schermato da SSRF. Non è un crawler. Gli endpoint cloud privati e l'inoltro delle credenziali richiedono i loro flag di fiducia espliciti. I token del provider appartengono alle variabili d'ambiente documentate, non agli argomenti di processo.

Usa il [selettore di workflow](https://santhreal.github.io/keyhog/capabilities.html) per i dettagli di sorgente e policy, la [guida all'azione GitHub](https://santhreal.github.io/keyhog/workflows/github-action.html) per il gate di repository mantenuto, la [guida CI diretta](https://santhreal.github.io/keyhog/workflows/ci.html) per report durevoli e gestione dell'uscita, e la [guida alla scansione di massa](https://santhreal.github.io/keyhog/guides/mass-scanning.html) per partizionamento e aggregazione. Il [ricettario](https://santhreal.github.io/keyhog/recipes.html) copre container, archivi, URL, contenuto collaborativo GitHub e sorgenti cloud.

### Velocità e concorrenza senza congetture

Inizia con le impostazioni predefinite. Cargo non può eseguire KeyHog dopo `cargo install`, quindi esegui i comandi seguenti una volta dopo aver installato una build Cargo multi-backend e di nuovo dopo che host, binario, corpus di rilevatori, driver o classi di carico di lavoro cambiano:```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Per un runner condiviso in cui al job vengono allocati quattro worker scanner e un
worker reader:```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

Costruisci il checkout del repository quando ti serve una modifica non ancora rilasciata:```sh
cargo install --path crates/cli --locked

Use la [guida all'installazione](https://santhreal.github.io/keyhog/install.html) per
i requisiti della toolchain Rust, i profili di funzionalità e le dipendenze
runtime specifiche per piattaforma.


## Cosa rileva

934 rilevatori incorporati con validazione offline e companion di proprietà del rilevatore:

- **Provider cloud:** AWS (access key + secret + verifica STS),
  Azure (subscription key, storage account key, SAS), GCP (service account,
  API key), Cloudflare, Heroku, Vercel, Supabase.
- **Processori di pagamento:** Stripe, Braintree, Razorpay, Paddle, Plaid,
  Square e PayPal, con controlli di proprietà del rilevatore e companion
  opzionali o obbligatori. Una Razorpay key secret richiede la key ID adiacente.
- **Forge di sorgenti:** PAT GitHub (con checksum CRC32), token GitLab,
  password app Bitbucket, token npm (con checksum), Gitea / Forgejo
  / Codeberg.
- **Auth / SSO:** Okta, Auth0, Clerk, JumpCloud, Kinde.
- **Comunicazioni:** Slack, Discord, Twilio, SendGrid, Postmark, Mailgun,
  Resend, Loops.
- **AI / ML:** OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio,
  Cohere, Mistral, HuggingFace, Replicate. Le credenziali dell'organizzazione
  HuggingFace includono sia la forma corrente `hf_` sia i token legacy `api_org_`.
- **Gestori di password:** chiavi segrete dell'account 1Password (`A3-` seguite da
  cinque o sei componenti segmentate alfanumeriche maiuscole).
- **Database:** stringhe di connessione Postgres, MongoDB Atlas, Supabase
  service-role, PlanetScale, Neon, Turso, MySQL, URL Redis.
- **Generico + scoperta per entropia:** `API_KEY=<blob-ad-alta-entropia>` rileva
  credenziali senza un rilevatore nominato, limitato da soglie di entropia
  per contesto + punteggio ML.
- **Materiale crittografico:** chiavi private RSA / EC / SSH, blocchi privati
  PGP, segreti di firma JWT.

Ogni rilevatore è distribuito come [file TOML](https://github.com/santhreal/keyhog/blob/main/detectors) (dati, non codice):
metadati del servizio, pattern regex, parole chiave, validatori offline, policy
di entropia e ML, campi companion e gestore di verifica. Aggiungere un nuovo
rilevatore è una singola modifica TOML revisionabile;
la [guida per i contributori](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md) ne illustra il percorso.

`keyhog explain <id>` scarica la specifica completa di qualsiasi rilevatore:
pattern, parole chiave, endpoint di verifica, oltre a una guida alla rotazione
e alla remediation passo-passo associata al servizio, così un risultato non è
mai una scatola nera:

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat: dump della specifica del rilevatore (pattern ghp_[A-Za-z0-9]{36}, parola chiave, URL di verifica) seguito dalla guida alla rotazione GitHub e dalla remediation passo-passo" width="860" />
</p>

Consulta la creazione e l'ispezione dei rilevatori nel
[riferimento dei rilevatori](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md), oppure interroga il corpus
installato con `keyhog detectors --search <termine> --verbose`.

## Perché maggiore recall, meno falsi positivi

- **Scansione con decodifica.** Manifest `Secret` Kubernetes, notebook
  Jupyter, payload JWT, env avvolti in base64, valori Helm e blob `auth:`
  di docker-config. Il preprocessore strutturato tratta le azioni Helm
  bilanciate come valori inerti a tempo di render e chiude i delimitatori
  Jupyter mancanti a fine file, così i byte letterali e le celle di codice
  complete restano coperti. Decodifica i valori strutturati in posizione e
  fornisce il testo in chiaro a ogni rilevatore a valle. I rilevatori non
  devono reimplementare ciascuno la decodifica. Le scansioni con decodifica
  abilitata recuperano anche espressioni JavaScript XOR di byte-array e
  AES-256-CBC senza effetti collaterali quando tutto il materiale di recupero
  è incorporato, incluse le rigide wrapper CryptoJS/OpenSSL con passphrase
  salata. KeyHog non esegue mai il sorgente.
- **Riassemblaggio multilinea.** Continuazione `"sk-proj-" + \` in JavaScript,
  stringhe multilinea YAML, continuazione con backslash nei Makefile, output
  templati Helm / Jinja, tutto riassemblato prima del matching regex.
- **Validazione companion.** I companion obbligatori limitano i rilevatori ad
  alto rumore. Una API key Twilio senza il suo API secret viene saltata. I
  companion opzionali arricchiscono il punteggio delle evidenze o la verifica.
  Il rilevamento dell'access-key AWS non richiede il suo secret, ma il secret è
  necessario per la verifica live.
- **Risoluzione tra rilevatori.** Il TOML del rilevatore può richiedere,
  rifiutare o assorbire risultati delimitati di un altro rilevatore. La
  risoluzione resta deterministica rispetto all'ordine di input, e target
  non validi, contraddizioni o cicli di dipendenza fanno fallire la compilazione
  del corpus.
- **Verdetti delle evidenze.** Ogni risultato porta un livello esatto `review`,
  `likely` o `confirmed` più un codice motivo canonico. Checksum intrinseco o
  prova grammaticale, companion obbligatori e verifica live producono evidenze
  confermate; una forma forte specifica del fornitore in un ruolo che contiene
  credenziali produce evidenze probabili; ancoraggi deboli, assegnazioni
  generiche, candidati solo per entropia e contesti di test, documentazione,
  regole o identificatori restano evidenze di review.
  Un `evidence_score` opzionale integra il verdetto quando misurato.
  La soglia predefinita `0.40` controlla il pavimento di confidenza interno
  dello scanner e resta configurabile con `--min-confidence`.
- **Calibrazione bayesiana per rilevatore.** `keyhog calibrate --fp generic-api-key`
  scrive un posteriore Beta(α,β). Le scansioni lo usano solo quando
  `--calibration-cache` o `[system].calibration_cache` punta a quel file, così
  la regolazione della confidenza è esplicita e riproducibile invece di
  dipendere da stato di cache host casuale.

## Prestazioni

Usa l'harness riproducibile in [`benchmarks/`](https://github.com/santhreal/keyhog/blob/main/benchmarks) per confrontare
KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog e Titus sotto un
unico contratto di punteggio. L'harness esclude il manifest ground-truth da
ogni albero di scansione. Le tabelle generate restano vuote finché non esistono
esecuzioni con schema corrente. Esegui `make -C benchmarks report` dopo la
misurazione. Non modificare a mano le tabelle generate.

### Classifica di rilevamento

<!-- BENCH:leaderboard:start -->
#### Corpus mirror sintetico a forma SecretBench
Corpus: **mirror** - 15000 fixture, 3000 positivi etichettati, 2.431.242 byte. Ogni scanner è stato valutato in modo identico (regola di sovrapposizione SecretBench); il manifest con la chiave di risposta è escluso dall'albero di scansione.

| Rank | Scanner | F1 | Precision | Recall | Findings | Wall | Peak 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 di regole homefield / home-turf dei concorrenti
Corpus: **homefield** - 2399 fixture raccolte dalle suite di regole ground-truth dei concorrenti (regole Betterleaks e Kingfisher; 1.057 positivi etichettati, 1.342 negativi, 772.974 byte). Valutazione incrociata tra strumenti sul ground truth dei concorrenti.

| Rank | Scanner | F1 | Precision | Recall | Findings | Wall | Peak 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 |
### Provenienza dei risultati

| Scanner | Versione scanner / digest eseguibile | Identità corpus | Identità host | Data esecuzione |
|---|---|---|---|---|
| KeyHog | versione: KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Set rilevatori: 926 (926-4168e2c6c93a16ca)<br>Target di build: x86_64-linux<br>Versione modello ML: moe-v1-246a05b92bec9aa3<br>Scheda modello ML: registrata 2026-07-15; feature 55; F1 sintetico 0.971 / P 0.945 / R 0.999; F1 reale 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; rilevatori a recall zero 2/32; differenziale a sei scanner non disponibile<br>SHA-256 eseguibile: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:39Z |
| TruffleHog | versione: trufflehog 3.96.0<br>SHA-256 eseguibile: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:58Z |
| Kingfisher | versione: kingfisher 1.94.0<br>SHA-256 eseguibile: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:50Z |
| Titus | versione: Titus v1.1.20 (porting Go di NoseyParker)<br>SHA-256 eseguibile: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:30:03Z |
| Nosey Parker | versione: noseyparker 0.24.0 Configurazione di build: Timestamp build:    2025-05-08T21:11:15.600909923Z Timestamp commit:   2025-05-08T17:04:47.000000000-04:00 Ramo commit:      HEAD SHA commit:         61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Funzionalità Cargo:     color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Debug:              true Ottimizzazione:       3 Target triple:      x86_64-unknown-linux-gnu Sistema di build: OS:                 Ubuntu Versione OS:         Linux (Ubuntu 22.04) Vendor CPU:         AuthenticAMD Marca CPU:          AMD EPYC 7763 64-Core Processor Core CPU:          2 Versione rustc:      1.86.0 Canale rustc:      stable Host triple rustc:  x86_64-unknown-linux-gnu Data commit rustc:  2025-03-31 SHA commit rustc:   05f9846f893b09a1be1fc8560e33fc3c815cfecb Versione LLVM rustc: 19.1<br>SHA-256 eseguibile: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 hostname: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:53Z |
| Betterleaks | versione: betterleaks versione dev<br>SHA-256 eseguibile: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte | SHA-256/12 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 -->

### Velocità e memoria

<!-- BENCH:perf:start -->
#### Corpus mirror sintetico a forma SecretBench

| Scanner | Config | Corpus | Wall | Throughput | Peak 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 di regole homefield / home-turf dei concorrenti

| Scanner | Config | Corpus | Wall | Throughput | Peak 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 -->

### Confronto recall per categoria

<!-- BENCH:gaps:start -->
_Solo fetta di recall diagnostico. Precision complessiva e F1 restano il contratto di confronto; i falsi positivi sono conteggiati nelle loro categorie con punteggio._

| Categoria | KeyHog P/R/F1 | KeyHog TP/FN | Miglior concorrente P/R/F1 | Gap di 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 di recupero statico delimitato

<!-- BENCH:recovery:start -->
Esecuzione selezionata: scanner **KeyHog** `KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Set rilevatori: 926 (926-4168e2c6c93a16ca)<br>Target di build: x86_64-linux<br>Versione modello ML: moe-v1-246a05b92bec9aa3<br>Scheda modello ML: registrata 2026-07-15; feature 55; F1 sintetico 0.971 / P 0.945 / R 0.999; F1 reale 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; rilevatori a recall zero 2/32; differenziale a sei scanner non disponibile`; corpus **mirror** (15.000 fixture, 2.431.242 byte); generato `2026-08-11T01:29:39Z`; artefatto `mirror-keyhog-simd-nocache-nodaemon-full.json`.

Schema telemetria: `static-recovery-v1`.

| Disposizione | Conteggio esatto |
|---|---:|
| Supportato | 0 |
| Non supportato | 0 |
| Errato | 0 |

| Motivo di rifiuto | Conteggio esatto |
|---|---:|
| _nessuno_ | 0 |
<!-- BENCH:recovery:end -->

### Evidenze Bloom bigram

<!-- BENCH:bloom:start -->
Schema evidenze: `bloom-evidence-v1`.

| Campo | Risultato esatto |
|---|---|
| Corpus | `samsung-creddata-fx-record-spans-v1` |
| Revisione corpus | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| SHA-256 corpus | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| SHA-256 fixture | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| SHA-256 eseguibile | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| SHA-256 corpus rilevatori workspace | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Digest rilevatori scanner | `8d789251e092959f` |
| SHA-256 corpus rilevatori | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Rifiuto Bloom | **110/51794 (0.21%)**; 51684 ammessi |
| Disponibilità esterna | 51794 misurati; 0 esplicitamente non disponibili su 51794 dichiarati; motivi:  |
| Risultati abilitati vs bypassati | **IDENTICI**; 977/977 risultati |
| SHA-256 identità risultato | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Densità/stato Bloom | 1793/65536 slot; `healthy`; saturazione a 39322 |

L'identità del risultato vincola rilevatore, file, riga, intervallo di byte e SHA-256 della credenziale; le credenziali in chiaro non vengono mai registrate.
<!-- BENCH:bloom:end -->

Riproduci: `make -C benchmarks canonical KEYHOG_BIN=/percorso/assoluto/keyhog`
riesegue l'esatto set di esecuzioni mirror di KeyHog, Betterleaks, Kingfisher,
Nosey Parker, TruffleHog e Titus, incluso il differenziale Bloom CredData
vincolato all'eseguibile; `make -C benchmarks report` rigenera le tabelle sopra
e `benchmarks/reports/`. Vedi [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
per i corpora (mirror, home-turf dei concorrenti, Samsung/CredData) e la
matrice backend/cache/daemon/OS/GPU.

## Worker daemon di massa con supporto GPU

Il daemon Unix di massa opzionale mantiene caldo uno scanner compilato e il suo
stato backend calibrato. Le scansioni del filesystem locale inviano solo la
radice canonica e i metadati della policy delle sorgenti; il daemon legge e
raggruppa i file nel proprio processo. Le sorgenti Git, binarie, remote e cloud
che richiedono credenziali lato client usano frame di chunk delimitati protetti.```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` è un audit locale limitato all'host, non un sostituto per la partizione dell'inventario di repository o
cloud. Si limita in base al totale di byte scansionati piuttosto
che al percorso: `--space` è il tetto massimo, e i filesystem montati in rete vengono
saltati a meno che non si passi `--include-network`. Rivedi il comportamento di mount, filesystem di rete,
tetto di spazio e privilegi prima di eseguirlo. Vedi
[triage a livello di sistema](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).

## Blocca le scansioni locali sensibili

`--lockdown` di Linux è una modalità di protezione dei processi fail-closed:```sh
keyhog scan . --daemon=off --lockdown

I metodi predefiniti della libreria sono riferimenti CPU portabili e deterministici. I
metodi espliciti del backend restituiscono errori tipizzati invece di terminare il processo o
sostituire silenziosamente un altro motore. I chunk grezzi e le corrispondenze possono contenere
testo in chiaro. Convertili con `RawMatch::to_redacted`, oppure usa i valori finali
`VerifiedFinding`, prima dei confini JSON, log, disco o rete.

La [guida all'architettura](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) definisce la proprietà delle crate,
i contratti dei backend, le ricevute di recupero, gli helper delle sorgenti e i confini sicuri
per la reportistica. La documentazione Rust a livello di crate possiede l'API completa.

## Configurare la policy con precedenza esplicita

La policy del repository risiede in `.keyhog.toml`:```toml
verify = false

[scan]
severity = "high"
incremental = true

[system]
gpu = "auto"

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