<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="KeyHog-Scan, der Schweregrad, Konfidenz, Datei und Zeile, Behebung, Ergebnisse und Abdeckungsstatus anzeigt" width="900" />
</p>

## Ein Secret-Scanner, der um die GPU herum gebaut ist

KeyHog übergibt nicht bloß ein paar reguläre Ausdrücke an einen generischen Compute-Shader.
Sein GPU-Pfad basiert auf [Vyre](https://github.com/santhreal/vyre), einem Rust-GPU-Compute-Substrat,
das parallel zu KeyHog entwickelt wurde. Detektor-Trigger werden zu unveränderlichen
GPU-residenten Tabellen kompiliert. Begrenzte Quell-Batches erzeugen vollständige
Trefferpositionen für dieselbe Bestätigungs-, Unterdrückungs-, Konfidenz- und Berichtspipeline,
die auch von CPU- und Hyperscan-Routen verwendet wird.

- **Drei physische GPU-Peers.** CUDA, natives Metal und portables WGPU werden
  unabhängig erfasst, gemessen und gemeldet.
- **Exakte Ergebnisgleichheit.** Die Kalibrierung lehnt einen Kandidaten ab, dessen
  Befundidentität von der Referenzroute abweicht. Eine schnellere falsche Antwort gelangt
  nie in die Routing-Tabelle.
- **Dauerhafte Routen-Nachweise.** KeyHog zeichnet die Binärdatei, den Detektor-Korpus,
  die Konfiguration, die Workload-Klasse, den Host, den Beschleuniger, den Treiber und die
  gemessenen Zeitmessdaten auf. Normale Scans führen im heißen Pfad kein Benchmarking durch.
- **Residente Ausführung.** Daemon-Worker halten den kompilierten Detektor- und Beschleunigerzustand
  warm für wiederholte Datei-, Archiv-, Verlauf-, Remote- und Cloud-Batches.
- **Keine versteckte CPU-Ausweichmöglichkeit.** Ein explizit ausgewählter Beschleuniger, der
  nicht initialisiert werden kann oder keine Arbeit absetzen kann, schlägt sichtbar fehl,
  anstatt CPU-Befunde unter einem GPU-Label zurückzugeben.

Die Standardinstallation über crates.io nutzt die portable CPU-Route in reinem Rust, sodass sie
auf einem sauberen Rust-Host funktioniert. Aktiviere die drei GPU-Peers, ohne Hyperscan zu benötigen:```sh
cargo install --locked keyhog --no-default-features --features portable,gpu

Der [Backend-Leitfaden](https://santhreal.github.io/keyhog/backends.html) dokumentiert
die residenten Tabellen, das begrenzte Dispatch-Modell, den Paritätsvertrag und die reproduzierbaren
Crossover-Nachweise.

## Erste Schritte

### Installieren und ersten Scan ausführen

Die beiden obigen Befehle installieren die neueste crates.io-Version und scannen den aktuellen
Baum mit dem portablen reinen-Rust-Pfad.

Pinnen Sie eine CI-Umgebung auf eine exakte Version mit
`cargo install --locked --version '=0.5.75' keyhog`. KeyHog erfordert Rust 1.89
oder neuer. Siehe den [Installationsleitfaden](https://santhreal.github.io/keyhog/install.html)
für GPU-, Hyperscan-, CI-, portable und Source-Build-Profile.

KeyHog beendet sich mit `0`, wenn der Scan sauber ist, und mit `1`, wenn es Befunde oberhalb
Ihrer Schweregradschwelle meldet. Exit `1` bedeutet, dass der Scanner funktioniert hat. Prüfen Sie bei jedem Befund
Datei, Zeile, Detektor und Abhilfe, bevor Sie entscheiden, ob Sie die Anmeldeinformation entfernen,
rotieren oder unterdrücken. Andere Nicht-Null-Codes beschreiben Eingabe-,
System-, Verifikations- oder Abdeckungsfehler; siehe die
[Exit-Code-Referenz](https://santhreal.github.io/keyhog/reference/exit-codes.html).

Der vollständige Prozessvertrag lautet:

| Exit | Bedeutung |
|---|---|
| `0` sauber | Der Scan wurde ohne meldepflichtigen Befund oder Abdeckungsfehler abgeschlossen. |
| `1` Befunde | Es sind Befunde vorhanden, aber keiner wurde als live bestätigt. |
| `2` Bedienerfehler | Korrigieren Sie die Argumente, Konfiguration, den Detektor-Korpus oder die durch den Bediener korrigierbare Eingabe. |
| `3` Systemfehler | Reparieren Sie den Runner oder führen Sie ihn erneut aus. Dies umfasst Low-Level-I/O, fatale Daemon-Dienste, inkrementellen Cache und explizit ausgewählte SIMD-Fehler. |
| `4` `backend --self-test` oder Wartungsfehler | Der angeforderte Installations-, Reparatur-, Backend- oder autoroute-Health-Check war nicht erfolgreich. |
| `10` Live-Anmeldeinformationen | Mindestens eine Anmeldeinformation wurde als live bestätigt. `update --check` verwendet diesen Code auch, wenn eine neuere Version verfügbar ist. |
| `11` Scanner-Panik | Verwerfen Sie das Scan-Ergebnis, da der Scanner-Zustand nicht vertrauenswürdig ist. |
| `12` Erforderlicher GPU-Fehler | Ein explizit ausgewählter oder erforderlicher GPU-Pfad konnte nicht ausgeführt werden. |
| `13` Unvollständige Abdeckung | Eine angeforderte Quelle schlug fehl oder die Eingabeabdeckung war unvollständig, und kein Befund-Ergebnis hatte Vorrang. |
| `130` Unterbrochen | SIGINT oder Ctrl-C hat den Prozess unterbrochen. |

**Filtern, formatieren, gaten:**

Erstellen Sie eine Baseline, bevor Sie es als Filter verwenden:```sh
keyhog scan . --create-baseline .keyhog-baseline.json
keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json

Die Aktion scannt den ausgecheckten Baum, schlägt bei Funden mit Schweregrad `high` oder `critical` fehl, lädt SARIF in Code Scanning hoch und behält den Bericht als Workflow-Artefakt. Installations-, Abdeckungs-, Backend- und Berichts-Veröffentlichungsfehler lassen den Job ebenfalls fehlschlagen.

Nutzen Sie den [GitHub Action-Leitfaden](https://santhreal.github.io/keyhog/workflows/github-action.html) für Eingaben, Ausgaben, Baseline-Übernahme, Monorepo-Partitionen, Verifizierung und Fehlerverhalten. Nutzen Sie den [CI-Leitfaden](https://santhreal.github.io/keyhog/workflows/ci.html) für GitLab, CircleCI, Jenkins, Buildkite und generische Shell-Jobs. Nutzen Sie den [Massen-Scan-Leitfaden](https://santhreal.github.io/keyhog/guides/mass-scanning.html) für Repository-Organisationen, gehostete Git-Gruppen, Cloud-Buckets und partitionierte Inventare.

## Scan-Oberflächen, die andere Tools als separate Produkte behandeln

KeyHog scannt Bytes an der Grenze, an der sie leaken können, nicht nur versionierte Quelldateien. Verwenden Sie einen Bericht pro Grenze, damit die CI die exakte Abdeckung und den Fehlerzustand behält.

| Gefährdungsfläche | Beispiel |
|---|---|
| Finales Paket-Artefakt | Führen Sie `npm pack` aus und scannen Sie dann das erzeugte `.tgz` mit `keyhog scan package.tgz`. Die Archiv-Entpackprüfung prüft generierte Dateien, Source Maps, Fixtures und Metadaten, die im erwarteten Quellbaum fehlen. |
| Bereitgestellte Browser-Anwendung | `keyhog scan --url https://app.example.com/assets/app.js` folgt begrenztem JavaScript, Source-Map-, WASM- und Antwort-Decoding, ohne den Scanner in einen unbegrenzten Crawler zu verwandeln. |
| GitHub Issues, Pull Requests, Discussions, Wikis und Gists | `keyhog scan --github-collaboration owner/repo --github-all` scannt jede Kollaborationsfläche außerhalb des Checkouts. |
| KI-Agent- und MCP-Konfiguration | `keyhog scan ~/.config ~/.claude ~/.codex` wendet dieselbe Detektor-, Decode-, Konfidenz- und Berichts-Pipeline auf lokale Tool-Konfiguration an. |
| Container-Image-Ebenen | `keyhog scan --docker-image registry.example.com/team/app:v1` scannt den Image-Inhalt, der ausgeführt wird, einschließlich Dateien, die während des Builds hinzugefügt wurden. |
| Cloud-Objekt-Inventare | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` oder `--azure-container-url URL` erhält Provider-Paginierung, Objekt- und Byte-Limit-Abdeckung im Terminalbericht. |
| Gesamter Entwicklungs-Host | `sudo keyhog scan-system --space 50G` entdeckt gemountete Dateisysteme und erreichbare Git-Historie unter einem festen Speicherbudget. |

Diese Routen teilen einen gemeinsamen Erkennungs- und Berichtsvertrag. Ein quellspezifischer Fehler kann sich nicht stillschweigend in einen engeren lokalen Scan verwandeln.

## Wählen Sie den richtigen Workflow

Wählen Sie zuerst die Quellgrenze. Ein Preset ändert die Erkennungsarbeit, während ein Backend die Ausführung ändert. Keines von beiden erweitert einen Working-Tree-Scan auf Git-Historie, ein Provider-Inventar, Cloud-Speicher oder eine Host-Prüfung.

Es gibt keine ehrliche `scan everything`-Abkürzung. Eine vollständige Bestandsprüfung führt die relevanten Grenzen unten als separate Jobs aus und behält jeden `json-envelope`-Bericht mit seinem rohen Exit-Code.

| Bedarf | Beginnen Sie mit | Durchsatz und Wiederverwendung | Abdeckungsgrenze |
|---|---|---|---|
| Schnelles lokales Feedback | `keyhog scan . --fast --incremental` | Nutzt Hashes unveränderter Dateien erneut. Das Fast-Preset überspringt Decode-, Entropie- und ML-Arbeit. | Führen Sie vor dem Merge die Standardrichtlinie aus, da fast absichtlich enger ist. |
| Vollständiger Repository-Scan | `keyhog scan .` | Kalibriertes `auto` und der CPU-Core-Worker-Standard. Fügen Sie `--incremental` für wiederholte Scans desselben vertrauenswürdigen Baums hinzu. | Nur aktuelle Dateien. Es fügt keine Git-Historie hinzu. |
| Staged-Commit-Gate | `keyhog scan --git-staged` oder `keyhog hook install` | Liest exakte Index-Blobs, sodass ungestagte Änderungen das Ergebnis nicht verändern können. | Nur gestagter Inhalt. Führen Sie einen Working-Tree-Scan separat aus, wenn lokale ungestagte Bytes relevant sind. |
| Dauerhafter Repository-Schutz | `keyhog guard add . --mode repo` und dann `keyhog guard status .` | Daemon-residentes Root-Registry mit einer 7-Zustands-Maschine, sauberem Attestations-Cache und Richtlinien-Identitätsverfolgung. | Erfordert einen laufenden Daemon. Der Guard ergänzt, ersetzt nicht, gestagte und Working-Tree-Scans. |
| GitHub-Pull-Request-Gate | `santhreal/keyhog@v0` | Die Aktion installiert, scannt, veröffentlicht SARIF und ein Artefakt und bewahrt dann den Status von KeyHog. | Ein ausgecheckter Pfad. Verwenden Sie Provider-Inventar-Scans für eine Organisation. |
| GitLab, Jenkins, Buildkite oder Shell-CI | `keyhog scan . --format json-envelope --output keyhog.json` | Bewahren Sie den Bericht und den Exit-Code bei Erfolg, Funden und Fehlern auf. Verwenden Sie `--git-diff <base>` nur für ein ausdrücklich engeres Gate geänderter Zeilen. | Die Bytes im Checkout oder der ausgewählte Diff. |
| Ein Repository mit bekannten Funden übernehmen | Erstellen Sie `.keyhog-baseline.json`, committen Sie es und scannen Sie dann mit `--baseline .keyhog-baseline.json`. | Vorhandene Identitäten bleiben in der Baseline sichtbar, während nur neue Funde das Gate fehlschlagen lassen. | Eine Baseline unterdrückt weder geänderte Zugangsdaten noch unvollständige Abdeckung. |
| Rekursive Git-Wiederherstellung | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | Kalibrieren Sie die Deep-Richtlinie einmal pro Worker-Klasse. Führen Sie im Prozess aus. | Ein Repository. `--git-history` deckt nur die Abstammung des aktuellen Checkouts ab, sodass ein nie ausgecheckter Zweig ohne Abdeckungslücke übersehen wird; `--git-blobs` erreicht auch verwaiste Blobs, amendierte Commits, Stashes, Notizen, annotierte Tag-Nachrichten und gepackte Referenzen. |
| Container- oder Archiv-Inspektion | `keyhog scan --docker-image registry/app:v1` oder `keyhog scan incoming/` | Behalten Sie einen Envelope-Bericht, damit übersprungene, beschädigte, verschlüsselte, unsichere oder zu große Mitglieder sichtbar bleiben. | Nur das ausgewählte Image oder der Dateisystempfad und unterstützte verschachtelte Formate. |
| URL-, Antwort- oder HAR-Inspektion | `keyhog scan --url https://api.example.com/config` oder `keyhog scan capture.har` | Verwenden Sie begrenzte Quelllimits und bewahren Sie den Terminal-Envelope. | Nur abgerufene Antworten oder Capture-Einträge. Dies ist kein Crawler. |
| Organisations- oder Cloud-Inventar | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | Partitionieren Sie nach Provider, Eigentümer oder Bucket. Führen Sie unabhängige Partitionen gleichzeitig mit je einem Bericht und Status aus. | Ein ausgewähltes Provider-Inventar pro Job. Paginierungs- oder Objektlimits bleiben Abdeckungsgrenzen. |
| Bestätigen, ob förderfähige Funde live sind | `keyhog scan . --verify` | Provider-Parallelität und Ratenkontrollen sind getrennt von Scanner-Workern. | Sendet zugangsdatenbasierte Anfragen an erklärte Provider-Endpunkte. Nicht jeder Detektor unterstützt Verifizierung. |
| Ganz-Host-Gesundheitsscan | `sudo keyhog scan-system --space 50G` | Nutzt standardmäßig alle CPU-Kerne und scannt nach Dateisystemdaten entdeckte Git-Historie. | Lokal gemountete Dateisysteme. Netzwerk-Mounts sind optional und die Speicherobergrenze ist hart. |
| GPU-gestütztes Verzeichnis, Historie, Archiv, Remote oder Cloud-Inventar auf Unix | Kalibrieren Sie die Autoroute, starten Sie `keyhog daemon start --mass` und führen Sie dann `keyhog scan --daemon=mass <SOURCE>` aus. | Streamt begrenzte Stapel durch einen kompilierten CPU-, Hyperscan-, CUDA-, Metal- oder WGPU-Worker. Fügen Sie `--incremental` für warme unveränderte Dateisystembäume hinzu. Die Terminal-Quittung meldet exakte Gesamt- und GPU-Stapel, Chunks, Bytes, GPU-Anteil und Durchsatz. | Baselines, Verifizierung, Lockdown, Presets, Overlays und andere Scanner-Richtlinienänderungen werden vor der Erfassung abgelehnt. Inkrementeller Zustand gilt nur für daemon-lokale Dateisystemwurzeln. |

### Jede unterstützte Quellgrenze scannen

Verwenden Sie einen Befehl pro Grenze. Bewahren Sie einen `json-envelope`-Bericht und den rohen Exit-Status für jede Inventarpartition auf.

| Quelle oder Anwendungsfall | Befehl |
|---|---|
| Mehrere lokale Wurzeln | `keyhog scan services/api services/web deploy/` |
| Kontinuierlich geänderte Dateien | `keyhog watch services/api deploy/` |
| Gestagte Bytes, geänderte Zeilen, erreichbare Historie oder Blobs | `keyhog scan --git-staged`, `--git-diff main`, `--git-history .` oder `--git-blobs .` |
| Native Binärdateien und Firmware-Strings | `keyhog scan --binary firmware.bin` (ein einfacher Verzeichnisscan überspringt Binärdateien und beendet sich weiterhin mit `0`) |
| Archive und komprimierte Quellen | `keyhog scan incoming/` (unterstützte Mitglieder werden automatisch erweitert) |
| Docker-Image-Ebenen | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, Source Maps, WASM oder eine Endpunkt-Antwort | `keyhog scan --url https://api.example.com/config` |
| HTTP-Anfrage- und Antwort-Captures | `keyhog scan capture.har` |
| GitHub Issues, Pull Requests, Discussions, Wikis und Gists | `keyhog scan --github-collaboration owner/repo --github-all` |
| GitHub-, GitLab- oder Bitbucket-Inventare | `--github-org ORG`, `--gitlab-group GROUP` oder `--bitbucket-workspace WORKSPACE` |
| S3-, GCS- oder Azure-Blob-Inventare | `--s3-bucket BUCKET`, `--gcs-bucket BUCKET` oder `--azure-container-url URL` |
| Ein begrenzter Stream aus einem anderen Tool | `producer \| keyhog scan --stdin` (verwenden Sie `set -o pipefail`, damit ein fehlgeschlagener Producer seinen eigenen Fehler anzeigt, nicht einen Null-Byte-Scan) |

Ein einfacher Verzeichnisscan liest keine nativen Binärdateien. Jede wird zu einer Abdeckungslücke `binary (extension or content sniff)`, der Scan beendet sich weiterhin mit `0`, und `--no-default-excludes` ändert das nicht. Übergeben Sie also `--binary`, wenn kompilierte Artefakte im Umfang sind. Dieses Flag benötigt einen Build mit der `binary`-Funktion, die in der Standard-crates.io-Installation enthalten ist, nicht jedoch in der schlanken `ci`-Funktion.

Die Extraktion nativer Binärdateien berichtet vollständige Zugangsdaten, die den expliziten Formvertrag eines benannten Detektors erfüllen. Sie unterdrückt kurze Präfix-Fragmente und generische zuweisungsförmige Strings aus kompilierten Datensektionen, da diese Bytes keinen Quellkontext behalten.

Endpunkt-Abruf ist begrenzt und SSRF-geprüft. Es ist kein Crawler. Private Cloud-Endpunkte und Zugangsdaten-Weiterleitung erfordern ihre expliziten Vertrauensflags. Provider-Token gehören in die dokumentierten Umgebungsvariablen, nicht in Prozessargumente.

Nutzen Sie den [Workflow-Auswähler](https://santhreal.github.io/keyhog/capabilities.html) für Quell- und Richtliniendetails, den [GitHub Action-Leitfaden](https://santhreal.github.io/keyhog/workflows/github-action.html) für das gewartete Repository-Gate, den [direkten CI-Leitfaden](https://santhreal.github.io/keyhog/workflows/ci.html) für dauerhafte Berichte und Exit-Behandlung und den [Massen-Scan-Leitfaden](https://santhreal.github.io/keyhog/guides/mass-scanning.html) für Partitionierung und Aggregation. Das [Rezepte-Kochbuch](https://santhreal.github.io/keyhog/recipes.html) deckt Container, Archive, URLs, GitHub-Kollaborationsinhalte und Cloud-Quellen ab.

### Geschwindigkeit und Parallelität ohne Rätselraten

Beginnen Sie mit den Standardeinstellungen. Der historisch verifizierte Binär-Asset-Installer führt die Kalibrierung selbst durch. Cargo kann KeyHog nach `cargo install` nicht ausführen. Führen Sie daher die folgenden Befehle einmal nach der Installation eines Multi-Backend-Cargo-Builds und erneut aus, wenn sich Host, Binärdatei, Detektor-Korpus, Treiber oder Workload-Klassen ändern:```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Bei einem Shared Runner, dem vier Scanner-Worker und ein
Reader-Worker zugewiesen sind:```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

Erstellen Sie den Repository-Checkout, wenn Sie eine unveröffentlichte Änderung benötigen:```sh
cargo install --path crates/cli --locked

Use the [install guide](https://santhreal.github.io/keyhog/install.html) for
Rust toolchain requirements, feature profiles, and platform-specific runtime
dependencies.


## Was es erkennt

926 eingebettete Detektoren mit detektor-eigener Offline-Validierung und Begleitern:

- **Cloud-Anbieter:** AWS (Access-Key + Secret + STS-Verifizierung),
  Azure (Abonnement-Schlüssel, Speicherkonto-Schlüssel, SAS), GCP (Dienstkonto,
  API-Schlüssel), Cloudflare, Heroku, Vercel, Supabase.
- **Zahlungsdienstleister:** Stripe, Braintree, Razorpay, Paddle, Plaid,
  Square und PayPal, mit detektor-eigenen Prüfungen sowie optionalen oder
  erforderlichen Begleitern. Ein Razorpay-Key-Secret erfordert die dazugehörige
  Key-ID in unmittelbarer Nähe.
- **Quellcode-Plattformen:** GitHub-PATs (mit CRC32-Prüfsumme), GitLab-Tokens,
  Bitbucket-App-Passwörter, npm-Tokens (mit Prüfsumme), Gitea / Forgejo
  / Codeberg.
- **Auth / SSO:** Okta, Auth0, Clerk, JumpCloud, Kinde.
- **Kommunikation:** Slack, Discord, Twilio, SendGrid, Postmark, Mailgun,
  Resend, Loops.
- **KI / ML:** OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio,
  Cohere, Mistral, HuggingFace, Replicate. HuggingFace-Organisations-
  Anmeldedaten umfassen sowohl die aktuelle `hf_`-Form als auch ältere
  `api_org_`-Tokens.
- **Passwortmanager:** 1Password-Konto-Secret-Keys (`A3-` gefolgt von fünf
  oder sechs segmentierten alphanumerischen Großbuchstaben-Komponenten).
- **Datenbanken:** Postgres-Verbindungszeichenfolgen, MongoDB Atlas,
  Supabase-Service-Role, PlanetScale, Neon, Turso, MySQL- und Redis-URLs.
- **Generische Erkennung + Entropie:** `API_KEY=<high-entropy-blob>` erkennt
  Anmeldedaten ohne benannten Detektor, gesteuert durch kontextbezogene
  Entropie-Schwellenwerte + ML-Bewertung.
- **Kryptografisches Material:** RSA-/EC-/SSH-Private-Keys, PGP-private
  Blöcke, JWT-Signatur-Secrets.

Jeder Detektor wird als [TOML-Datei](https://github.com/santhreal/keyhog/blob/HEAD/detectors/) (Daten, kein Code) ausgeliefert: Dienst-Metadaten, Regex-Muster, Schlüsselwörter, Offline-Validatoren, Entropie- und ML-Richtlinie, Begleitfelder und Verifizierungs-Handler. Das Hinzufügen eines neuen Detektors ist eine einzelne überprüfbare TOML-Änderung; der [Beitragsleitfaden](https://github.com/santhreal/keyhog/blob/HEAD/CONTRIBUTING.md) führt Schritt für Schritt durch den Prozess.

`keyhog explain <id>` gibt die vollständige Spezifikation eines beliebigen Detektors aus: Muster, Schlüsselwörter, Verifizierungs-Endpunkt sowie einen dienstbezogenen Rotations- und Schritt-für-Schritt-Behebungsleitfaden, sodass ein Fund nie eine Blackbox ist:

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat: Detektor-Spezifikations-Ausgabe (Muster ghp_[A-Za-z0-9]{36}, Schlüsselwort, Verifizierungs-URL), gefolgt von der GitHub-Rotationsanleitung und der Schritt-für-Schritt-Behebung" width="860" />
</p>

Die Erstellung und Inspektion von Detektoren wird in der [Detektor-Referenz](https://github.com/santhreal/keyhog/blob/HEAD/docs/src/detectors.md) beschrieben; alternativ durchsuchen Sie den installierten Korpus mit `keyhog detectors --search <term> --verbose`.

## Warum höhere Trefferquote und weniger Fehlalarme

- **Dekodierungs-Durchlauf-Scanning.** Kubernetes-`Secret`-Manifeste,
  Jupyter-Notebooks, JWT-Payloads, base64-umhüllte Envs, Helm-Werte und
  `auth:`-Blobs der docker-config. Der strukturierte Präprozessor behandelt
  ausgewogene Helm-Aktionen als träge Renderzeit-Werte und schließt fehlende
  Jupyter-Trennzeichen am Dateiende, sodass wörtliche Bytes und vollständige
  Code-Zellen abgedeckt bleiben. Er dekodiert strukturierte Werte an Ort und
  Stelle und liefert jedem nachgelagerten Detektor den Klartext. Detektoren
  müssen die Dekodierung nicht jeweils neu implementieren. Dekodierungs-aktivierte
  Scans rekonstruieren außerdem nebenwirkungsfreie JavaScript-Byte-Array-XOR-
  und AES-256-CBC-Ausdrücke, wenn das gesamte Wiederherstellungsmaterial
  eingebettet ist, einschließlich strenger CryptoJS/OpenSSL-Salted-Passphrase-
  Wrapper. KeyHog führt die Quelle niemals aus.
- **Mehrzeilige Wiederherstellung.** `"sk-proj-" + \`-Fortsetzungen in
  JavaScript, YAML-Mehrzeilen-Zeichenfolgen, Makefile-Backslash-Fortsetzungen,
  Helm-/Jinja-templatisierte Ausgaben – alles wird vor der
  Regex-Übereinstimmung wieder zusammengesetzt.
- **Begleit-Validierung.** Erforderliche Begleiter sperren Detektoren mit hohem
  Rauschen. Ein Twilio-API-Key ohne sein API-Secret wird übersprungen.
  Optionale Begleiter erhöhen die Konfidenz oder verbessern die Verifizierung.
  Die AWS-Access-Key-Erkennung erfordert das Secret nicht, aber für die
  Live-Verifizierung wird das Secret benötigt.
- **Detektorübergreifende Auflösung.** Detektor-TOML kann begrenzte Funde eines
  anderen Detektors erfordern, ablehnen oder übernehmen. Die Auflösung bleibt
  unabhängig von der Eingabereihenfolge deterministisch; ungültige Ziele,
  Widersprüche oder Abhängigkeitszyklen führen zu einem Fehlschlag der
  Korpus-Kompilierung.
- **Konfidenz-Bewertung.** Jeder Fund trägt einen `[0.0, 1.0]`-Score, der aus
  Shannon-Entropie, umgebendem Kontext, Begleit-Übereinstimmung,
  detektor-eigenem Offline-Nachweis (GitHub-/npm-CRC32 und
  PyPI-Payload-Dekodierung), strukturellen Belegen und einem kleinen
  ML-Klassifikator (~30k Parameter) abgeleitet wird. Der Standard-Schwellenwert
  `0.40` (die kanonische `ScanConfig::default()`-Untergrenze; identisch mit dem
  `--min-confidence`-Standardwert und dem `[scan].min_confidence`-Beispiel
  unten) filtert minderwertige Übereinstimmungen, ohne echte Secrets zu
  verbergen.
- **Bayessche Kalibrierung pro Detektor.** `keyhog calibrate --fp generic-api-key`
  schreibt eine Beta(α,β)-Posterior. Scans verwenden sie nur, wenn
  `--calibration-cache` oder `[system].calibration_cache` auf diese Datei
  zeigt, sodass die Konfidenz-Anpassung explizit und reproduzierbar ist, statt
  von zufälligen Host-Cache-Zuständen abzuhängen.

## Leistung

Nutzen Sie die reproduzierbare Testumgebung in [`benchmarks/`](https://github.com/santhreal/keyhog/blob/HEAD/benchmarks/), um KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog und Titus unter einem einheitlichen Bewertungsvertrag zu vergleichen. Die Testumgebung schließt das Ground-Truth-Manifest aus jedem Scan-Baum aus. Die generierten Tabellen bleiben leer, bis Läufe mit dem aktuellen Schema vorhanden sind. Führen Sie nach der Messung `make -C benchmarks report` aus. Bearbeiten Sie generierte Tabellen nicht von Hand.

### Detektions-Rangliste

<!-- BENCH:leaderboard:start -->
Korpus: **mirror** - 15000 Fixtures, 3000 gekennzeichnete Positivfälle. Jeder Scanner wird identisch bewertet (SecretBench-Überlappungsregel); das Antwortschlüssel-Manifest ist vom Scan-Baum ausgeschlossen.

| Rang | Scanner | F1 | Präzision | Recall | Funde | Wandzeit | Spitzen-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 |

### Ergebnis-Herkunft

| Scanner | Scanner-Version / Digest der ausführbaren Datei | Korpus-Identität | Host-Identität | Laufdatum |
|---|---|---|---|---|
| KeyHog | version: KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Detector Set: 926 (926-4168e2c6c93a16ca)<br>Build Target: x86_64-linux<br>ML Model Version: moe-v1-246a05b92bec9aa3<br>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<br>executable SHA-256: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:39Z |
| TruffleHog | version: trufflehog 3.96.0<br>executable SHA-256: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:58Z |
| Kingfisher | version: kingfisher 1.94.0<br>executable SHA-256: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:50Z |
| Titus | version: Titus v1.1.20 (Go port of NoseyParker)<br>executable SHA-256: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>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<br>executable SHA-256: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:53Z |
| Betterleaks | version: betterleaks version dev<br>executable SHA-256: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15,000 fixtures; 3,000 labeled positives; 2,431,242 bytes | hostname SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->

### Geschwindigkeit & Speicher

<!-- BENCH:perf:start -->
| Scanner | Konfiguration | Korpus | Wandzeit | Durchsatz | Spitzen-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 |
<!-- BENCH:perf:end -->

### Kategorieweiser Recall-Vergleich

<!-- BENCH:gaps:start -->
_Nur der diagnostische Recall-Ausschnitt. Gesamtpräzision und F1 bleiben der Vergleichsvertrag; Fehlalarme werden in ihren bewerteten Kategorien gezählt._

| Kategorie | KeyHog P/R/F1 | KeyHog TP/FN | Bester Wettbewerber P/R/F1 | Recall-Lücke |
|---|---|---|---|---|
| `generic-high-entropy-string` | 1.000 / 0.434 / 0.606 | 73/95 | Betterleaks 1.000 / 0.798 / 0.887 | +0.363 |
<!-- BENCH:gaps:end -->

### Telemetrie der begrenzten statischen Wiederherstellung

<!-- BENCH:recovery:start -->
Ausgewählter Lauf: Scanner **KeyHog** `KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Detector Set: 926 (926-4168e2c6c93a16ca)<br>Build Target: x86_64-linux<br>ML Model Version: moe-v1-246a05b92bec9aa3<br>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`; Korpus **mirror** (15,000 fixtures, 2,431,242 bytes); erzeugt `2026-08-11T01:29:39Z`; Artefakt `mirror-keyhog-simd-nocache-nodaemon-full.json`.

Telemetrie-Schema: `static-recovery-v1`.

| Status | Genaue Anzahl |
|---|---:|
| Unterstützt | 0 |
| Nicht unterstützt | 0 |
| Fehlerhaft | 0 |

| Ablehnungsgrund | Genaue Anzahl |
|---|---:|
| _keine_ | 0 |
<!-- BENCH:recovery:end -->

### Bigram-Bloom-Nachweis

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

| Feld | Genaues Ergebnis |
|---|---|
| Korpus | `samsung-creddata-fx-record-spans-v1` |
| Korpus-Revision | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| Korpus-SHA-256 | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| Fixture-SHA-256 | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| SHA-256 der ausführbaren Datei | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| SHA-256 des Workspace-Detektor-Korpus | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Scanner-Detektor-Digest | `8d789251e092959f` |
| Detektor-Korpus-SHA-256 | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Bloom-Ablehnung | **110/51794 (0.21%)**; 51684 akzeptiert |
| Externe Verfügbarkeit | 51794 gemessen; 0 von 51794 deklarierten explizit nicht verfügbar; Gründe:  |
| Aktivierte vs. umgangene Funde | **IDENTISCH**; 977/977 Funde |
| Finding-Identität-SHA-256 | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Bloom-Dichte/-Zustand | 1793/65536 Slots; `healthy`; Sättigung bei 39322 |

Die Fund-Identität verknüpft Detektor, Datei, Zeile, Byte-Spanne und Anmeldedaten-SHA-256; Klartext-Anmeldedaten werden nie aufgezeichnet.
<!-- BENCH:bloom:end -->

Reproduzieren: `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog` führt den exakten Mirror-Laufsatz von KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog und Titus erneut aus, einschließlich der ausführungsgebundenen CredData-Bloom-Differenz; `make -C benchmarks report` erzeugt die obigen Tabellen und `benchmarks/reports/` neu. Siehe [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/HEAD/benchmarks/README.md) für die Korpora (mirror, Heimspiel-Korpus der Wettbewerber, Samsung/CredData) und die Backend-/Cache-/Daemon-/OS-/GPU-Matrix.

## GPU-gestützte Massen-Daemon-Worker

Der optionale Unix-Massen-Daemon hält einen kompilierten Scanner und seinen kalibrierten Backend-Zustand warm. Lokale Dateisystem-Scans senden nur kanonische Root- und Quellrichtlinien-Metadaten; der Daemon liest die Dateien in seinem eigenen Prozess und verarbeitet sie stapelweise. Git-, Binär-, Remote- und Cloud-Quellen, die clientseitige Anmeldedaten erfordern, verwenden geschützte begrenzte Chunk-Frames.```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` ist eine begrenzte lokale Host-Prüfung, kein Ersatz für Repository- oder
Cloud-Inventarpartitionierung. Es wird durch die insgesamt gescannten Bytes begrenzt, nicht
durch den Pfad: `--space` ist die Obergrenze, und netzwerkgebundene Dateisysteme werden
übersprungen, sofern Sie nicht `--include-network` übergeben. Prüfen Sie das Mount-, Netzwerkdateisystem-,
Speichergrenz- und Privilegienverhalten, bevor Sie es ausführen. Siehe
[systemweite Triage](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).

## Sensible lokale Scans absichern

Linux `--lockdown` ist ein Prozessschutzmodus mit Fail-Closed-Verhalten:```sh
keyhog scan . --daemon=off --lockdown

Die Standard-Bibliotheksmethoden sind deterministische portable CPU-Referenzen. Explizite Backend-Methoden geben typisierte Fehler zurück, anstatt den Prozess zu beenden oder stillschweigend eine andere Engine einzusetzen. Rohe Chunks und Treffer können Klartext enthalten. Konvertieren Sie sie mit `RawMatch::to_redacted`, oder verwenden Sie finale `VerifiedFinding`-Werte, bevor sie JSON-, Log-, Datenträger- oder Netzwerkgrenzen überschreiten.

Der [Architekturleitfaden](https://github.com/santhreal/keyhog/blob/HEAD/docs/src/architecture.md) definiert Crate-Eigentümerschaft, Backend-Verträge, Wiederherstellungsbelege, Quellhilfsprogramme und sichere Berichtsgrenzen. Die Rust-Dokumentation auf Crate-Ebene ist maßgeblich für die vollständige API.

## Richtlinie mit expliziter Priorität konfigurieren

Die Repository-Richtlinie befindet sich in `.keyhog.toml`:```toml
verify = false

[scan]
severity = "high"
incremental = true

[system]
gpu = "auto"

Detektor-Definitionen bleiben Daten unter `detectors/`. `keyhog-core` ist für Detektor- und Finding-Typen zuständig, `keyhog-scanner` für Matching- und Ausführungs-Backends, `keyhog-sources` für die Eingabebeschaffung, `keyhog-verifier` für Live-Checks und `keyhog-cli` für Operator-Workflows.

Beginnen Sie mit dem [Architekturleitfaden](https://github.com/santhreal/keyhog/blob/HEAD/docs/src/architecture.md) für die Repository-Karte, die Abhängigkeitsrichtung, die Bytes-to-Finding-Pipeline, die Routing-Zuständigkeit und die Profiling-Einstiegspunkte.

## Installation untersuchen und erweitern```sh
keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh