Website · Dokumentation · Architektur · Vyre-GPU-Engine

KeyHog: GPU-beschleunigter Secret-Scanner für Code, Cloud und CI

KeyHog ist ein Open-Source-Secret-Scanner in Rust, der durchgesickerte API-Schlüssel, Tokens, Passwörter und Anmeldedaten in Quellcode, Git-Historie, Containern, Cloud-Speicher, Browser-Assets, Kollaborationsinhalten und laufenden Systemen findet und verifiziert.

Die meisten Secret-Scanner bleiben bei CPU-Regex-Treffern in einem Repository-Checkout stehen. KeyHog kombiniert 934 dienstspezifische Detektoren, Decode-Durchlauf für versteckte Anmeldedaten, kontextbewusste Belege und Unterdrückung, Live-Verifizierung durch Anbieter sowie erstklassige CUDA-, Metal- und WGPU-Ausführung über Vyre. Die Kalibrierung misst jeden geeigneten Pure-Rust-CPU-, Hyperscan/SIMD- und GPU-Backend. Automatisches Routing nutzt dann die schnellste, in Parität bewiesene Route für den exakten Host und die Arbeitslastklasse.

GPU ist ein echtes Backend	Die tatsächliche Angriffsfläche scannen	Signal vom Rauschen trennen	Auf das Ergebnis reagieren
CUDA, natives Metal und WGPU sind gemessene Partner, keine stille Fallback-Kette.	Git-Historie, Docker-Layer, Archive, Cloud-Buckets, Source Maps, WASM, HAR-Aufzeichnungen, gehostete Git-Sammlungen und ganze Systeme scannen.	base64, hex, URL, protobuf, mehrzeilige und strukturierte Konfiguration dekodieren, bevor Belege, Beispiel-Unterdrückung und Baselines angewendet werden.	Berechtigte Anmeldedaten über Anbieter-APIs verifizieren, SARIF oder strukturierte Envelopes ausgeben und exakte Abdeckungs- und Exit-Semantik beibehalten.
cargo install --locked keyhog
keyhog scan .

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

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

KeyHog übergibt nicht 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 zusammen mit 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-, Beweis- und
Berichtspipeline, die auch von CPU- und Hyperscan-Routen verwendet wird.

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

Die Standardinstallation über crates.io verwendet die portable reine-Rust-CPU-Route, sodass sie
auf einem sauberen Rust-Host funktioniert. Aktivieren Sie die drei GPU-Peers, ohne Hyperscan zu erwerben:```sh
cargo install --locked keyhog --no-default-features --features portable,gpu

Aktivieren Sie den Hyperscan- oder Vectorscan-SIMD-Regex-Peer:```sh cargo install --locked keyhog --no-default-features --features portable,simd

Führen Sie die Produktions-Backend-Diagnose aus und prüfen Sie dann die gemessene Route:```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Der Backend-Leitfaden dokumentiert die residenten Tabellen, das begrenzte Dispatch-Modell, den Paritätsvertrag und reproduzierbare Crossover-Belege.

Erste Schritte

Installieren und Ihren ersten Scan ausführen

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

Pinnen Sie eine CI-Umgebung auf genau eine Version mit cargo install --locked --version '=0.5.86' keyhog. KeyHog erfordert Rust 1.89 oder neuer. Siehe den Installationsleitfaden für GPU-, Hyperscan-, CI-, portable und Quell-Build-Profile.

KeyHog beendet sich mit 1, wenn ein Befund die aktive Evidenzrichtlinie blockiert. Die Standardrichtlinie blockiert likely- und confirmed-Befunde, während review-Befunde mit Exit-Code 0 sichtbar bleiben; --evidence-policy paranoid blockiert jede Stufe. Prüfen Sie die genaue Evidenzstufe, den Grundcode, die Datei, die Zeile, den Detektor und die Behebung jedes Befunds. Andere Nicht-Null-Codes beschreiben Eingabe-, System-, Verifikations- oder Abdeckungsfehler; siehe die Exit-Code-Referenz.

Der vollständige Prozessvertrag lautet:

Exit	Bedeutung
`0` Erfolg	Kein Befund blockiert die aktive Evidenzrichtlinie, und kein Abdeckungsfehler ist aufgetreten. Review-Stufen-Befunde können unter der Standardrichtlinie sichtbar bleiben.
`1` blockierende Befunde	Mindestens ein Befund blockiert die aktive Evidenzrichtlinie, aber keiner wurde als live bestätigt.
`2` Bedienerfehler	Beheben Sie die Argumente, die Konfiguration, den Detektor-Korpus oder die vom Bediener korrigierbare Eingabe.
`3` Systemfehler	Reparieren oder wiederholen Sie den Runner. Dies umfasst Low-Level-I/O, fatale Daemon-Dienste, den inkrementellen Cache und explizit ausgewählte SIMD-Fehler.
`4` Health-/Selbsttest-Fehler	Ein `doctor`- oder `backend --self-test`-Health-Check war nicht gesund.
`10` Live-Anmeldedaten	Mindestens eine Anmeldedaten wurden als live bestätigt.
`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 Strg+C hat den Prozess unterbrochen.

Filtern, formatieren, gaten:

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

Der erste Befehl erfasst geprüfte Befunde und beendet sich mit `0`, ohne sie
auszugeben. Committen Sie diese Datei und verwenden Sie dann den zweiten Befehl, um nur neue Befund-Identitäten
zu melden. Ein Baseline-Eintrag stimmt mit dem Detektor und dem Anmeldedatenwert überein,
niemals mit dem Dateipfad. Das Verschieben eines aufgezeichneten Geheimnisses lässt die Prüfung also nicht fehlschlagen, aber
das Rotieren schon. Geänderte Anmeldedaten und unvollständige Abdeckung bleiben sichtbar.
Der vollständige Pfad, einschließlich Monorepo-Partitionen, ist [Nur bei neuen
Geheimnissen fehlschlagen](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets).

