keyhog

<p align="center">
  <img src="https://raw.githubusercontent.com/santhreal/keyhog/HEAD/docs/assets/keyhog-banner.svg" alt="KeyHog GPU-accelerated open-source secret scanner for code, Git history, cloud, containers, browser assets, and CI" width="960" />
</p>

<p align="center">
  <a href="https://crates.io/crates/keyhog"><img src="https://img.shields.io/crates/v/keyhog?style=flat-square&amp;color=ffd60a&amp;label=crates.io&amp;labelColor=0a0a0a" alt="KeyHog su crates.io" /></a>&nbsp;
  <a href="https://santhreal.github.io/keyhog/"><img src="https://img.shields.io/badge/docs-KeyHog-ffd60a?style=flat-square&amp;labelColor=0a0a0a" alt="Documentazione KeyHog" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/actions"><img src="https://img.shields.io/github/actions/workflow/status/santhreal/keyhog/ci.yml?style=flat-square&amp;label=CI&amp;labelColor=0a0a0a" alt="CI" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-MIT%20OR%20Apache--2.0-9aa0b4?style=flat-square&amp;labelColor=0a0a0a" alt="MIT OR Apache-2.0" /></a>&nbsp;
  <a href="https://github.com/santhreal/keyhog/blob/main/metrics/stars.svg"><img src="https://img.shields.io/github/stars/santhreal/keyhog?style=flat-square&amp;color=ffd60a&amp;label=stars&amp;labelColor=0a0a0a" alt="Stelle GitHub e cronologia stelle di proprietà del repository" /></a>
</p>

<p align="center">
  <strong><a href="https://santh.dev/keyhog/">Sito web</a></strong> ·
  <strong><a href="https://santhreal.github.io/keyhog/">Documentazione</a></strong> ·
  <strong><a href="https://santh.dev/blog/keyhog/">Architettura</a></strong> ·
  <strong><a href="https://github.com/santhreal/vyre">Motore GPU Vyre</a></strong>
</p>

# KeyHog: scanner di segreti accelerato via GPU per codice, cloud e CI

**KeyHog è uno scanner di segreti open-source in Rust che trova e verifica
chiavi API, token, password e credenziali esposte in codice sorgente, cronologia
Git, container, storage cloud, asset del browser, contenuti collaborativi e
sistemi in esecuzione.**

