Sito web · Documentazione · Architettura · Motore GPU Vyre

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

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

La maggior parte degli scanner di segreti si ferma alle corrispondenze regex CPU in un checkout del repository. KeyHog combina 926 rilevatori specifici per servizio, decodifica per credenziali occultate, evidenza sensibile al contesto e soppressione, verifica live tramite provider e supporto di prima classe per CUDA, Metal e WGPU tramite Vyre. La calibrazione misura ogni backend elegibile puramente Rust su CPU, Hyperscan/SIMD e GPU. Il routing automatico usa quindi il percorso più veloce con parità dimostrata per l'esatto host e la classe di carico di lavoro.

GPU è un vero backend	Scansiona la superficie d'attacco reale	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, acquisizioni HAR, raccolte Git ospitate e interi sistemi.	Decodifica base64, hex, URL, protobuf, multilinea e configurazioni strutturate prima di applicare evidenza, soppressione di esempi e baseline.	Verifica le credenziali idonee con le API dei provider, emetti SARIF o buste strutturate e preserva copertura esatta e semantica di uscita.
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 severità, evidenza, file e riga, remediation, risultati e stato di copertura" width="900" />
</p>

## Uno scanner di segreti costruito attorno alla GPU

KeyHog non affida poche espressioni regolari a uno shader di calcolo generico.
Il suo percorso GPU è costruito 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 in GPU. Batch di origine limitati producono posizioni di corrispondenza complete
per la stessa pipeline di conferma, soppressione, evidenza e reportistica
usata dai percorsi CPU e Hyperscan.

- **Tre peer GPU fisici.** CUDA, Metal nativo e WGPU portabile vengono
  acquisiti, misurati e riportati indipendentemente.
- **Parità esatta dei risultati.** La calibrazione rifiuta un candidato la cui
  identità del finding differisce dal percorso di riferimento. Una risposta sbagliata ma 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 le evidenze
  temporali misurate. Le scansioni normali non eseguono benchmark nel percorso critico.
- **Esecuzione residente.** I worker daemon mantengono lo stato compilato dei rilevatori e dell'acceleratore
  caldo per batch ripetuti di file, archivi, cronologia, remoti e cloud.
- **Nessuna via di fuga nascosta verso la CPU.** Un acceleratore selezionato esplicitamente che non riesce
  a inizializzarsi o a inviare lavoro fallisce in modo visibile, invece di restituire finding CPU sotto
  un'etichetta GPU.

L'installazione predefinita da crates.io usa il percorso CPU portabile in puro 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 il percorso misurato:```sh keyhog backend --self-test keyhog calibrate-autoroute --policy all keyhog backend --autoroute --json