Verwenden Sie für den nächsten Scan das [Rezepte-
Kochbuch](https://santhreal.github.io/keyhog/recipes.html) oder die kopierbaren
Befehle unter [Den richtigen Workflow wählen](#den-richtigen-workflow-waehlen). Sie können
den Git-Verlauf, Container-Images, Cloud-Buckets, Repository-Sammlungen,
URLs und eine gesamte Maschine scannen, ohne die Werkzeuge zu wechseln.

### Repositories für schnelle Pre-Commit-Scans absichern

Registrieren Sie ein Repository beim permanenten KeyHog-Daemon für schnelle
Pre-Commit-Geheimniserkennung (erfordert Unix; unter Windows verwenden Sie den In-Process-`keyhog scan`):```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

Siehe den Leitfaden für den permanenten Guard und den Pre-Commit-Workflow für die vollständige Konfiguration, den Lebenszyklus der Zustandsmaschine und die Hook-Automatisierung.

Zu GitHub Actions hinzufügen

Erstelle .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

Die Aktion scannt den ausgecheckten Baum, schlägt bei Befunden mit `high` oder
`critical` fehl, lädt SARIF in Code Scanning hoch und behält den Bericht als
Workflow-Artefakt. Fehler bei Installation, Abdeckung, Backend und
Berichtsveröffentlichung 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 getrackte Quelldateien.
Verwenden Sie einen Bericht pro Grenze, damit CI die exakte Abdeckung und den
Fehlerstatus behält.

| Expositionsoberfläche | Beispiel |
|---|---|
| Finales Paketartefakt | Führen Sie `npm pack` aus und scannen Sie dann das erzeugte `.tgz` mit `keyhog scan package.tgz`. Die Archiv-Expansion 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, Diskussionen, Wikis und Gists | `keyhog scan --github-collaboration owner/repo --github-all` scannt jede Kollaborationsoberfläche außerhalb des Checkouts. |
| KI-Agent- und MCP-Konfiguration | `keyhog scan ~/.config ~/.claude ~/.codex` wendet dieselbe Detektor-, Decode-, Evidenz- und Berichtspipeline 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 eingeführt wurden. |
| Cloud-Objekt-Inventare | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` oder `--azure-container-url URL` bewahrt 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 harten Speicherbudget. |

Diese Routen teilen einen Erkennungs- und Berichtsvertrag. Ein quellenspezifischer
Fehler kann nicht stillschweigend zu einem engeren lokalen Scan werden.

## Wählen Sie den richtigen Workflow

Wählen Sie zuerst die Quellengrenze. 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 keinen ehrlichen `scan everything`-Abkürzungsweg. 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` | Wiederverwendet Hashes unveränderter Dateien. Das Fast-Preset überspringt Decode-, Entropie- und ML-Arbeit. | Führen Sie die Standardrichtlinie vor dem Merge 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 unstagede Änderungen das Ergebnis nicht verändern können. | Nur gestagte Inhalte. Führen Sie einen Working-Tree-Scan separat aus, wenn lokale unstagede Bytes relevant sind. |
| Dauerhafter Repository-Wächter | `keyhog guard add . --mode repo` 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 Wächter ergänzt, ersetzt aber nicht Staged- 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` | Persistieren Sie den Bericht und den Exit-Code bei Erfolg, Befunden und Fehlern. Verwenden Sie `--git-diff <base>` nur für ein explizit engeres Gate für geänderte Zeilen. | Die im Checkout vorhandenen Bytes oder der ausgewählte Diff. |
| Repository mit bekannten Befunden ü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 Befunde das Gate fehlschlagen lassen. | Eine Baseline unterdrückt keine geänderten Anmeldedaten oder 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 Branch 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, Besitzer oder Bucket. Führen Sie unabhängige Partitionen gleichzeitig mit einem Bericht und Status pro Partition aus. | Ein ausgewähltes Provider-Inventar pro Job. Paginierungs- oder Objektlimits bleiben Abdeckungsgrenzen. |
| Bestätigen, ob förderfähige Befunde live sind | `keyhog scan . --verify` | Provider-Concurrency- und Ratenkontrollen sind von Scanner-Workern getrennt. | Sendet anmeldedatenbasierte Anfragen an deklarierte Provider-Endpunkte. Nicht jeder Detektor unterstützt Verifizierung. |
| Ganz-Host-Gesundheitsscan | `sudo keyhog scan-system --space 50G` | Verwendet standardmäßig alle CPU-Kerne und scannt entdeckte Git-Historie nach Dateisystemdaten. | Lokale gemountete Dateisysteme. Netzwerk-Mounts sind optional und die Speichergrenze 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 Batches 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-Batches, Chunks, Bytes, GPU-Anteil und Durchsatz. | Baselines, Verifizierung, Lockdown, Presets, Overlays und andere Scanner-Richtlinienänderungen werden vor der Erfassung abgelehnt. Inkrementeller Status gilt nur für daemon-lokale Dateisystem-Roots. |

### Jede unterstützte Quellengrenze scannen

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

| Quelle oder Anwendungsfall | Befehl |
|---|---|
| Mehrere lokale Roots | `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 endet trotzdem mit `0`) |
| Archive und komprimierte Quellen | `keyhog scan incoming/` (unterstützte Mitglieder expandieren automatisch) |
| Docker-Image-Ebenen | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, Source Maps, WASM oder eine Endpunktantwort | `keyhog scan --url https://api.example.com/config` |
| HTTP-Anfrage- und Antwort-Captures | `keyhog scan capture.har` |
| GitHub-Issues, Pull Requests, Diskussionen, 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 meldet, nicht einen Null-Byte-Scan) |

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

Die Extraktion nativer Binärdateien meldet vollständige Anmeldedaten, 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 Anmeldedaten-Weiterleitung erfordern ihre expliziten Vertrauensflags.
Provider-Token gehören in die dokumentierten Umgebungsvariablen, nicht in Prozessargumente.

Nutzen Sie den [Workflow-Wähler](https://santhreal.github.io/keyhog/capabilities.html)
für Quellen- und Richtliniendetails, den [GitHub-Action-
Leitfaden](https://santhreal.github.io/keyhog/workflows/github-action.html) für das
gepflegte 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. Cargo kann KeyHog nach `cargo install` nicht ausführen, also
führen Sie die folgenden Befehle einmal nach der Installation eines Multi-Backend-Cargo-Builds und
erneut nach Änderungen am Host, Binary, Detektor-Korpus, Treiber oder den Workload-Klassen aus:```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Control	Verwenden für	Diese Invariante beibehalten
Kalibriertes `--backend auto`	Routine-CPU-, Hyperscan- oder GPU-Auswahl.	Ein expliziter Backend ist ein diagnostischer Override, keine schnellere Standardeinstellung.
`--threads <N>`	Reservieren von CPU-Kapazität auf einem gemeinsam genutzten Runner. Dedizierte Hosts sollten es normalerweise ungesetzt lassen, damit KeyHog die verfügbaren Kerne nutzt.	Jeder Wert muss positiv sein. Mehrere gleichzeitige KeyHog-Prozesse besitzen jeweils einen Worker-Pool, also teile das Host-Budget über Partitionen auf.
`--reader-threads <N>`	Gemessene Speicher-Pipelines, bei denen Reader-Arbeit, nicht das Scannen, der Engpass ist.	Der Standardwert leitet sich vom Scan-Worker-Pool ab. Lasse ihn ungesetzt, bis Profiling einen Reader-Engpass zeigt.
`--incremental` und `--incremental-cache <PATH>`	Wiederholte Scans desselben vertrauenswürdigen Baums.	Teile einen Index nicht über unzusammenhängende Repositories oder nicht vertrauenswürdige Jobs.
Provider- oder Repository-Partitionen	Gleichzeitiges Estate-Scannen und unabhängige Wiederholungen.	Bewahre eine Terminal-Envelope und den rohen Exit-Code pro Partition. Verkette keine Funde und verwerfe keinen Coverage-Zustand.
`--verify-concurrency`, `--verify-rate` und `--verify-batch`	Begrenzen von Live-Provider-Prüfungen unabhängig vom Datei-Scannen.	Verifizierung sendet credential-abgeleitete Anfragen. Provider-Ratenlimits, nicht die CPU-Anzahl, besitzen diese Nebenläufigkeit.
Massen-Daemon	TB-große Verzeichnis-, Verlaufs-, Archiv-, Remote- oder Cloud-Streams auf einem Unix-Worker.	Jeder Frame ist auf 8 MiB und 1.024 Chunks begrenzt. Der Daemon serialisiert Fragment-Zustand und gibt eine exakte CPU/GPU-Ausführungsquittung zurück.
`--fast`, Standard, `--deep` oder `--precision`	Auswahl einer expliziten Erkennungskosten- und Recall-Policy.	Diese Presets schließen sich gegenseitig aus und ändern die Coverage. Sie sind keine austauschbaren Geschwindigkeitsregler.

Prüfe die aufgelöste Policy mit keyhog config --effective. Verwende --profile, um feste Scanner-Stufen und den vollständigen Operator-Lauf zu messen, bevor du Reader-, Batch- oder Kanal-Tiefen-Steuerungen änderst. Der Overhead-arme Bericht erfasst Quelle, Backend, Cache, Workload, Thread, Eingabe, Zustandsübergang, CPU-Zeit, Spitzenspeicher, exakte Binär-SHA-256, aktivierte-Funktion-SHA-256, Ziel-Triple, Build-Profil, Compiler, Allocator, verknüpftes-Backend-SHA-256, Detektor-Korpus-SHA-256, aktivierter-Detektor-BLAKE3, kompilierter-Plan-BLAKE3, gehashte Detektor-Provenienz, vollständige aufgelöste-Konfiguration-BLAKE3, Leistungs-Policy-BLAKE3, Preset, angewandter Schutz-Zustand, Quell-Adapter, gehashtes Quell-Ziel-BLAKE3, gehashte Quell-Partition-BLAKE3, rohe Quell-Bytes, Quell-Einheit-Fanout, dekodierungsabgeleitete Bytes, abgeschlossene Backend-Dispatch-Bytes und stabile Größen-/Fanout-Buckets. Byte-Domänen, die ihr Quell-Adapter noch nicht unterscheiden kann, bleiben explizit nicht verfügbar, statt zu gemessenen Nullen zu werden. Der Bericht erfasst keinen Quellinhalt, keine Credential-Werte, keine rohen Pfade, keine rohen URLs und keine rohen Konfigurationswerte. Verwende --perf-trace nur für teure Pro-Muster- und Backend-Diagnosezähler. Lasse erweiterte Pipeline-Steuerungen ungesetzt, es sei denn, eine reproduzierbare Messung auf dem Ziel-Worker zeigt eine Verbesserung.

Für einen wiederkehrenden vollständigen Repository-Scan:```sh keyhog scan . --incremental
--format json-envelope --output keyhog.json

Für einen gemeinsamen Runner, bei dem dem Job vier Scanner-Worker und ein
Reader-Worker zugewiesen sind:```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

Der zweite Befehl ist ein Ressourcenbudget, kein universelles Optimum. Miss den Zielhost, bevor du explizite Worker-Anzahlen wählst.

Für die Tiefenwiederherstellung und die systemweite Triage verwende deren dedizierte Anleitungen, da sich deren Abdeckung und Abschlussregeln von einem normalen Repository-Scan unterscheiden.

Benchmarks für Secret-Scanner

Diese Tafeln vergleichen Erkennungsrichtlinie, CPU- und GPU-Ausführungsanfragen, inkrementelles Cache-Verhalten und Warm-Daemon-Anfragen. Jeder Wert wird aus dem geprüften Benchmark-Snapshot generiert. Der Snapshot bindet die Scanner-Version, den ausführbaren Digest, den Detektor-Digest, das Korpus, den Host und den Ausführungszeitstempel. Verwende die vollständigen Benchmark-Nachweise für die Herkunft der Wettbewerber und den Rückruf pro Kategorie.

Erkennungsgenauigkeit

KeyHog KeyHog v0.5.70 scannte das Mirror-Korpus: 15.000 Fixtures, 3.000 markierte Positivfälle und 2.431.242 Eingabebytes. Das Antwortschlüssel-Manifest wurde vom Scan-Baum ausgeschlossen. Die Zeile verwendet die Standardrichtlinie auf der expliziten Hyperscan/SIMD-Route auf AMD Ryzen 9 9950X 16-Core Processor.

Präzision	Rückruf	F1	Richtig positiv	Falsch positiv	Falsch negativ
0.9651	0.9027	0.9328	2.708	98	292

Der verfolgte Quellbaum war sauber.

Ausführungsrouten, Voreinstellungen und Cache

Gemessen auf AMD Ryzen 9 9950X 16-Core Processor mit NVIDIA GeForce RTX 5090, 32 logischen Kernen, 15.000 Fixtures, 3.000 markierten Positivfällen und 2.431.242 Eingabebytes. Scanner: KeyHog v0.5.70. Der verfolgte Quellbaum war sauber.

Vollständiger Scan nach Ausführungsroute

Alle Zeilen verwenden die Standard-Erkennungsrichtlinie mit inkrementellem Cache und deaktiviertem Daemon. Die automatische Zeile protokolliert die angeforderte Richtlinie, aber das Benchmark-Ergebnis bindet nicht die ausgewählte persistierte Route, daher ist es kein Routing-Nachweis. GPU-Zeilen umfassen die Akquise und den vollständigen Scanner-Start auf diesem kleinen Korpus; sie sind keine GPU-Kernel-Crossover-Messungen.

Angeforderte Route	Wand	Durchsatz	Spitzen-RSS	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
Automatisch	1,46 s	1,59 MB/s	634 MiB	0.9328

Erkennungsrichtlinie auf Hyperscan/SIMD

Die Route, der Cache, der Daemon-Zustand, das Korpus und der Host bleiben fest. Voreinstellungen ändern die Erkennungsarbeit, daher vergleiche Präzision und Rückruf sowie die Zeit.

Richtlinie	Wand	Präzision	Rückruf	F1	Befunde
Schnell	737 ms	0.9700	0.8837	0.9248	2.738
Standard	860 ms	0.9651	0.9027	0.9328	2.816
Tief	861 ms	0.9645	0.9067	0.9347	2.845
Präzision	849 ms	0.9590	0.6397	0.7674	2.001

Inkrementeller Warm-Wiederholungslauf

Das Benchmark füllt den BLAKE3-Merkle-Index und misst dann den zweiten identischen Scan. Der kleine synthetische Baum ändert sich wenig, da der Scanner-Start dominiert; miss dein Repository, bevor du eine Beschleunigung behauptest.

Hyperscan/SIMD-Standardrichtlinie	Wand	Durchsatz	Spitzen-RSS
Cache aus	860 ms	2,70 MB/s	416 MiB
Warmer inkrementeller Cache	617 ms	3,76 MB/s	457 MiB

Warm-Daemon-Anfragen

Eine deterministische reguläre 8-MiB-Datei (sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5) wurde einmal im Prozess und einmal durch einen eigenen Daemon nach einer Aufwärm-Anfrage gescannt. Die Daemon-Zeit ist die Client-Anfrage; der Daemon-RSS gehört zum residenten Server.

Explizite Route	Im Prozess	Warmer Daemon	Warm / Einmalig	RSS im Prozess	Daemon-RSS
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

Diese Zeilen decken die warme Einzeldatei-Route ab. Die Massenroute akzeptiert auch begrenzte Verzeichnis- und Remote-Quellstapel; ihr inkrementeller Dateisystempfad wird separat gemessen.

CPU-, Reader-, Speicher-, Größen- und Partitions-Skalierung

Generiert von make -C benchmarks readme-scaling aus benchmarks/reports/readme-scaling.json. Die Testumgebung führte 3 gemessene Versuche nach 1 Aufwärmphase mit explizitem simd und deaktiviertem Daemon-Routing durch. Die Worker-Skalierung verwendet einen warmen Client-Seitencache, um CPU-Arbeit zu isolieren. Reader-, Korpusgrößen-, Speicher- und Partitionszeilen fordern saubere Seitenverdrängung mit posix_fadvise, wo die Plattform dies unterstützt; der Snapshot protokolliert die Richtlinie auf jeder Zeile. Jede Arbeitslast ist bytedeterministisch und befundfrei.

Host: AMD Ryzen 9 9950X 16-Core Processor, 32 effektive logische Kerne, 94.140 MiB RAM, Linux 6.17.0-19-generic. Nachweis: clean, Binärdatei 274b045489c4.

Scan-Worker-Skalierung

Worker	Reader-Threads	Median-Wand	p95-Wand	Durchsatz	Beschleunigung	Effizienz	Median-Spitzen-RSS
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

Dateisystem-Reader-Skalierung

Scan-Worker	Reader-Threads	Median-Wand	p95-Wand	Durchsatz	Relativ zu 1 Reader	Median-Spitzen-RSS
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

Korpusgrößen-Skalierung

Korpus	Dateien	Exakte Bytes	Median-Wand	p95-Wand	Durchsatz	Median-Spitzen-RSS
klein	256	8 MiB	869,9 ms	886,1 ms	9,2 MiB/s	111,1 MiB
mittel	1.024	64 MiB	1.859,9 ms	1.874,8 ms	34,4 MiB/s	126,3 MiB
groß	2.048	256 MiB	5.214,9 ms	5.321,7 ms	49,1 MiB/s	137,1 MiB

Speicher-Skalierung

Speicherklasse	Dateisystem	Geräte-ID	Median-Wand	p95-Wand	Durchsatz	Relativ zum ersten Speicher	Median-Spitzen-RSS
Arbeitsbereich	`ext4`	`66305`	1.847,4 ms	1.863,4 ms	34,6 MiB/s	1,00x	127,0 MiB
Lokal-temp	`tmpfs`	`116`	1.870,8 ms	1.887,3 ms	34,2 MiB/s	0,99x	124,9 MiB

Gleichzeitige Partitions-Skalierung

Prozesse	Worker pro Prozess	Aggregierte Worker	Gesamtdateien	Gesamtbytes	Median-Wand	Aggregierter Durchsatz	Beschleunigung	Median-Summen-Spitzen-RSS
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

Diese Zeilen sind Messungen, keine universellen Abstimmungskonstanten. Führe den Generator auf dem Zielhost und Speicher aus. Verwende den Knickpunkt, an dem der Durchsatz aufhört sich zu verbessern, und reserviere dann CPU und Speicher für den CI-Runner oder die Orchestrierungsschicht.

Reproduziere alle vier Benchmark-Gruppen mit make -C benchmarks readme-matrix. Der Befehl misst die erforderliche Matrix und schlägt fehl, wenn eine angeforderte CPU-, Hyperscan-, CUDA-, Metal-, WGPU-, Voreinstellungs-, Cache-, Daemon-, Thread-, Reader-, Speicher-, Korpusgrößen- oder Partitionszeile nicht verfügbar ist. Verwende make -C benchmarks readme-matrix-check, um zu überprüfen, dass beide Snapshots, Berichte und README übereinstimmen.

Wähle eine Scan-Konfiguration

Beginne mit der Standardrichtlinie und kalibriertem automatischem Routing. Ändere nur eine Achse, wenn der Workflow es erfordert:

Workflow	Erkennungsrichtlinie	Ausführung und Wiederverwendung	Zusätzliche Kontrolle
Erster Repository-Scan	Standard	Kalibriert `auto`; `--daemon=auto`	Überprüfe alle Befunde, bevor du Unterdrückungen hinzufügst.
Wiederholter lokaler Baum- oder CI-Scan	Standard	Kalibriert `auto`; `--incremental`	Persistiere den inkrementellen Cache nur zwischen Scans desselben vertrauenswürdigen Baums.
Kurze Feedback-Schleife	`--fast`	Kalibriert `auto`; optional `--incremental`	Akzeptiere reduzierte Dekodierungs-, Entropie- und ML-Abdeckung. Führe die Standardrichtlinie vor dem Merge aus.
Wiederherstellung mit höchstem Rückruf	`--deep`	Im Prozess	Tief ist gegenseitig ausschließlich mit schnell und präzision und nicht daemonfähig.
Großes Inventar mit geringerem Rauschen	`--precision`	Im Prozess für Repository-Sammlungen, Verlauf und Cloud-Quellen	Die Voreinstellung erhöht die Vertrauensschwellen und deaktiviert die Entropieerkennung. Sie kann Anmeldeinformationen mit geringerem Vertrauen übersehen.
TB-großes Verzeichnis-, Verlaufs-, Archiv-, Remote- oder Cloud-Inventar auf Unix	Standard	`keyhog daemon start --mass`, dann `--daemon=mass`	Stapel bleiben auf 8 MiB und 1.024 Blöcke begrenzt. Bewahre den Terminal-Abdeckungsbericht und den GPU-Ausführungsbeleg auf.
Live-Validierung von Anmeldeinformationen	Standard	Im Prozess	Füge `--verify` explizit hinzu. Die Verifizierung sendet von Anmeldeinformationen abgeleitete Anfragen an Anbieter.
Linux-Scan ohne Swap	Standard plus `--lockdown`	Im Prozess; inkrementeller Cache deaktiviert	Lockdown verweigert Verifizierung, Klartextgeheimnisse, Schnellmodus und vollständigkeitsreduzierende Schalter.

--fast, --deep und --precision sind sich gegenseitig ausschließende Erkennungsvoreinstellungen. --lockdown ist ein Fail-Closed-Ausführungsmodus, keine vierte Voreinstellung. Explizite --backend-Werte sind Diagnose- und Benchmark-Overrides. Sie ersetzen nicht die persistierten schnellsten-korrekten Nachweise, die vom automatischen Routing verwendet werden. Siehe Konfiguration, Autoroute-Kalibrierung, Daemon und Warm-Scans und Härtung für die vollständigen Verträge.

Wie KeyHog funktioniert

KeyHog kompiliert seine 934 Detektoren in einen gemeinsamen Trigger- und Extraktionsplan, dekodiert verschachtelte Kodierungen vor dem Abgleich und wendet pro Detektor Bewertung, Nachweis und Unterdrückung an. Pure-Rust-CPU (cpu-fallback) ist immer verfügbar. Die Hyperscan-Route (simd-regex) verwendet Hyperscan, wenn dieses Feature vorhanden ist; portable Builds verwenden die CPU-Route. CUDA (gpu-cuda-region-presence), Metal (gpu-metal-region-presence) und WGPU (gpu-wgpu-region-presence) sind gleichberechtigte Partner in einem beweisgestützten Autoroute-Selektor, keine Fallback-Kette. Die Kalibrierung misst jeden berechtigten Partner und persistiert die schnellste Route, deren vollständige Befunde mit der Referenzroute für den exakten Binär-, Detektor- und Konfigurationszustand, Host, Beschleuniger und Arbeitslastklasse übereinstimmen. Eine fehlende, veraltete, ungültige oder unvollständige Entscheidung stoppt einen automatischen Scan vor der Ausführung und meldet, wie neu kalibriert werden soll. Sie ersetzt niemals stillschweigend ein anderes Backend.

Siehe Architektur für die Repository-Karte, Abhängigkeitsrichtung, Bytes-zu-Befund-Pipeline und Profilierungs-Einstiegspunkte. Siehe Backends und Routing für Ausführungsverträge und Autoroute-Kalibrierung für Parität, Arbeitslastidentität, Cache-Lebenszyklus und Reparaturverfahren.

Vollständige Dokumentation: santhreal.github.io/keyhog - Installation, erster Scan, Ausgabeformate, Erkennungsinterna, Unterdrückungen, Verifizierung, Pre-Commit- und CI-Integration, CLI-Referenz, Autoroute, Exit-Codes, Umgebungsvariablen und Mitwirken. Quelle unter docs/.

Installiere KeyHog

Installiere die aktuelle crates.io-Version:```sh cargo install keyhog --locked

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

Bestätigen Sie die installierte Version:```sh keyhog --version --full keyhog doctor

Verwenden Sie die [Installationsanleitung](https://santhreal.github.io/keyhog/install.html) für
Rust-Toolchain-Anforderungen, Feature-Profile und plattformspezifische Laufzeitabhängigkeiten.


## Was es erkennt

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

- **Cloud-Anbieter:** AWS (Zugriffsschlüssel + Secret + STS-Verifizierung),
  Azure (Abonnement-Schlüssel, Speicherkonto-Schlüssel, SAS), GCP (Dienstkonto,
  API-Schlüssel), Cloudflare, Heroku, Vercel, Supabase.
- **Zahlungsabwickler:** Stripe, Braintree, Razorpay, Paddle, Plaid,
  Square und PayPal, mit detektor-eigenen Prüfungen und optionalen oder erforderlichen
  Begleitern. Ein Razorpay-Schlüsselgeheimnis erfordert die nahegelegene Schlüssel-ID.
- **Quellcode-Forges:** 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 Legacy-`api_org_`-
  Tokens.
- **Passwortmanager:** 1Password-Kontogeheimschlüssel (`A3-` gefolgt von
  fünf oder sechs segmentierten Großbuchstaben-Alphanumerik-Komponenten).
- **Datenbanken:** Postgres-Verbindungszeichenfolgen, MongoDB Atlas, Supabase
  Service-Rolle, PlanetScale, Neon, Turso, MySQL, Redis-URLs.
- **Generisch + Entropie-Erkennung:** `API_KEY=<Hoch-Entropie-Blob>` erfasst
  Anmeldedaten ohne benannten Detektor, gesteuert durch kontextbezogene Entropie-
  Schwellenwerte + ML-Bewertung.
- **Kryptografisches Material:** RSA / EC / SSH-Private Keys, PGP-private
  Blöcke, JWT-Signaturgeheimnisse.

Jeder Detektor wird als [TOML-Datei](https://github.com/santhreal/keyhog/blob/main/detectors) (Daten, nicht Code) ausgeliefert:
Dienstmetadaten, Regex-Muster, Schlüsselwörter, Offline-Validatoren, Entropie- und ML-
Richtlinie, Begleitfelder und Verifizierungshandler. Das Hinzufügen eines neuen Detektors ist eine
einzelne überprüfbare TOML-Änderung;
der [Mitwirkenden-Leitfaden](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md) führt Schritt für Schritt hindurch.

`keyhog explain <id>` gibt die vollständige Spezifikation jedes Detektors aus: Muster, Schlüsselwörter,
Verifizierungsendpunkt sowie eine dienstschlüsselbezogene Rotation und eine Schritt-für-Schritt-
Sanierungsanleitung, 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-Spezifikationsausgabe (Muster ghp_[A-Za-z0-9]{36}, Schlüsselwort, Verifizierungs-URL) gefolgt von der GitHub-Rotationsanleitung und Schritt-für-Schritt-Sanierung" width="860" />
</p>

Durchsuchen Sie die Detektor-Erstellung und -Inspektion in der
[Detektor-Referenz](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md) oder fragen Sie den installierten Korpus mit
`keyhog detectors --search <Begriff> --verbose` ab.

## Warum höhere Trefferquote, weniger Fehlalarme

- **Dekodierungsdurchlauf-Scanning.** Kubernetes-`Secret`-Manifeste, Jupyter-
  Notebooks, JWT-Payloads, base64-umhüllte Umgebungen, Helm-Werte und docker-config-
  `auth:`-Blobs. Der strukturierte Vorprozessor 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 speist jeden nachgelagerten Detektor mit dem Klartext. Detektoren
  müssen die Dekodierung nicht jeweils neu implementieren. Dekodierungsaktivierte Scans stellen auch
  nebenwirkungsfreie JavaScript-Byte-Array-XOR- und AES-256-CBC-Ausdrücke wieder her, wenn
  das gesamte Wiederherstellungsmaterial eingebettet ist, einschließlich strenger CryptoJS/OpenSSL-gesalzener
  Passphrase-Wrapper. KeyHog führt die Quelle niemals aus.
- **Mehrzeilige Wiederzusammenführung.** `"sk-proj-" + \`-Fortsetzung in JavaScript,
  YAML-Mehrzeilen-Strings, Makefile-Backslash-Fortsetzung, Helm /
  Jinja-vorlagenbasierte Ausgaben, alles vor dem Regex-Abgleich wieder zusammengeführt.
- **Begleitvalidierung.** Erforderliche Begleiter begrenzen Detektoren mit hohem Rauschen. Ein
  Twilio-API-Schlüssel ohne sein API-Geheimnis wird übersprungen. Optionale Begleiter reichern
  die Evidenzbewertung oder Verifizierung an. Die AWS-Zugriffsschlüssel-Erkennung erfordert nicht
  sein Geheimnis, aber das Geheimnis wird für die Live-Verifizierung benötigt.
- **Detektorübergreifende Auflösung.** Detektor-TOML kann begrenzte Funde eines anderen Detektors
  erfordern, ablehnen oder übernehmen. Die Auflösung bleibt deterministisch über die
  Eingabereihenfolge hinweg, und ungültige Ziele, Widersprüche oder Abhängigkeitszyklen führen zu einem
  Fehlschlag der Korpus-Kompilierung.
- **Evidenz-Befunde.** Jeder Fund trägt eine exakte `review`-, `likely`- oder
  `confirmed`-Stufe sowie einen kanonischen Grundcode. Intrinsische Prüfsummen- oder Grammatik-
  Nachweise, erforderliche Begleiter und Live-Verifizierung erzeugen bestätigte Evidenz;
  starke anbieter-spezifische Form in einer anmeldedaten-tragenden Rolle erzeugt wahrscheinliche
  Evidenz; schwache Anker, generische Zuweisungen, nur-Entropie-Kandidaten und
  Test-, Dokumentations-, Regel- oder Bezeichnerkontexte bleiben Review-Evidenz.
  Ein optionales `evidence_score` ergänzt den Befund, wenn gemessen.
  Der Standard-Schwellenwert `0.40` steuert die interne Konfidenzuntergrenze des Scanners
  und bleibt mit `--min-confidence` konfigurierbar.
- **Bayes'sche Kalibrierung pro Detektor.** `keyhog calibrate --fp generic-api-key`
  schreibt eine Beta(α,β)-A-posteriori-Verteilung. Scans verwenden sie nur, wenn `--calibration-cache`
  oder `[system].calibration_cache` auf diese Datei zeigt, sodass die Konfidenzabstimmung
  explizit und reproduzierbar ist, statt von zufälligem Host-Cache-Zustand abzuhängen.

## Leistung

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

### Erkennungs-Rangliste

<!-- BENCH:leaderboard:start -->
#### Synthetischer SecretBench-Form-Spiegelkorpus
Korpus: **mirror** - 15000 Fixtures, 3000 markierte Positive, 2.431.242 Bytes. Jeder Scanner wurde identisch bewertet (SecretBench-Überlappungsregel); das Antwortschlüssel-Manifest ist vom Scan-Baum ausgeschlossen.

| Rang | Scanner | F1 | Präzision | Trefferquote | 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 |

#### Wettbewerber-Heimfeld / Heimterritorium-Regelkorpus
Korpus: **homefield** - 2399 Fixtures aus den Ground-Truth-Regelsuiten der Wettbewerber geerntet (Betterleaks- und Kingfisher-Regeln; 1.057 markierte Positive, 1.342 Negative, 772.974 Bytes). Toolübergreifende Auswertung auf Wettbewerber-Ground-Truth.

| Rang | Scanner | F1 | Präzision | Trefferquote | Funde | Wandzeit | Spitzen-RSS |
|---|---|---|---|---|---|---|---|
| 1 | **KeyHog** | **0.9214** | 0.9582 | 0.8874 | 979 | 0.72s | 384 MB |
| 2 | Betterleaks | 0.9056 | 0.9130 | 0.8984 | 1040 | 0.58s | 192 MB |
| 3 | Kingfisher | 0.8842 | 0.9250 | 0.8468 | 968 | 2.14s | 390 MB |
| 4 | TruffleHog | 0.4812 | 0.9850 | 0.3226 | 345 | 1.22s | 280 MB |
| 5 | Titus | 0.4635 | 0.3810 | 0.5913 | 1640 | 2.15s | 110 MB |
| 6 | Nosey Parker | 0.4520 | 0.3950 | 0.5280 | 1412 | 0.68s | 265 MB |
### Ergebnis-Herkunft

| Scanner | Scanner-Version / ausführbarer Digest | Korpus-Identität | Host-Identität | Laufdatum |
|---|---|---|---|---|
| KeyHog | Version: KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Detektor-Set: 926 (926-4168e2c6c93a16ca)<br>Build-Ziel: x86_64-linux<br>ML-Modellversion: moe-v1-246a05b92bec9aa3<br>ML-Modellkarte: aufgezeichnet 2026-07-15; Merkmale 55; synthetisch F1 0.971 / P 0.945 / R 0.999; real F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; Null-Trefferquote-Detektoren 2/32; Sechs-Scanner-Differential nicht verfügbar<br>ausführbarer SHA-256: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:29:39Z |
| TruffleHog | Version: trufflehog 3.96.0<br>ausführbarer SHA-256: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:29:58Z |
| Kingfisher | Version: kingfisher 1.94.0<br>ausführbarer SHA-256: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:29:50Z |
| Titus | Version: Titus v1.1.20 (Go-Port von NoseyParker)<br>ausführbarer SHA-256: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:30:03Z |
| Nosey Parker | Version: noseyparker 0.24.0 Build-Konfiguration: Build-Zeitstempel:    2025-05-08T21:11:15.600909923Z Commit-Zeitstempel:   2025-05-08T17:04:47.000000000-04:00 Commit-Zweig:      HEAD Commit-SHA:         61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Cargo-Funktionen:     color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Debug:              true Optimierung:       3 Ziel-Triple:      x86_64-unknown-linux-gnu Build-System: OS:                 Ubuntu OS-Version:         Linux (Ubuntu 22.04) CPU-Hersteller:         AuthenticAMD CPU-Marke:          AMD EPYC 7763 64-Core-Prozessor CPU-Kerne:          2 rustc-Version:      1.86.0 rustc-Kanal:      stable rustc-Host-Triple:  x86_64-unknown-linux-gnu rustc-Commit-Datum:  2025-03-31 rustc-Commit-SHA:   05f9846f893b09a1be1fc8560e33fc3c815cfecb rustc-LLVM-Version: 19.1<br>ausführbarer SHA-256: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:29:53Z |
| Betterleaks | Version: betterleaks version dev<br>ausführbarer SHA-256: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15.000 Fixtures; 3.000 markierte Positive; 2.431.242 Bytes | Hostname-SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core-Prozessor | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->

### Geschwindigkeit & Speicher

<!-- BENCH:perf:start -->
#### Synthetischer SecretBench-Form-Spiegelkorpus

| 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 |

#### Wettbewerber-Heimfeld / Heimterritorium-Regelkorpus

| Scanner | Konfiguration | Korpus | Wandzeit | Durchsatz | Spitzen-RSS |
|---|---|---|---|---|---|
| Betterleaks | `default-nocache-nodaemon-no-validate` | homefield | 0.58s | 1.3 MB/s | 192 MB |
| Nosey Parker | `default-nocache-nodaemon-no-git-history` | homefield | 0.68s | 1.1 MB/s | 265 MB |
| KeyHog | `simd-nocache-nodaemon-full` | homefield | 0.72s | 1.1 MB/s | 384 MB |
| TruffleHog | `default-nocache-nodaemon-no-verify` | homefield | 1.22s | 0.6 MB/s | 280 MB |
| Titus | `default-nocache-nodaemon-no-validate` | homefield | 2.15s | 0.4 MB/s | 110 MB |
| Kingfisher | `default-nocache-nodaemon-low-no-validate` | homefield | 2.14s | 0.4 MB/s | 390 MB |
<!-- BENCH:perf:end -->

### Trefferquoten-Vergleich pro Kategorie

<!-- BENCH:gaps:start -->
_Diagnostischer Trefferquoten-Ausschnitt nur. 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 | Trefferquoten-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 begrenzter statischer Wiederherstellung

<!-- BENCH:recovery:start -->
Ausgewählter Lauf: Scanner **KeyHog** `KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Detektor-Set: 926 (926-4168e2c6c93a16ca)<br>Build-Ziel: x86_64-linux<br>ML-Modellversion: moe-v1-246a05b92bec9aa3<br>ML-Modellkarte: aufgezeichnet 2026-07-15; Merkmale 55; synthetisch F1 0.971 / P 0.945 / R 0.999; real F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; Null-Trefferquote-Detektoren 2/32; Sechs-Scanner-Differential nicht verfügbar`; Korpus **mirror** (15.000 Fixtures, 2.431.242 Bytes); generiert `2026-08-11T01:29:39Z`; Artefakt `mirror-keyhog-simd-nocache-nodaemon-full.json`.

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

| Einstufung | Exakte Anzahl |
|---|---:|
| Unterstützt | 0 |
| Nicht unterstützt | 0 |
| Fehlerhaft | 0 |

| Ablehnungsgrund | Exakte Anzahl |
|---|---:|
| _keiner_ | 0 |
<!-- BENCH:recovery:end -->

### Bigram-Bloom-Evidenz

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

| Feld | Exaktes Ergebnis |
|---|---|
| Korpus | `samsung-creddata-fx-record-spans-v1` |
| Korpus-Revision | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| Korpus-SHA-256 | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| Fixture-SHA-256 | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| Ausführbarer SHA-256 | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| Arbeitsbereich-Detektorkorpus-SHA-256 | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Scanner-Detektor-Digest | `8d789251e092959f` |
| Detektorkorpus-SHA-256 | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Bloom-Ablehnung | **110/51794 (0.21%)**; 51684 zugelassen |
| Externe Verfügbarkeit | 51794 gemessen; 0 explizit nicht verfügbar von 51794 deklariert; Gründe:  |
| Aktivierte vs. umgangene Funde | **IDENTISCH**; 977/977 Funde |
| Fund-Identitäts-SHA-256 | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Bloom-Dichte/Zustand | 1793/65536 Slots; `healthy`; Sättigung bei 39322 |

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

Reproduzieren: `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
führt den exakten KeyHog-, Betterleaks-, Kingfisher-, Nosey-Parker-, TruffleHog- und
Titus-Spiegellauf-Satz erneut aus, einschließlich des ausführungsgebundenen CredData-Bloom-Differentials,
`make -C benchmarks report` regeneriert die obigen Tabellen und
`benchmarks/reports/`. Siehe [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
für die Korpora (mirror, Wettbewerber-Heimterritorium, 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
Quellenrichtlinien-Metadaten; der Daemon liest und stapelt die Dateien in seinem eigenen
Prozess. 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

--daemon=mass ist eine erforderliche Route. Sie wiederholt nie innerhalb des Prozesses. Jeder Batch ist auf 8 MiB und 1.024 Chunks begrenzt, unabhängig von der Gesamtgröße der Eingabe. Bewahren Sie die Abdeckungshülle, den Exit-Status und den Terminal-Ausführungsbeleg für jede Inventarpartition auf.

Siehe Daemon-Lebenszyklus, Routing und Belege und Inventarpartitionierung.

Systemweite Anmeldedaten-Triage```sh

sudo keyhog scan-system --space 50G sudo keyhog scan-system --include-network --output system-findings.json

`scan-system` ist eine begrenzte lokale Host-Prüfung, kein Ersatz für Repository- oder
Cloud-Inventar-Partitionierung. Es begrenzt sich selbst durch die insgesamt gescannten Bytes und nicht
durch den Pfad: `--space` ist die Obergrenze, und netzwerkgebundene Dateisysteme werden
übersprungen, es sei denn, Sie übergeben `--include-network`. Überprüfen Sie Mount-, Netzwerkdateisystem-,
Speicherplatz-Obergrenzen- und Privilegienverhalten, bevor Sie es ausführen. Siehe
[systemweite Triage](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).

## Sensible lokale Scans sperren

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

Es sperrt den aktuellen und zukünftigen Speicher, deaktiviert Core-Dumps und den inkrementellen Cache, bleibt im Prozess und verweigert Verifizierung, Klartextausgabe, den schnellen Modus und Schalter, die die Vollständigkeit reduzieren. Es schlägt auf nicht unterstützten Plattformen oder bei unzureichender Kapazität für gesperrten Speicher fehl. Siehe Härtung und Datenverarbeitung.

KeyHog als Rust-Bibliothek verwenden```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();

Die Standard-Bibliotheksmethoden sind deterministische portable CPU-Referenzen. Explizite
Backend-Methoden geben typisierte Fehler zurück, anstatt den Prozess zu beenden oder
still einen anderen Engine zu substituieren. Rohe Chunks und Treffer können
Klartext enthalten. Konvertieren Sie diese mit `RawMatch::to_redacted` oder verwenden Sie finale
`VerifiedFinding`-Werte, bevor JSON, Logs, Datenträger oder Netzwerkgrenzen überschritten werden.

Der [Architektur-Leitfaden](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) definiert Crate-Eigentum,
Backend-Verträge, Wiederherstellungsbelege, Quell-Helfer und sichere Berichterstattungs-
grenzen. Die Rust-Dokumentation auf Crate-Ebene besitzt die vollständige API.

## Richtlinie mit expliziter Priorität konfigurieren

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

[scan]
severity = "high"
incremental = true

[system]
gpu = "auto"

Die Auflösungsreihenfolge ist: integrierte Standardwerte, Benutzerkonfiguration, Repository-Konfiguration, Umgebung, sofern dokumentiert, und schließlich explizite CLI-Überschreibungen. Unbekannte Schlüssel und ungültige Kombinationen schlagen vor dem Scannen fehl. Führen Sie keyhog config --effective aus, um die aufgelöste Richtlinie zu prüfen, ohne Proxy-Anmeldeinformationen offenzulegen. Einträge nach expires schlagen beim Laden der Zulassungsliste vor dem Scannen fehl.

Siehe Konfiguration und Rangfolge für jeden Schlüssel und Umgebungsvariablen für Anmeldeinformationen und Laufzeiteingaben.

Architektur

KeyHog hält die Orchestrierung an der Grenze und das Domänenverhalten in Bibliotheken:```text sources -> scanner -> suppression/evidence -> reporting -> optional verifier CLI and Action own process, transport, and exit semantics.

Detektor-Definitionen bleiben Daten unter `detectors/`. `keyhog-core` besitzt
die Detektor- und Fundtypen, `keyhog-scanner` besitzt die Matching- und Ausführungs-
Backends, `keyhog-sources` besitzt die Eingabeerfassung, `keyhog-verifier` besitzt die Live-
Prüfungen, und `keyhog-cli` besitzt die Operator-Workflows.

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

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

Die CLI-Referenz listet jeden Befehl, jedes Flag, jeden generierten Standardwert und jeden Exit-Status auf. Verwende keyhog --help und keyhog <command> --help für die exakt installierte Version.

Mitwirken

Neuer Detektor? Lege eine TOML-Datei in detectors/ ab und erstelle einen PR. Der Mitwirkenden-Leitfaden (CONTRIBUTING.md) enthält das Schema und ein ausgearbeitetes Beispiel.
Fehler / übersehenes Geheimnis / falsch-positiv? Melde ein Issue mit der geschwärzten Anmeldedaten-Form und der Detektor-ID; jeder Bericht wird zu einer dauerhaften Test-Fixture unter crates/scanner/tests/contracts/.
Release-Verhalten? Jeder erfolgreiche main-CI-Lauf erhöht die Patch-Version, generiert Changelogs und veröffentlicht alle sechs Crates auf crates.io. Füge für einen präzisen Hinweis optional ein Fragment unter changes/ hinzu. Der Release-Leitfaden behandelt die automatische Transaktion und die Wiederherstellung nach fehlgeschlagenen Uploads.
Sicherheitsproblem in KeyHog selbst? Öffne kein öffentliches Issue; nutze die private Schwachstellenmeldung von GitHub. Falls dieses Formular nicht verfügbar ist, sende eine E-Mail an [email protected]; PGP ist nicht erforderlich.

Changelog. Offene Issues.

Danksagungen

KeyHog baut auf früheren Secret-Scanning-Arbeiten auf. Ideen übernommen von:

TruffleHog: Detektor-Breite und Verifizierungssemantik
Betterleaks: Token-Effizienz und Unterdrückung falsch-positiver Ergebnisse
Titus: Scan-Ergonomie und Schweregrad-Kalibrierung

Dank an diese Projekte und ihre Mitwirkenden.

Lizenz

Lizenz: MIT OR Apache-2.0.

Bedingungen: MIT und Apache-2.0. Diese Dual-Lizenz deckt den Code und die Detektor-TOMLs ab. Kommerzielle Nutzung, Einbettung, Forks und gehostete Dienste sind unter beiden Lizenzen gestattet.

Stern-Verlauf

_{Generiert aus UTC-Beobachtungen der öffentlichen GitHub-Sternanzahl. Das Repository speichert den ersten Punkt und jeden späteren Zählübergang. Wiederholungen am selben Tag ersetzen den Punkt des Tages, und unveränderte Zählungen erzeugen keinen Commit.}