La maggior parte degli scanner di segreti si ferma alle corrispondenze regex su CPU in un checkout del repository.
KeyHog combina **934 rilevatori specifici per servizio**, decodifica per credenziali
occultate, prove contestuali con soppressione, verifica live tramite provider,
ed esecuzione di prima classe su **CUDA, Metal e WGPU tramite
[Vyre](https://github.com/santhreal/vyre)**. La calibrazione misura ogni backend
CPU puro-Rust idoneo, Hyperscan/SIMD e GPU. Il routing automatico utilizza quindi
il percorso più veloce con parità dimostrata per l'esatto host e classe di carico di lavoro.

| La GPU è un backend reale | Scansiona la superficie d'attacco effettiva | Separa il segnale dal rumore | Agisci sul risultato |
|---|---|---|---|
| CUDA, Metal nativo e WGPU sono peer misurati, non una catena di fallback silenziosa. | Scansiona cronologia Git, layer Docker, archivi, bucket cloud, source map, WASM, catture HAR, raccolte Git ospitate e interi sistemi. | Decodifica base64, hex, URL, protobuf, multilinea e configurazione strutturata prima di applicare prove, soppressione di esempi e baseline. | Verifica le credenziali idonee con le API dei provider, emetti SARIF o envelope strutturati e preserva copertura esatta e semantica di uscita. |```sh
cargo install --locked keyhog
keyhog scan .
```
<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
```
Abilita il peer regex SIMD Hyperscan o Vectorscan:```sh
cargo install --locked keyhog --no-default-features --features portable,simd
```
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
```
La [guida al backend](https://santhreal.github.io/keyhog/backends.html) documenta
le tabelle residenti, il modello di dispatch limitato, il contratto di parità e le
prove riproducibili di crossover.

## Per iniziare

### Installa ed esegui la tua prima scansione

I due comandi sopra installano l'ultima release di crates.io e scansionano l'albero
corrente con il percorso portabile puramente in Rust.

Blocca un ambiente CI a una release esatta con
`cargo install --locked --version '=0.5.86' keyhog`. KeyHog richiede Rust 1.89
o successivo. Consulta la [guida all'installazione](https://santhreal.github.io/keyhog/install.html)
per i profili GPU, Hyperscan, CI, portabile e di build da sorgente.

KeyHog esce con codice `1` quando un risultato blocca la policy di evidenza attiva. La policy
predefinita blocca i risultati `likely` e `confirmed` mantenendo visibili i risultati `review`
con uscita `0`; `--evidence-policy paranoid` blocca ogni livello. Esamina
il livello di evidenza esatto, il codice motivo, il file, la riga, il rilevatore e la
correzione di ogni risultato. Altri codici diversi da zero descrivono errori di input, di sistema, di verifica o di
copertura; consulta il
[riferimento dei codici di uscita](https://santhreal.github.io/keyhog/reference/exit-codes.html).

Il contratto di processo completo è:

| Uscita | Significato |
|---|---|
| `0` successo | Nessun risultato blocca la policy di evidenza attiva e non si è verificato alcun errore di copertura. I risultati di livello review possono rimanere visibili con la policy predefinita. |
| `1` risultati bloccanti | Almeno un risultato blocca la policy di evidenza attiva, ma nessuno è stato confermato come live. |
| `2` errore dell'operatore | Correggi gli argomenti, la configurazione, il corpus di rilevatori o l'input correggibile dall'operatore. |
| `3` errore di sistema | Ripara o riprova l'esecutore. Include I/O di basso livello, servizio daemon fatale, cache incrementale ed errori SIMD selezionati esplicitamente. |
| `4` errore di salute/self-test | Un controllo di salute `doctor` o `backend --self-test` non era sano. |
| `10` credenziali live | Almeno una credenziale è stata confermata come live. |
| `11` panico dello scanner | Scarta il risultato della scansione perché lo stato dello scanner non è affidabile. |
| `12` errore GPU richiesto | Un percorso GPU selezionato o richiesto esplicitamente non ha potuto essere eseguito. |
| `13` copertura incompleta | Una sorgente richiesta è fallita o la copertura dell'input era incompleta e nessun esito di risultato ha avuto precedenza. |
| `130` interrotto | SIGINT o Ctrl-C ha interrotto il processo. |

**Filtra, formatta, blocca:**

Crea una baseline prima di usarla come filtro:```sh
keyhog scan . --create-baseline .keyhog-baseline.json
keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.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
```
Vedi la [guida alla guardia perpetua](https://santhreal.github.io/keyhog/workflows/guard.html)
e il [workflow pre-commit](https://santhreal.github.io/keyhog/workflows/precommit.html)
per la configurazione completa, il ciclo di vita della macchina a stati e l'automazione degli hook.

### Aggiungilo a GitHub Actions

Crea `.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
```
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
```
| Control | Usalo per | Mantieni questo invariante |
|---|---|---|
| `--backend auto` calibrato | Selezione di routine di CPU, Hyperscan o GPU. | Un backend esplicito è un override diagnostico, non un default più veloce. |
| `--threads <N>` | Riservare capacità CPU su un runner condiviso. Gli host dedicati normalmente dovrebbero lasciarlo non impostato così KeyHog usa i core disponibili. | Ogni valore deve essere positivo. Più processi KeyHog concorrenti possiedono ciascuno un pool di worker, quindi dividi il budget dell'host tra le partizioni. |
| `--reader-threads <N>` | Pipeline di storage misurate dove il lavoro del reader, non la scansione, è il collo di bottiglia. | Il default deriva dal pool di worker di scansione. Lascialo non impostato finché il profiling non mostra un collo di bottiglia del reader. |
| `--incremental` e `--incremental-cache <PATH>` | Scansioni ripetute dello stesso albero fidato. | Non condividere un singolo indice tra repository non correlati o job non fidati. |
| Partizioni di provider o repository | Scansione concorrente dell'estate e retry indipendenti. | Preserva un envelope terminale e un codice di uscita grezzo per partizione. Non concatenare i risultati e scartare lo stato di copertura. |
| `--verify-concurrency`, `--verify-rate` e `--verify-batch` | Limitare i controlli live del provider indipendentemente dalla scansione dei file. | La verifica invia richieste derivate dalle credenziali. I rate limit del provider, non il numero di CPU, governano questa concorrenza. |
| Daemon di massa | Flussi di directory, cronologia, archivi, remoti o cloud su scala TB su un singolo worker Unix. | Ogni frame è limitato a 8 MiB e 1.024 chunk. Il daemon serializza lo stato dei frammenti e restituisce una ricevuta esatta di esecuzione CPU/GPU. |
| `--fast`, default, `--deep` o `--precision` | Selezionare una policy esplicita di costo di rilevamento e recall. | Questi preset si escludono a vicenda e cambiano la copertura. Non sono manopole di velocità intercambiabili. |

Ispeziona la policy risolta con `keyhog config --effective`. Usa `--profile`
per misurare le fasi fisse dello scanner e l'esecuzione completa dell'operatore prima di modificare
i controlli di reader, batch o profondità del canale. Il report a basso overhead registra
sorgente, backend, cache, workload, thread, input, transizioni di stato, tempo CPU,
picco di memoria, SHA-256 esatto del binario, SHA-256 delle funzionalità abilitate, tripletta target, profilo di
build, compilatore, allocatore, SHA-256 del backend collegato, SHA-256 del corpus del rilevatore,
BLAKE3 dei rilevatori abilitati, BLAKE3 del piano compilato, provenienza del rilevatore con hash,
BLAKE3 completo della configurazione risolta, BLAKE3 della policy di prestazioni, preset,
stato di protezione applicato, adapter di sorgente, BLAKE3 della sorgente-target con hash,
BLAKE3 della partizione sorgente con hash, byte grezzi della sorgente, fanout delle unità sorgente,
byte derivati dalla decodifica, byte completati dal dispatch del backend e bucket stabili di dimensione/fanout.
I domini di byte che il loro adapter di sorgente non può ancora distinguere rimangono
esplicitamente non disponibili invece di diventare zeri misurati. Il report non
registra contenuto della sorgente, valori delle credenziali, percorsi grezzi, URL grezzi o valori
grezzi di configurazione. Usa `--perf-trace` solo per contatori diagnostici costosi per pattern e
backend.
Lascia i controlli avanzati della pipeline non impostati a meno che una misurazione riproducibile sul
worker di destinazione non mostri un miglioramento.

Per una scansione ricorrente completa del repository:```sh
keyhog scan . --incremental \
  --format json-envelope --output keyhog.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
```
Il secondo comando è un budget di risorse, non un ottimo universale. Misura
l'host di destinazione prima di scegliere conteggi espliciti di worker.

Per il [recupero profondo](https://santhreal.github.io/keyhog/guides/deep-recovery.html)
e il [triage a livello di sistema](https://santhreal.github.io/keyhog/guides/system-wide-triage.html),
usa le loro guide dedicate perché la loro copertura e le regole di completamento
differiscono da una scansione normale del repository.

## Benchmark dello scanner per segreti

Questi pannelli confrontano la policy di rilevamento, le richieste di esecuzione CPU e GPU,
il comportamento della cache incrementale e le richieste del daemon caldo. Ogni valore è
generato dallo snapshot del benchmark controllato. Lo snapshot vincola la versione dello scanner,
il digest dell'eseguibile, il digest del rilevatore, il corpus, l'host e il timestamp di esecuzione.
Usa le [prove complete del benchmark](#performance) per la provenienza dei concorrenti e
il richiamo per categoria.

### Accuratezza del rilevamento

<!-- BENCH:accuracy:start -->
KeyHog `KeyHog v0.5.70` ha scansionato il corpus **mirror**: 15.000 fixture, 3.000 positivi etichettati e 2.431.242 byte di input. Il manifest della chiave di risposta è stato escluso dall'albero di scansione. La riga usa la policy predefinita sul percorso esplicito Hyperscan/SIMD su **AMD Ryzen 9 9950X 16-Core Processor**.

| Precisione | Richiamo | F1 | Veri positivi | Falsi positivi | Falsi negativi |
|---:|---:|---:|---:|---:|---:|
| 0.9651 | 0.9027 | 0.9328 | 2.708 | 98 | 292 |

L'albero sorgente tracciato era pulito.
<!-- BENCH:accuracy:end -->

### Percorsi di esecuzione, preset e cache

<!-- BENCH:config:start -->
Misurato su **AMD Ryzen 9 9950X 16-Core Processor** con **NVIDIA GeForce RTX 5090**, 32 core logici, 15.000 fixture, 3.000 positivi etichettati e 2.431.242 byte di input. Scanner: `KeyHog v0.5.70`. L'albero sorgente tracciato era pulito.

#### Scansione completa per percorso di esecuzione

Tutte le righe usano la policy di rilevamento predefinita con cache incrementale e daemon disattivato. La riga automatica registra la policy richiesta, ma il risultato del benchmark non vincola il percorso persistente selezionato, quindi non è una prova di routing. Le righe GPU includono l'acquisizione e l'avvio completo dello scanner su questo piccolo corpus; non sono misurazioni di crossover del kernel GPU.

| Percorso richiesto | Wall | Throughput | RSS di picco | 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 |
| Automatico | 1,46 s | 1,59 MB/s | 634 MiB | 0.9328 |

#### Policy di rilevamento su Hyperscan/SIMD

Il percorso, la cache, lo stato del daemon, il corpus e l'host rimangono fissi. I preset cambiano il lavoro di rilevamento, quindi confronta precisione e richiamo oltre al tempo.

| Policy | Wall | Precisione | Richiamo | F1 | Risultati |
|---|---:|---:|---:|---:|---:|
| Veloce | 737 ms | 0.9700 | 0.8837 | 0.9248 | 2.738 |
| Predefinita | 860 ms | 0.9651 | 0.9027 | 0.9328 | 2.816 |
| Profonda | 861 ms | 0.9645 | 0.9067 | 0.9347 | 2.845 |
| Precisione | 849 ms | 0.9590 | 0.6397 | 0.7674 | 2.001 |

#### Rerun incrementale caldo

Il benchmark popola l'indice Merkle BLAKE3, quindi cronometra la seconda scansione identica. Il piccolo albero sintetico cambia poco perché l'avvio dello scanner domina; misura il tuo repository prima di affermare un'accelerazione.

| Policy predefinita Hyperscan/SIMD | Wall | Throughput | RSS di picco |
|---|---:|---:|---:|
| Cache disattivata | 860 ms | 2,70 MB/s | 416 MiB |
| Cache incrementale calda | 617 ms | 3,76 MB/s | 457 MiB |
<!-- BENCH:config:end -->

### Richieste del daemon caldo

<!-- BENCH:daemon:start -->
Un file regolare deterministico da 8 MiB (`sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5`) è stato scansionato una volta in-process e una volta tramite un daemon di proprietà dopo una richiesta di riscaldamento. Il tempo del daemon è la richiesta del client; l'RSS del daemon appartiene al server residente.

| Percorso esplicito | In process | Daemon caldo | Caldo / one-shot | RSS in-process | RSS 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 |

Queste righe coprono il percorso caldo a file singolo. Il percorso di massa accetta anche batch limitati di directory e sorgenti remote; il suo percorso incrementale del filesystem è misurato separatamente.
<!-- BENCH:daemon:end -->
<!-- BENCH:scaling:BEGIN -->
### Scalabilità di CPU, lettore, storage, dimensione e partizione

Generato da `make -C benchmarks readme-scaling` da `benchmarks/reports/readme-scaling.json`. L'harness ha eseguito 3 prove misurate dopo 1 riscaldamento con routing `simd` esplicito e daemon disattivato. La scalabilità dei worker usa una cache di pagina client calda per isolare il lavoro della CPU. Le righe di lettore, dimensione del corpus, storage e partizione richiedono l'evizione della pagina pulita con `posix_fadvise` dove la piattaforma lo supporta; lo snapshot registra la policy su ogni riga. Ogni carico di lavoro è byte-deterministico e privo di risultati.

Host: `AMD Ryzen 9 9950X 16-Core Processor`, 32 core logici effettivi, 94.140 MiB di RAM, `Linux 6.17.0-19-generic`. Evidenza: `clean`, binario `274b045489c4`.

#### Scalabilità dei worker di scansione

---

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