La [guida ai backend](https://santhreal.github.io/keyhog/backends.html) documenta
le tabelle residenti, il modello di dispatcher limitato, il contratto di parità e le
prove riproducibili di crossover.

## Per iniziare

### Installazione e prima scansione

I due comandi sopra installano l'ultima release di crates.io ed eseguono la scansione
dell'albero corrente con la route puramente Rust portabile.

Fissa un ambiente CI a una release esatta con
`cargo install --locked --version '=0.5.79' 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 build da sorgente.

KeyHog esce con `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
per ogni risultato il livello di evidenza esatto, il codice motivo, il file, la riga, il
rilevatore e la remediation. Altri codici diversi da zero descrivono errori di input,
sistema, verifica o copertura; consulta il
[riferimento ai 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 il runner. Include I/O di basso livello, servizio daemon fatale, cache incrementale ed errori SIMD selezionati esplicitamente. |
| `4` `backend --self-test` o errore di manutenzione | Il controllo di integrità di installazione, riparazione, backend o autoroute richiesto non era sano. |
| `10` credenziali live | Almeno una credenziale è stata confermata come live. `update --check` usa inoltre questo codice quando esiste una release più recente. |
| `11` panic dello scanner | Scarta il risultato della scansione perché lo stato dello scanner non è affidabile. |
| `12` errore GPU richiesto | Un percorso GPU selezionato esplicitamente o richiesto non ha potuto essere eseguito. |
| `13` copertura incompleta | Una sorgente richiesta non è riuscita 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, applica il gate:**

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 acquisisce un'istantanea dei finding revisionati ed esce con 0 senza stamparli. Committa quel file, poi usa il secondo comando per riportare solo le identità dei nuovi finding. Una voce di baseline corrisponde sul detector e sul valore della credenziale, mai sul percorso del file, quindi spostare un segreto registrato non fa fallire il gate, ma ruotarlo sì. Le credenziali modificate e la copertura incompleta rimangono visibili. Il percorso completo, incluse le partizioni monorepo, è Fallisci solo su nuovi segreti.

Per la prossima scansione, usa il cookbook di ricette o i comandi copiabili in Scegli il flusso di lavoro giusto. Puoi scansionare la cronologia Git, le immagini dei container, i bucket cloud, le raccolte di repository, URL e un'intera macchina senza cambiare strumenti.

Sorveglia i repository per scansioni pre-commit veloci

Registra un repository con il daemon perpetuo KeyHog per il rilevamento rapido di 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

Consulta la [guida al perpetual guard](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'Action esegue la scansione dell'albero estratto, fallisce in presenza di risultati a high o critical, carica SARIF su Code Scanning e conserva il report come artefatto del workflow. Anche gli errori di installazione, copertura, backend e pubblicazione del report fanno fallire il job.

Usa la guida per GitHub Action per input, output, adozione della baseline, partizioni monorepo, verifica e comportamento in caso di errore. Usa la guida CI per job GitLab, CircleCI, Jenkins, Buildkite e shell generici. Usa la guida alla scansione di massa 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 essere esposti, non solo dei file sorgente tracciati. Usa un report per ogni confine così la CI mantiene copertura e stato di errore esatti.

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 che non sono presenti nell'albero sorgente atteso.
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 senza limiti.
GitHub issues, pull request, discussioni, wiki e gist	`keyhog scan --github-collaboration owner/repo --github-all` esegue la scansione di ogni superficie di collaborazione al di fuori del checkout.
Configurazione di agenti AI e MCP	`keyhog scan ~/.config ~/.claude ~/.codex` applica alla configurazione locale degli strumenti lo stesso pipeline di rilevamento, decodifica, evidenze e report.
Layer delle 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` preserva nel report finale la copertura di paginazione, oggetti e limiti di byte del provider.
Intero host di sviluppo	`sudo keyhog scan-system --space 50G` rileva filesystem montati e cronologia Git raggiungibile entro un budget di archiviazione rigido.

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

Scegli il workflow giusto

Scegli prima il confine della sorgente. Un preset modifica il lavoro di rilevamento, mentre un backend modifica 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 del tipo scan everything. Una revisione completa del parco asset 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 riuso	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 di worker basato sui core CPU. Aggiungi `--incremental` per scansioni ripetute dello stesso albero fidato.	Solo file correnti. Non aggiunge la cronologia Git.
Gate per commit in stage	`keyhog scan --git-staged` o `keyhog hook install`	Legge i blob esatti dell'indice, quindi le modifiche non in stage non possono cambiare il risultato.	Solo contenuto in stage. Esegui separatamente una scansione dell'albero di lavoro quando i byte locali non in stage sono rilevanti.
Guardia permanente del repository	`keyhog guard add . --mode repo` poi `keyhog guard status .`	Registro root residente nel daemon con una 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 in stage e dell'albero di lavoro.
Gate per pull request GitHub	`santhreal/keyhog@v0`	L'Action installa, esegue la scansione, pubblica SARIF e un artefatto, quindi preserva lo stato di KeyHog.	Un singolo percorso estratto. Usa la scansione dell'inventario del provider per un'organizzazione.
GitLab, Jenkins, Buildkite o CI shell	`keyhog scan . --format json-envelope --output keyhog.json`	Salva report e codice di uscita in caso di 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.
Adottare 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 né 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 la discendenza del checkout corrente, quindi un ramo mai estratto viene perso senza lacune di copertura; `--git-blobs` raggiunge anche blob orfani, commit riscritti con amend, stash, note, messaggi di tag annotati e ref packed.
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, risposte o HAR	`keyhog scan --url https://api.example.com/config` o `keyhog scan capture.har`	Usa limiti di sorgente delimitati e conserva l'envelope finale.	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 provider selezionato per job. La paginazione o i limiti di 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 provider dichiarati. Non tutti i detector supportano la verifica.
Scansione di salute 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 locali montati. I mount di rete sono facoltativi e il tetto di spazio è rigido.
Inventario su Unix di directory, cronologia, archivi, remote o cloud con supporto GPU	Calibra l'autoroute, avvia `keyhog daemon start --mass`, poi esegui `keyhog scan --daemon=mass <SOURCE>`.	Trasmette batch delimitati attraverso un worker CPU, Hyperscan, CUDA, Metal o WGPU compilato. Aggiungi `--incremental` per alberi filesystem invariati già in cache. La ricevuta finale riporta totali esatti 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 sorgente supportato

Usa un comando per ogni 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 di continuo	`keyhog watch services/api deploy/`
Byte in stage, 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 compresse	`keyhog scan incoming/` (i membri supportati vengono espansi 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`
GitHub issues, 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 delimitato da un altro strumento	`producer \| keyhog scan --stdin` (usa `set -o pipefail` così un produttore che fallisce espone il proprio errore, non una scansione a zero byte)

Una scansione di directory semplice non legge i binari nativi. Ciascuno di essi diventa una lacuna di copertura binary (extension or content sniff), la scansione esce comunque con 0 e --no-default-excludes non modifica il comportamento, quindi passa --binary quando gli artefatti compilati sono in scope. Quel flag richiede una build con la feature binary, che l'installazione predefinita da crates.io include e la feature ridotta ci non include.

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

Il recupero di endpoint è delimitato e filtrato contro SSRF. Non è un crawler. Gli endpoint cloud privati e l'inoltro delle credenziali richiedono i rispettivi flag di trust espliciti. I token del provider vanno nelle variabili d'ambiente documentate, non negli argomenti di processo.

Usa il selettore di workflow per i dettagli su sorgenti e policy, la guida GitHub Action per il gate di repository mantenuto, la guida CI diretta per report durevoli e gestione dell'uscita, e la guida alla scansione di massa per partizionamento e aggregazione. Il ricettario copre container, archivi, URL, contenuti di collaborazione GitHub e sorgenti cloud.

Velocità e concorrenza senza congetture

Inizia con le impostazioni predefinite. Il programma di installazione storico verificato degli asset binari esegue la calibrazione da solo. 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 l'host, il binario, il corpus di detector, il driver o le classi di carico di lavoro cambiano:```sh keyhog calibrate-autoroute --policy all keyhog backend --autoroute --json

| Control | Use it for | Keep this invariant |
|---|---|---|
| Calibrated `--backend auto` | Routine CPU, Hyperscan, or GPU selection. | An explicit backend is a diagnostic override, not a faster default. |
| `--threads <N>` | Reserving CPU capacity on a shared runner. Dedicated hosts should normally leave it unset so KeyHog uses the available cores. | Every value must be positive. Several concurrent KeyHog processes each own a worker pool, so divide the host budget across partitions. |
| `--reader-threads <N>` | Measured storage pipelines where reader work, not scanning, is the bottleneck. | The default derives from the scan worker pool. Leave it unset until profiling shows a reader bottleneck. |
| `--incremental` and `--incremental-cache <PATH>` | Repeated scans of the same trusted tree. | Do not share one index across unrelated repositories or untrusted jobs. |
| Provider or repository partitions | Concurrent estate scanning and independent retries. | Preserve one terminal envelope and raw exit code per partition. Do not concatenate findings and discard coverage state. |
| `--verify-concurrency`, `--verify-rate`, and `--verify-batch` | Bounding live provider checks independently of file scanning. | Verification sends credential-derived requests. Provider rate limits, not CPU count, own this concurrency. |
| Mass daemon | TB-scale directory, history, archive, remote, or cloud streams on one Unix worker. | Each frame is limited to 8 MiB and 1,024 chunks. The daemon serializes fragment state and returns an exact CPU/GPU execution receipt. |
| `--fast`, default, `--deep`, or `--precision` | Selecting an explicit detection-cost and recall policy. | These presets are mutually exclusive and change coverage. They are not interchangeable speed knobs. |

Inspect the resolved policy with `keyhog config --effective`. Use `--profile`
to measure fixed scanner stages and the complete operator run before you change
reader, batch, or channel-depth controls. The low-overhead report records
source, backend, cache, workload, thread, input, state-transition, CPU-time,
peak memory, exact binary SHA-256, enabled-feature SHA-256, target triple, build
profile, compiler, allocator, linked-backend SHA-256, detector-corpus SHA-256,
enabled-detector BLAKE3, compiled-plan BLAKE3, hashed detector-provenance,
complete resolved-configuration BLAKE3, performance-policy BLAKE3, preset,
applied protection state, source adapters, hashed source-target BLAKE3,
hashed source-partition BLAKE3, raw source bytes, source-unit fanout,
decode-derived bytes, completed backend-dispatch bytes, and stable size/fanout
buckets. Byte domains that their source adapter cannot yet distinguish remain
explicitly unavailable instead of becoming measured zeroes. The report does
not record source content, credential values, raw paths, raw URLs, or raw
configuration values. Use `--perf-trace` only for expensive per-pattern and
backend diagnostic counters.
Keep advanced pipeline controls unset unless a reproducible measurement on the
target worker shows an improvement.

For a recurring full repository scan:```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 dei worker.

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

## Benchmark dello scanner di segreti

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

### Precisione di 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 delle chiavi 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**.

| Precision | Recall | F1 | True positives | False positives | False negatives |
|---:|---:|---:|---:|---:|---:|
| 0.9651 | 0.9027 | 0.9328 | 2,708 | 98 | 292 |

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

### Percorsi di esecuzione, preimpostazioni 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 disattivati. La riga automatica registra la policy richiesta, ma il risultato del benchmark non vincola il percorso persistito 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 |
| Pure-Rust CPU | 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 |
| Automatic | 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. Le preimpostazioni modificano il lavoro di rilevamento, quindi confronta precisione, recall e anche il tempo.

| Policy | Wall | Precision | Recall | F1 | Risultati |
|---|---:|---:|---:|---:|---:|
| Fast | 737 ms | 0.9700 | 0.8837 | 0.9248 | 2,738 |
| Default | 860 ms | 0.9651 | 0.9027 | 0.9328 | 2,816 |
| Deep | 861 ms | 0.9645 | 0.9067 | 0.9347 | 2,845 |
| Precision | 849 ms | 0.9590 | 0.6397 | 0.7674 | 2,001 |

#### Riesecuzione incrementale a caldo

Il benchmark popola l'indice Merkle BLAKE3, poi 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 aumento di velocità.

| Policy predefinita Hyperscan/SIMD | Wall | Throughput | RSS di picco |
|---|---:|---:|---:|
| Cache disattivata | 860 ms | 2.70 MB/s | 416 MiB |
| Cache incrementale a caldo | 617 ms | 3.76 MB/s | 457 MiB |
<!-- BENCH:config:end -->

### Richieste warm del daemon

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

| Percorso esplicito | Nel processo | Daemon a caldo | A caldo / one-shot | RSS in-process | RSS del daemon |
|---|---:|---:|---:|---:|---:|
| Hyperscan/SIMD | 323 ms | 106 ms | 0.33× | 63 MiB | 74 MiB |
| Pure-Rust CPU | 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 a file singolo a caldo. Il percorso massivo accetta anche batch limitati di directory e sorgenti remote; il suo percorso incrementale sul filesystem viene misurato separatamente.
<!-- BENCH:daemon:end -->
<!-- BENCH:scaling:BEGIN -->
### Scalabilità di CPU, reader, storage, dimensione e partizioni

Generato da `make -C benchmarks readme-scaling` da `benchmarks/reports/readme-scaling.json`. L'harness ha eseguito 3 prove misurate dopo 1 riscaldamento con `simd` esplicito e routing del daemon disattivato. La scalabilità dei worker usa una cache di pagine client a caldo per isolare il lavoro della CPU. Le righe di reader, dimensione del corpus, storage e partizioni richiedono l'evizione delle pagine pulite con `posix_fadvise` dove la piattaforma la supporta; lo snapshot registra la policy su ogni riga. Ogni carico di lavoro è deterministico a livello di byte 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

| Worker | Thread reader | Wall mediano | Wall p95 | Throughput | Speedup | Efficienza | RSS di picco mediana |
|---:|---:|---:|---:|---:|---:|---:|---:|
| 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 |

#### Scalabilità del reader del filesystem

| Worker di scansione | Thread reader | Wall mediano | Wall p95 | Throughput | Relativo a 1 reader | RSS di picco mediana |
|---:|---:|---:|---:|---:|---:|---:|
| 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 |

#### Scalabilità della dimensione del corpus

| Corpus | File | Byte esatti | Wall mediano | Wall p95 | Throughput | RSS di picco mediana |
|---|---:|---:|---:|---:|---:|---:|
| small | 256 | 8 MiB | 869.9 ms | 886.1 ms | 9.2 MiB/s | 111.1 MiB |
| medium | 1,024 | 64 MiB | 1,859.9 ms | 1,874.8 ms | 34.4 MiB/s | 126.3 MiB |
| large | 2,048 | 256 MiB | 5,214.9 ms | 5,321.7 ms | 49.1 MiB/s | 137.1 MiB |

#### Scalabilità dello storage

| Classe di storage | Filesystem | ID dispositivo | Wall mediano | Wall p95 | Throughput | Relativo al primo storage | RSS di picco mediana |
|---|---|---:|---:|---:|---:|---:|---:|
| 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 |

#### Scalabilità delle partizioni concorrenti

| Processi | Worker per processo | Worker aggregati | File totali | Byte totali | Wall mediano | Throughput aggregato | Speedup | RSS di picco sommati mediana |
|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| 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 |

Queste righe sono misurazioni, non costanti di ottimizzazione universali. Esegui il generatore sull'host e sullo storage di destinazione. Usa il punto di flesso in cui il throughput smette di migliorare, quindi riserva CPU e memoria per il runner CI o il layer di orchestrazione.
<!-- BENCH:scaling:END -->

Riproduci tutti e quattro i gruppi di benchmark con `make -C benchmarks readme-matrix`.
Il comando misura la matrice richiesta e fallisce se una qualsiasi riga richiesta di CPU,
Hyperscan, CUDA, Metal, WGPU, preset, cache, daemon, thread, reader, storage, dimensione
del corpus o partizione non è disponibile. Usa
`make -C benchmarks readme-matrix-check` per verificare che entrambi gli snapshot, i report
e il README concordino.

### Scegliere una configurazione di scansione

Inizia con la policy predefinita e il routing automatico calibrato. Modifica un solo asse
solo quando il flusso di lavoro lo richiede:

| Flusso di lavoro | Policy di rilevamento | Esecuzione e riutilizzo | Controllo aggiuntivo |
|---|---|---|---|
| Prima scansione del repository | Predefinita | Calibrato `auto`; `--daemon=auto` | Rivedi tutti i risultati prima di aggiungere le soppressioni. |
| Scansione ripetuta di albero locale o CI | Predefinita | Calibrato `auto`; `--incremental` | Persisti la cache incrementale solo tra scansioni dello stesso albero attendibile. |
| Ciclo di feedback breve | `--fast` | Calibrato `auto`; `--incremental` opzionale | Accetta una copertura ridotta di decodifica, entropia e ML. Esegui la policy predefinita prima del merge. |
| Recovery con recall massimo | `--deep` | Nel processo | Deep è mutuamente esclusivo con fast e precision e non è idoneo al daemon. |
| Inventario di grandi dimensioni a basso rumore | `--precision` | Nel processo per raccolte di repository, cronologia e sorgenti cloud | La preimpostazione alza le soglie minime di confidenza e disabilita la scoperta per entropia. Può mancare credenziali a confidenza più bassa. |
| Inventario su Unix di directory, cronologia, archivi, sorgenti remote o cloud su scala TB | Predefinita | `keyhog daemon start --mass`, poi `--daemon=mass` | I batch rimangono limitati a 8 MiB e 1.024 chunk. Conserva il report di copertura del terminale e la ricevuta di esecuzione GPU. |
| Validazione live delle credenziali | Predefinita | Nel processo | Aggiungi `--verify` esplicitamente. La verifica invia richieste derivate dalle credenziali ai provider. |
| Scansione Linux senza swap | Predefinita più `--lockdown` | Nel processo; cache incrementale disabilitata | Lockdown rifiuta la verifica, i segreti in chiaro, la modalità fast e le opzioni che riducono la completezza. |

`--fast`, `--deep` e `--precision` sono preimpostazioni di rilevamento mutuamente esclusive.
`--lockdown` è una modalità di esecuzione fail-closed, non una quarta preimpostazione. I valori
espliciti di `--backend` sono diagnostici e override del benchmark. Non sostituiscono
l'evidenza persistita del percorso più veloce e corretto usata dal routing automatico. Vedi
[Configurazione](https://santhreal.github.io/keyhog/reference/configuration.html),
[calibrazione dell'autoroute](https://santhreal.github.io/keyhog/reference/autoroute-calibration.html),
[daemon e scansioni a caldo](https://santhreal.github.io/keyhog/workflows/daemon.html),
e [hardening](https://santhreal.github.io/keyhog/hardening.html) per i contratti
completi.

## Come funziona KeyHog

KeyHog compila i suoi 926 rilevatori in un piano condiviso di attivazione ed estrazione,
decodifica le codifiche annidate prima del matching e applica punteggi, evidenze e soppressioni
per singolo rilevatore. La CPU Pure-Rust (`cpu-fallback`) è sempre disponibile.
Il percorso Hyperscan (`simd-regex`) usa Hyperscan quando questa funzionalità è presente;
le build portabili usano il percorso CPU. CUDA (`gpu-cuda-region-presence`), Metal
(`gpu-metal-region-presence`) e WGPU (`gpu-wgpu-region-presence`) sono pari
in un selettore autoroute basato su prove, non una catena di fallback. La calibrazione misura
ogni peer idoneo e persiste il percorso più veloce i cui risultati completi corrispondono
al percorso di riferimento per l'esatto binario, lo stato di rilevatori e configurazione,
host, acceleratore e classe di carico di lavoro. Una decisione mancante, obsoleta, non valida
o incompleta interrompe una scansione automatica prima dell'esecuzione e segnala come ricalibrare.
Non sostituisce mai silenziosamente un altro backend.

Vedi [Architettura](https://santhreal.github.io/keyhog/architecture.html) per la
mappa del repository, la direzione delle dipendenze, la pipeline da byte a risultati e i punti
di ingresso per il profiling. Vedi [Backend e routing](https://santhreal.github.io/keyhog/backends.html)
per i contratti di esecuzione e [Calibrazione autoroute](https://santhreal.github.io/keyhog/reference/autoroute-calibration.html)
per parità, identità del carico di lavoro, ciclo di vita della cache e procedure di riparazione.

**Documentazione completa:** [santhreal.github.io/keyhog](https://santhreal.github.io/keyhog/) - installazione, prima scansione, formati di output, internals di rilevamento, soppressioni, verifica, integrazione pre-commit + CI, riferimento CLI, autoroute, codici di uscita, variabili d'ambiente e contributi. Codice sorgente in `docs/`.

---

## Installare KeyHog

Installa la versione corrente di crates.io:```sh
cargo install keyhog --locked

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

Conferma la build installata:```sh
keyhog --version --full
keyhog doctor

Usa la guida all'installazione per i requisiti della toolchain Rust, i profili delle funzionalità e le dipendenze runtime specifiche per piattaforma.

Cosa rileva

926 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 chiave segreta Razorpay richiede la key ID vicina.
Forge di codice sorgente: 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 attuale hf_ sia i token legacy api_org_.
Password manager: chiavi segrete dell'account 1Password (A3- seguito da cinque o sei componenti alfanumeriche maiuscole segmentate).
Database: stringhe di connessione Postgres, MongoDB Atlas, Supabase service-role, PlanetScale, Neon, Turso, MySQL, URL Redis.
Generico + rilevamento dell'entropia: API_KEY=<blob-ad-alta-entropia> rileva credenziali senza un rilevatore dedicato, 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 (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 ne illustra il procedimento.

keyhog explain <id> mostra l'intera specifica di qualsiasi rilevatore: pattern, parole chiave, endpoint di verifica, oltre a una guida alla rotazione e alla rimediation passo-passo specifica per il servizio, così un riscontro non è mai una scatola nera:

$keyhog explain github-classic-pat: dump della specifica del rilevatore (pattern ghp_[A-Za-z0-9]{36}, parole chiave, URL di verifica) seguito dalla guida alla rotazione GitHub e dalla rimediation passo-passo$

Sfoglia la creazione e l'ispezione dei rilevatori nella riferimento dei rilevatori, oppure interroga il corpus installato con keyhog detectors --search <term> --verbose.

Perché maggiore recall, meno falsi positivi

Scansione con decodifica. Manifest Secret di Kubernetes, notebook Jupyter, payload JWT, env codificate in base64, valori Helm e blob auth: di docker-config. Il preprocessore strutturato tratta le azioni Helm bilanciate come valori di rendering inerti 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 place e fornisce il testo in chiaro a ogni rilevatore a valle. I rilevatori non devono reimplementare la decodifica ciascuno. Le scansioni con decodifica recuperano anche espressioni JavaScript senza effetti collaterali come XOR di array di byte e AES-256-CBC quando tutto il materiale di recupero è incorporato, incluse le wrapper rigorose con passphrase saltate CryptoJS/OpenSSL. KeyHog non esegue mai il codice sorgente.
Riassemblaggio multilinea. Continuazione "sk-proj-" + \ in JavaScript, stringhe multilinea YAML, continuazione con backslash nei Makefile, output templati Helm / Jinja: tutto riassemblato prima del match regex.
Validazione dei companion. I companion obbligatori limitano i rilevatori ad alto rumore. Una chiave API Twilio senza il suo secret API viene saltata. I companion opzionali arricchiscono il punteggio delle evidenze o la verifica. Il rilevamento della access-key AWS non richiede il suo secret, ma il secret è necessario per la verifica live.
Risoluzione tra rilevatori. Il TOML di un rilevatore può richiedere, rifiutare o assorbire risultati delimitati di un altro rilevatore. La risoluzione resta deterministica indipendentemente dall'ordine di input; target non validi, contraddizioni o cicli di dipendenza fanno fallire la compilazione del corpus.
Verdetti delle evidenze. Ogni riscontro 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 basati solo su entropia e contesti di test, documentazione, regole o identificatori restano evidenze di revisione. Un evidence_score opzionale integra il verdetto quando misurato. La soglia predefinita 0.40 controlla il livello minimo di confidenza interno dello scanner e rimane configurabile con --min-confidence.
Calibrazione bayesiana per rilevatore. keyhog calibrate --fp generic-api-key scrive una posteriori Beta(α,β). Le scansioni la 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 accidentale dell'host.

Prestazioni

Usa l'harness riproducibile in 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 dei rilevamenti

Corpus: mirror - 15000 fixture, 3000 positivi etichettati. Ogni scanner valutato in modo identico (regola di sovrapposizione SecretBench); il manifest con le risposte è 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

Provenienza dei risultati

Scanner	Versione scanner / digest eseguibile	Identità corpus	Identità host	Data esecuzione
KeyHog	version: KeyHog v0.5.70 Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c Detector Set: 926 (926-4168e2c6c93a16ca) Build Target: x86_64-linux ML Model Version: moe-v1-246a05b92bec9aa3 ML Model Card: recorded 2026-07-15; features 55; synthetic F1 0.971 / P 0.945 / R 0.999; real F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; zero-recall detectors 2/32; six-scanner differential unavailable executable SHA-256: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:29:39Z
TruffleHog	version: trufflehog 3.96.0 executable SHA-256: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:29:58Z
Kingfisher	version: kingfisher 1.94.0 executable SHA-256: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:29:50Z
Titus	version: Titus v1.1.20 (port Go di NoseyParker) executable SHA-256: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:30:03Z
Nosey Parker	version: noseyparker 0.24.0 Build Configuration: Build Timestamp: 2025-05-08T21:11:15.600909923Z Commit Timestamp: 2025-05-08T17:04:47.000000000-04:00 Commit Branch: HEAD Commit SHA: 61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Cargo Features: color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Debug: true Optimization: 3 Target Triple: x86_64-unknown-linux-gnu Build System: OS: Ubuntu OS Version: Linux (Ubuntu 22.04) CPU Vendor: AuthenticAMD CPU Brand: AMD EPYC 7763 64-Core Processor CPU Cores: 2 rustc Version: 1.86.0 rustc Channel: stable rustc Host Triple: x86_64-unknown-linux-gnu rustc Commit Date: 2025-03-31 rustc Commit SHA: 05f9846f893b09a1be1fc8560e33fc3c815cfecb rustc LLVM Version: 19.1 executable SHA-256: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:29:53Z
Betterleaks	version: betterleaks version dev executable SHA-256: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4`	mirror; 15.000 fixture; 3.000 positivi etichettati; 2.431.242 byte	hostname SHA-256/12: `82fcd9288623` Linux 6.17.0-19-generic AMD Ryzen 9 9950X 16-Core Processor	2026-08-11T01:29:43Z

Velocità e memoria

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

Confronto del recall per categoria

Fetta diagnostica del solo recall. Precision complessiva e F1 restano il contratto di confronto; i falsi positivi sono conteggiati nelle rispettive categorie.

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

Telemetria del recupero statico delimitato

Esecuzione selezionata: scanner KeyHog KeyHog v0.5.70 Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c Detector Set: 926 (926-4168e2c6c93a16ca) Build Target: x86_64-linux ML Model Version: moe-v1-246a05b92bec9aa3 ML Model Card: recorded 2026-07-15; features 55; synthetic F1 0.971 / P 0.945 / R 0.999; real F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; zero-recall detectors 2/32; six-scanner differential unavailable; 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
Supportata	0
Non supportata	0
Erronea	0

Motivo di rifiuto	Conteggio esatto
nessuno	0

Evidenza Bloom a bigrammi

Schema evidenza: 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:
Riscontri abilitati vs bypassati	IDENTICI; 977/977 riscontri
SHA-256 identità riscontro	`1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e`
Densità/stato Bloom	1793/65536 slot; `healthy`; saturazione a 39322

L'identità del riscontro lega rilevatore, file, riga, intervallo di byte e SHA-256 della credenziale; le credenziali in chiaro non vengono mai registrate.

Riproduci: make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog riesegue l'esatto set di esecuzioni mirror di KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog e Titus, inclusa la tabella differenziale Bloom CredData legata all'eseguibile; make -C benchmarks report rigenera le tabelle sopra e benchmarks/reports/. Consulta benchmarks/README.md per i corpora (mirror, competitor home-turf, Samsung/CredData) e la matrice backend/cache/daemon/OS/GPU.

Worker daemon di massa con GPU

Il daemon di massa Unix 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 delle policy di origine; il daemon legge e raccoglie i file nel proprio processo. Le sorgenti Git, binarie, remote e cloud che richiedono credenziali lato client usano frame a blocchi limitati 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

`--daemon=mass` è un percorso obbligatorio. Non ritenta mai all'interno del processo. Ogni batch è
limitato a 8 MiB e 1.024 blocchi, indipendentemente dalla dimensione totale dell'input. Conserva
l'inviluppo di copertura, lo stato di uscita e la ricevuta di esecuzione terminale per ogni
partizione dell'inventario.

Vedi [ciclo di vita del daemon, routing e ricevute](https://santhreal.github.io/keyhog/workflows/daemon.html)
e [partizionamento dell'inventario](https://santhreal.github.io/keyhog/guides/mass-scanning.html).

## Triage delle credenziali a livello di sistema```sh
sudo keyhog scan-system --space 50G
sudo keyhog scan-system --include-network --output system-findings.json

scan-system è un audit local-host limitato, non un sostituto del partizionamento dell'inventario di repository o cloud. Si limita in base al totale di byte scansionati piuttosto che al percorso: --space è il limite massimo e i filesystem montati in rete vengono saltati a meno che non si passi --include-network. Esaminare il comportamento di mount, filesystem di rete, limite di spazio e privilegi prima di eseguirlo. Vedi triage a livello di sistema.

Blindare le scansioni locali sensibili

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

Blocca la memoria corrente e futura, disabilita i core dump e la cache
incrementale, rimane nel processo, e rifiuta la verifica, l'output in chiaro,
la modalità veloce e le opzioni che riducono la completezza. Fallisce su
piattaforme non supportate o in caso di memoria bloccata insufficiente. Vedi
[hardening e gestione dei dati](https://santhreal.github.io/keyhog/hardening.html).

## Usa KeyHog come libreria Rust```rust
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();

I metodi predefiniti della libreria sono riferimenti CPU portatili deterministici. I metodi backend espliciti 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 o usa i valori finali VerifiedFinding prima dei confini JSON, log, disco o rete.

La guida all'architettura definisce la proprietà delle crate, i contratti dei backend, le ricevute di recupero, gli helper delle sorgenti e i confini sicuri per la segnalazione. 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"

L'ordine di risoluzione è: default integrati, configurazione utente, configurazione del repository, ambiente dove documentato, e infine override espliciti da CLI. Chiavi sconosciute e combinazioni non valide causano un errore prima della scansione. Esegui `keyhog config --effective` per ispezionare la policy risolta senza esporre le credenziali del proxy.
Le voci oltre `expires` fanno fallire il caricamento dell'allowlist prima della scansione.

Vedi [configurazione e precedenza](https://santhreal.github.io/keyhog/reference/configuration.html) per ogni chiave e [variabili d'ambiente](https://santhreal.github.io/keyhog/reference/env.html) per input di credenziali e runtime.

## Architettura

KeyHog mantiene l'orchestrazione al confine e il comportamento di dominio nelle librerie:```text
sources -> scanner -> suppression/evidence -> reporting
                 \-> optional verifier
CLI and Action own process, transport, and exit semantics.

Le definizioni dei detector restano dati in detectors/. keyhog-core gestisce i tipi di detector e di finding, keyhog-scanner gestisce i backend di corrispondenza ed esecuzione, keyhog-sources gestisce l'acquisizione degli input, keyhog-verifier gestisce i controlli live e keyhog-cli gestisce i flussi di lavoro dell'operatore.

Inizia con la guida all'architettura per la mappa del repository, la direzione delle dipendenze, la pipeline da byte a finding, la proprietà del routing e i punti di ingresso per il profiling.

Ispezionare ed estendere l'installazione```sh

keyhog detectors --search aws --verbose keyhog explain aws-access-key keyhog backend --autoroute --json keyhog completion zsh

The [CLI reference](https://santhreal.github.io/keyhog/reference/cli.html)
elenca ogni comando, flag, valore predefinito generato e stato di uscita. Usa
`keyhog --help` e `keyhog <command> --help` per la versione esatta installata.

## Contribuire

- **Nuovo detector?** Metti un TOML in [`detectors/`](https://github.com/santhreal/keyhog/blob/HEAD/detectors/) e apri una
  PR. La guida per i contributori ([`CONTRIBUTING.md`](https://github.com/santhreal/keyhog/blob/HEAD/CONTRIBUTING.md))
  contiene lo schema e un esempio completo.
- **Bug / segreto mancato / falso positivo?** Apri una segnalazione con la
  forma del credential oscurato e l'id del detector; ogni segnalazione diventa
  una fixture di test permanente in
  [`crates/scanner/tests/contracts/`](https://github.com/santhreal/keyhog/blob/HEAD/crates/scanner/tests/contracts/).
- **Comportamento delle release?** Ogni esecuzione CI riuscita su `main`
  incrementa la versione patch, genera i changelog e pubblica tutte e sei le
  crate su crates.io. Aggiungi un frammento opzionale in [`changes/`](https://github.com/santhreal/keyhog/blob/HEAD/changes/)
  per una nota precisa. La [guida alle release](https://santhreal.github.io/keyhog/releasing.html) copre
  la transazione automatica e il recupero da upload falliti.
- **Problema di sicurezza in KeyHog stesso?** Non aprire una segnalazione
  pubblica; usa [la segnalazione privata delle vulnerabilità di GitHub](https://github.com/santhreal/keyhog/security/advisories/new).
  Se quel modulo non è disponibile, scrivi a `[email protected]`; PGP non è richiesto.

[Changelog](https://github.com/santhreal/keyhog/blob/HEAD/CHANGELOG.md). [Segnalazioni aperte](https://github.com/santhreal/keyhog/issues).

## Crediti

KeyHog si basa sul lavoro precedente sulla scansione dei segreti. Idee prese in prestito da:

- [TruffleHog](https://github.com/trufflesecurity/trufflehog): ampiezza dei detector e semantica di verifica
- [Betterleaks](https://github.com/betterleaks/betterleaks): efficienza dei token e soppressione dei falsi positivi
- **Titus:** ergonomia della scansione e calibrazione della gravità

Grazie a questi progetti e ai loro contributori.

## Licenza

Licenza: MIT OR Apache-2.0.

Termini: [MIT](https://github.com/santhreal/keyhog/blob/HEAD/LICENSE-MIT) e [Apache-2.0](https://github.com/santhreal/keyhog/blob/HEAD/LICENSE-APACHE). Questa doppia licenza copre il codice e
i TOML dei detector. L'uso commerciale, l'incorporamento, i fork e i servizi ospitati sono
consentiti con entrambe le licenze.

---

## Storico delle stelle

<p align="center">
  <a href="./metrics/stars.json"><img src="https://raw.githubusercontent.com/santhreal/keyhog/HEAD/metrics/stars.svg" alt="Storico delle stelle GitHub di KeyHog da osservazioni di proprietà del repository" width="960" /></a>
</p>

<p align="center">
  <sub>Generato dalle <a href="./metrics/stars.json">osservazioni UTC del conteggio pubblico delle stelle di GitHub</a>. Il repository memorizza il primo punto e ogni transizione successiva del conteggio. Le riesecuzioni nello stesso giorno sostituiscono il punto di quel giorno e i conteggi invariati non creano alcun commit.</sub>
</p>

keyhog v0.5.73-action

Categorie