Scanner de secrets open source en Rust
Site web · Documentation · Architecture · Moteur GPU Vyre
KeyHog est un scanner de secrets open source en Rust qui détecte et vérifie les clés API, jetons, mots de passe et identifiants divulgués dans le code source, l'historique Git, les conteneurs, le stockage cloud, les actifs de navigateur, le contenu collaboratif et les systèmes en cours d'exécution.
La plupart des scanners de secrets s'arrêtent aux correspondances regex CPU dans une copie de dépôt. KeyHog combine 934 détecteurs spécifiques à chaque service, le décodage des identifiants dissimulés, les preuves contextuelles et la suppression, la vérification en direct auprès des fournisseurs, et une exécution de premier ordre CUDA, Metal et WGPU via Vyre. La calibration mesure chaque backend CPU purement Rust éligible, Hyperscan/SIMD et GPU. Le routage automatique utilise ensuite la route la plus rapide prouvée par parité pour l'hôte et la classe de charge de travail exacts.
| Le GPU est un vrai backend | Analysez la surface d'attaque réelle | Séparez le signal du bruit | Agissez sur le résultat |
|---|---|---|---|
| CUDA, Metal natif et WGPU sont des pairs mesurés, pas une chaîne de repli silencieuse. | Analysez l'historique Git, les couches Docker, les archives, les buckets cloud, les source maps, WASM, les captures HAR, les collections Git hébergées et des systèmes entiers. | Décodez base64, hex, URL, protobuf, multiligne et la configuration structurée avant d'appliquer les preuves, la suppression d'exemples et les lignes de base. | Vérifiez les identifiants éligibles avec les API des fournisseurs, émettez des enveloppes SARIF ou structurées, et préservez la couverture exacte et la sémantique de sortie. |
| cargo install --locked keyhog | |||
| keyhog scan . |
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="Analyse KeyHog montrant la sévérité, les preuves, le fichier et la ligne, la remédiation, les résultats et l'état de couverture" width="900" />
</p>
## Un scanner de secrets conçu autour du GPU
KeyHog ne confie pas quelques expressions régulières à un compute shader générique.
Son chemin GPU repose sur [Vyre](https://github.com/santhreal/vyre), un substrat
de calcul GPU en Rust développé en parallèle de KeyHog. Les déclencheurs de détection
sont compilés en tables immuables résidant sur le GPU. Des lots de sources bornés
produisent des positions de correspondance complètes pour le même pipeline de
confirmation, de suppression, de preuve et de rapport utilisé par les routes CPU et Hyperscan.
- **Troix pairs GPU physiques.** CUDA, Metal natif et WGPU portable sont
acquis, mesurés et rapportés indépendamment.
- **Parité exacte des résultats.** La calibration rejette un candidat dont
l'identité de résultat diffère de la route de référence. Une réponse erronée plus rapide
n'entre jamais dans la table de routage.
- **Preuve de route persistante.** KeyHog enregistre le binaire, le corpus de détecteurs,
la configuration, la classe de charge de travail, l'hôte, l'accélérateur, le pilote et les
preuves de timing mesurées. Les analyses normales ne benchmarkent pas dans le chemin critique.
- **Exécution résidente.** Les workers du démon maintiennent les détecteurs compilés et l'état
de l'accélérateur à chaud pour les lots répétés de fichiers, d'archives, d'historique, distants et cloud.
- **Aucune échappatoire CPU cachée.** Un accélérateur explicitement sélectionné qui ne peut pas
s'initialiser ou se répartir échoue de manière visible au lieu de renvoyer des résultats CPU sous
une étiquette GPU.
L'installation par défaut via crates.io utilise la route CPU pure-Rust portable afin de fonctionner
sur un hôte Rust propre. Activez les trois pairs GPU sans acquérir Hyperscan :```sh
cargo install --locked keyhog --no-default-features --features portable,gpu
Activez le pair regex SIMD Hyperscan ou Vectorscan :```sh cargo install --locked keyhog --no-default-features --features portable,simd
Exécutez le diagnostic du backend de production, puis inspectez la route mesurée :```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
Le guide du backend documente les tables résidentes, le modèle de dispatch borné, le contrat de parité et les preuves de croisement reproductibles.
Les deux commandes ci-dessus installent la dernière version de crates.io et analysent l’arborescence actuelle avec la route portable pure-Rust.
Épinglez un environnement CI à une version exacte avec
cargo install --locked --version '=0.5.86' keyhog. KeyHog nécessite Rust 1.89
ou plus récent. Consultez le guide d’installation
pour les profils GPU, Hyperscan, CI, portable et de compilation depuis les sources.
KeyHog se termine avec le code 1 lorsqu’un résultat bloque la politique de preuve active. La politique
par défaut bloque les résultats likely et confirmed tout en gardant les résultats review
visibles avec le code 0 ; --evidence-policy paranoid bloque chaque niveau. Examinez
le niveau de preuve exact, le code de raison, le fichier, la ligne, le détecteur et la
remédiation de chaque résultat. Les autres codes non nuls décrivent des échecs d’entrée, système, de vérification ou
de couverture ; consultez la
référence des codes de sortie.
Le contrat de processus complet est le suivant :
| Sortie | Signification |
|---|---|
0 succès | Aucun résultat ne bloque la politique de preuve active, et aucune défaillance de couverture ne s’est produite. Les résultats de niveau review peuvent rester visibles sous la politique par défaut. |
1 résultats bloquants | Au moins un résultat bloque la politique de preuve active, mais aucun n’a été confirmé comme actif. |
2 erreur de l’opérateur | Corrigez les arguments, la configuration, le corpus de détecteurs ou l’entrée corrigeable par l’opérateur. |
3 erreur système | Réparez ou réessayez l’exécuteur. Cela inclut les E/S de bas niveau, le service démon fatal, le cache incrémental et les échecs SIMD explicitement sélectionnés. |
4 échec de santé/auto-test | Un contrôle de santé doctor ou backend --self-test était non sain. |
10 identifiants actifs | Au moins un identifiant a été confirmé comme actif. |
11 panique du scanner | Ignorez le résultat de l’analyse car l’état du scanner n’est pas fiable. |
12 échec GPU requis | Un chemin GPU explicitement sélectionné ou requis n’a pas pu s’exécuter. |
13 couverture incomplète | Une source demandée a échoué ou la couverture d’entrée était incomplète, et aucun résultat ne l’a emporté. |
130 interrompu | SIGINT ou Ctrl-C a interrompu le processus. |
Filtrer, formater, contrôler :
Créez une ligne de base avant de l’utiliser comme filtre :```sh keyhog scan . --create-baseline .keyhog-baseline.json keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json
La première commande enregistre les résultats examinés et se termine avec le code `0` sans les afficher. Validez ce fichier, puis utilisez la seconde commande pour ne signaler que les nouvelles identités de secrets. Une entrée de référence correspond au détecteur et à la valeur de l’identifiant, jamais au chemin du fichier, donc déplacer un secret enregistré ne fait pas échouer la validation, mais le faire pivoter, si. Les identifiants modifiés et la couverture incomplète restent visibles. Le chemin complet, y compris les partitions de monorepo, est [Échouer uniquement sur les nouveaux secrets](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets).
Pour la prochaine analyse, utilisez le [livre de recettes](https://santhreal.github.io/keyhog/recipes.html) ou les commandes copiables dans [Choisir le bon workflow](#choose-the-right-workflow). Vous pouvez analyser l’historique Git, les images de conteneurs, les buckets cloud, les collections de dépôts, les URL et une machine entière sans changer d’outil.
### Protéger les dépôts pour des analyses pré-commit rapides
Enregistrez un dépôt avec le démon KeyHog permanent pour une détection rapide de secrets avant chaque commit (nécessite Unix ; sous Windows, utilisez `keyhog scan` en processus) :```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
Voir le guide du gardien perpétuel et le workflow pre-commit pour la configuration complète, le cycle de vie de la machine à états et l’automatisation des hooks.
Créez .github/workflows/keyhog.yml :```yaml
name: keyhog
on:
push:
branches: [main]
pull_request:
permissions:
contents: read
security-events: write
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
- uses: santhreal/keyhog@v0
with:
path: .
severity: high
L'action analyse l'arborescence extraite, échoue sur les résultats de gravité `high` ou `critical`, téléverse le SARIF vers Code Scanning et conserve le rapport comme artefact de workflow. Les échecs d'installation, de couverture, de backend et de publication du rapport font également échouer le job.
Consultez le [guide GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) pour les entrées, les sorties, l'adoption de la ligne de base, les partitions de monorepo, la vérification et le comportement en cas d'échec. Consultez le [guide CI](https://santhreal.github.io/keyhog/workflows/ci.html) pour GitLab, CircleCI, Jenkins, Buildkite et les jobs shell génériques. Consultez le [guide de scan de masse](https://santhreal.github.io/keyhog/guides/mass-scanning.html) pour les organisations de dépôts, les groupes Git hébergés, les buckets cloud et les inventaires partitionnés.
## Surfaces de scan que d'autres outils traitent comme des produits distincts
KeyHog analyse les octets à la frontière où ils peuvent fuir, pas seulement les fichiers sources suivis. Utilisez un rapport par frontière afin que la CI conserve la couverture exacte et l'état d'échec.
| Surface d'exposition | Exemple |
|---|---|
| Artefact de package final | Exécutez `npm pack`, puis analysez le `.tgz` produit avec `keyhog scan package.tgz`. L'expansion d'archive vérifie les fichiers générés, les source maps, les fixtures et les métadonnées absents de l'arborescence source attendue. |
| Application de navigateur déployée | `keyhog scan --url https://app.example.com/assets/app.js` suit le décodage JavaScript, source-map, WASM et des réponses de manière bornée sans transformer le scanner en crawler illimité. |
| Issues GitHub, pull requests, discussions, wikis et gists | `keyhog scan --github-collaboration owner/repo --github-all` analyse chaque surface de collaboration en dehors de l'extraction. |
| Configuration d'agent IA et MCP | `keyhog scan ~/.config ~/.claude ~/.codex` applique le même pipeline de détection, décodage, preuve et rapport à la configuration locale des outils. |
| Couches d'images conteneur | `keyhog scan --docker-image registry.example.com/team/app:v1` analyse le contenu de l'image qui sera exécuté, y compris les fichiers introduits pendant la construction. |
| Inventaires d'objets cloud | `keyhog scan --s3-bucket BUCKET`, `--gcs-bucket BUCKET` ou `--azure-container-url URL` préserve la pagination du fournisseur, les objets et la couverture des limites d'octets dans le rapport terminal. |
| Hôte de développement entier | `sudo keyhog scan-system --space 50G` découvre les systèmes de fichiers montés et l'historique Git accessible sous un budget de stockage strict. |
Ces routes partagent un contrat unique de détection et de rapport. Un échec spécifique à une source ne peut pas se transformer silencieusement en un scan local plus restreint.
## Choisir le bon workflow
Choisissez d'abord la frontière de la source. Un préréglage modifie le travail de détection, tandis qu'un backend modifie l'exécution. Ni l'un ni l'autre n'étend un scan d'arborescence de travail à l'historique Git, à un inventaire de fournisseur, au stockage cloud ou à un audit d'hôte.
Il n'existe pas de raccourci honnête `scan everything`. Un examen complet du patrimoine exécute les frontières pertinentes ci-dessous comme des jobs séparés et conserve chaque rapport `json-envelope` avec son code de sortie brut.
| Besoin | Commencer par | Débit et réutilisation | Frontière de couverture |
|---|---|---|---|
| Retour rapide local | `keyhog scan . --fast --incremental` | Réutilise les hachages de fichiers inchangés. Le préréglage rapide ignore le décodage, l'entropie et le travail ML. | Exécutez la politique par défaut avant la fusion car le mode rapide est volontairement plus restreint. |
| Scan complet du dépôt | `keyhog scan .` | `auto` calibré et le défaut de workers par cœur CPU. Ajoutez `--incremental` pour les scans répétés de la même arborescence de confiance. | Fichiers actuels uniquement. Il n'ajoute pas l'historique Git. |
| Porte de commit stagé | `keyhog scan --git-staged` ou `keyhog hook install` | Lit les blobs d'index exacts, donc les modifications non stagées ne peuvent pas changer le résultat. | Contenu stagé uniquement. Exécutez un scan d'arborescence de travail séparément lorsque les octets locaux non stagés comptent. |
| Garde perpétuelle du dépôt | `keyhog guard add . --mode repo` puis `keyhog guard status .` | Registre racine résident en démon avec une machine à 7 états, cache d'attestation propre et suivi d'identité de politique. | Nécessite un démon en cours d'exécution. La garde complète, ne remplace pas, les scans stagés et d'arborescence de travail. |
| Porte de pull request GitHub | `santhreal/keyhog@v0` | L'action installe, analyse, publie le SARIF et un artefact, puis préserve le statut de KeyHog. | Un chemin extrait. Utilisez le scan d'inventaire de fournisseur pour une organisation. |
| GitLab, Jenkins, Buildkite ou shell CI | `keyhog scan . --format json-envelope --output keyhog.json` | Persistez le rapport et le code de sortie en cas de succès, de résultats et d'erreurs. Utilisez `--git-diff <base>` uniquement pour une porte de lignes modifiées explicitement plus restreinte. | Les octets présents dans l'extraction, ou le diff sélectionné. |
| Adopter un dépôt avec des résultats connus | Créez `.keyhog-baseline.json`, committez-le, puis analysez avec `--baseline .keyhog-baseline.json`. | Les identités existantes restent visibles dans la ligne de base tandis que seuls les nouveaux résultats font échouer la porte. | Une ligne de base ne supprime pas les identifiants modifiés ni la couverture incomplète. |
| Récupération Git récursive | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | Calibrez la politique profonde une fois par classe de worker. Exécutez en processus. | Un dépôt. `--git-history` couvre uniquement l'ascendance de l'extraction actuelle, donc une branche jamais extraite est manquée sans écart de couverture ; `--git-blobs` atteint également les blobs orphelins, les commits amendés, les stashes, les notes, les messages de tags annotés et les refs empaquetées. |
| Inspection de conteneur ou d'archive | `keyhog scan --docker-image registry/app:v1` ou `keyhog scan incoming/` | Conservez un rapport d'enveloppe afin que les membres ignorés, corrompus, chiffrés, non sûrs ou surdimensionnés restent visibles. | Uniquement l'image ou le chemin de système de fichiers sélectionné et les formats imbriqués pris en charge. |
| Inspection d'URL, de réponse ou de HAR | `keyhog scan --url https://api.example.com/config` ou `keyhog scan capture.har` | Utilisez des limites de source bornées et préservez l'enveloppe terminale. | Uniquement les réponses récupérées ou les entrées de capture. Ce n'est pas un crawler. |
| Inventaire d'organisation ou cloud | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | Partitionnez par fournisseur, propriétaire ou bucket. Exécutez des partitions indépendantes en parallèle avec un rapport et un statut chacun. | Un inventaire de fournisseur sélectionné par job. Les limites de pagination ou d'objets restent des frontières de couverture. |
| Confirmer si les résultats éligibles sont actifs | `keyhog scan . --verify` | La concurrence et les contrôles de débit du fournisseur sont séparés des workers du scanner. | Envoie des requêtes dérivées des identifiants aux points de terminaison déclarés du fournisseur. Tous les détecteurs ne prennent pas en charge la vérification. |
| Scan de santé de l'hôte entier | `sudo keyhog scan-system --space 50G` | Utilise tous les cœurs CPU par défaut et analyse l'historique Git découvert après les données du système de fichiers. | Systèmes de fichiers locaux montés. Les montages réseau sont facultatifs et le plafond d'espace est strict. |
| Inventaire de répertoire, historique, archive, distant ou cloud accéléré GPU sur Unix | Calibrez l'auto-routage, démarrez `keyhog daemon start --mass`, puis exécutez `keyhog scan --daemon=mass <SOURCE>`. | Diffuse des lots bornés via un worker compilé CPU, Hyperscan, CUDA, Metal ou WGPU. Ajoutez `--incremental` pour les arborescences de fichiers système chaudes inchangées. Le reçu terminal rapporte les totaux exacts et les lots GPU, les chunks, les octets, la part GPU et le débit. | Les lignes de base, la vérification, le verrouillage, les préréglages, les overlays et autres changements de politique du scanner sont rejetés avant l'acquisition. L'état incrémental s'applique uniquement aux racines de système de fichiers locales du démon. |
### Analyser chaque frontière de source prise en charge
Utilisez une commande par frontière. Conservez un rapport `json-envelope` et le statut de sortie brut pour chaque partition d'inventaire.
| Source ou cas d'usage | Commande |
|---|---|
| Plusieurs racines locales | `keyhog scan services/api services/web deploy/` |
| Fichiers modifiés en continu | `keyhog watch services/api deploy/` |
| Octets stagés, lignes modifiées, historique atteignable ou blobs | `keyhog scan --git-staged`, `--git-diff main`, `--git-history .` ou `--git-blobs .` |
| Binaires natifs et chaînes de firmware | `keyhog scan --binary firmware.bin` (un scan de répertoire simple ignore les binaires et sort toujours avec `0`) |
| Archives et sources compressées | `keyhog scan incoming/` (les membres pris en charge se développent automatiquement) |
| Couches d'images Docker | `keyhog scan --docker-image registry/app:v1` |
| JavaScript, source maps, WASM ou réponse de point de terminaison | `keyhog scan --url https://api.example.com/config` |
| Captures de requêtes et réponses HTTP | `keyhog scan capture.har` |
| Issues GitHub, pull requests, discussions, wikis et gists | `keyhog scan --github-collaboration owner/repo --github-all` |
| Inventaires GitHub, GitLab ou Bitbucket | `--github-org ORG`, `--gitlab-group GROUP` ou `--bitbucket-workspace WORKSPACE` |
| Inventaires S3, GCS ou Azure Blob | `--s3-bucket BUCKET`, `--gcs-bucket BUCKET` ou `--azure-container-url URL` |
| Un flux borné depuis un autre outil | `producer \| keyhog scan --stdin` (utilisez `set -o pipefail` pour qu'un producteur en échec fasse remonter sa propre erreur, pas un scan de zéro octet) |
Un scan de répertoire simple ne lit pas les binaires natifs. Chacun devient un écart de couverture `binary (extension or content sniff)`, le scan sort toujours avec `0`, et `--no-default-excludes` ne change pas cela, donc passez `--binary` lorsque les artefacts compilés sont dans le périmètre. Ce drapeau nécessite une compilation avec la fonctionnalité `binary`, que l'installation crates.io par défaut possède et que la fonctionnalité allégée `ci` ne possède pas.
L'extraction de binaires natifs rapporte des identifiants complets qui satisfont le contrat de forme explicite d'un détecteur nommé. Elle supprime les fragments de préfixe courts et les chaînes génériques en forme d'assignation des sections de données compilées car ces octets ne conservent pas le contexte source.
La récupération de points de terminaison est bornée et filtrée contre le SSRF. Ce n'est pas un crawler. Les points de terminaison cloud privés et le transfert d'identifiants nécessitent leurs drapeaux de confiance explicites. Les jetons de fournisseur appartiennent aux variables d'environnement documentées, pas aux arguments de processus.
Consultez le [sélecteur de workflow](https://santhreal.github.io/keyhog/capabilities.html) pour les détails de source et de politique, le [guide GitHub Action](https://santhreal.github.io/keyhog/workflows/github-action.html) pour la porte de dépôt maintenue, le [guide CI direct](https://santhreal.github.io/keyhog/workflows/ci.html) pour les rapports durables et la gestion des sorties, et le [guide de scan de masse](https://santhreal.github.io/keyhog/guides/mass-scanning.html) pour le partitionnement et l'agrégation. Le [livre de recettes](https://santhreal.github.io/keyhog/recipes.html) couvre les conteneurs, les archives, les URL, le contenu de collaboration GitHub et les sources cloud.
### Vitesse et concurrence sans conjectures
Commencez par les valeurs par défaut. Cargo ne peut pas exécuter KeyHog après `cargo install`, donc exécutez les commandes ci-dessous une fois après l'installation d'une compilation Cargo multi-backend et à nouveau après un changement de l'hôte, du binaire, du corpus de détecteurs, du pilote ou des classes de charge de travail :```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
| Contrôle | À utiliser pour | Conserver cet invariant |
|---|---|---|
--backend auto calibré | Sélection de routine CPU, Hyperscan ou GPU. | Un backend explicite est une surcharge de diagnostic, pas un défaut plus rapide. |
--threads <N> | Réserver la capacité CPU sur un exécuteur partagé. Les hôtes dédiés devraient normalement le laisser non défini afin que KeyHog utilise les cœurs disponibles. | Chaque valeur doit être positive. Plusieurs processus KeyHog concurrents possèdent chacun un pool de travailleurs, donc divisez le budget de l’hôte entre les partitions. |
--reader-threads <N> | Pipelines de stockage mesurés où le travail du lecteur, et non l’analyse, est le goulot d’étranglement. | La valeur par défaut dérive du pool de travailleurs d’analyse. Laissez-le non défini jusqu’à ce que le profilage montre un goulot d’étranglement du lecteur. |
--incremental et --incremental-cache <PATH> | Analyses répétées du même arbre de confiance. | Ne partagez pas un index entre des dépôts sans rapport ou des tâches non fiables. |
| Partitions de fournisseur ou de dépôt | Analyse concurrente du parc et nouvelles tentatives indépendantes. | Préservez une enveloppe terminale et un code de sortie brut par partition. Ne concaténez pas les résultats et ne jetez pas l’état de couverture. |
--verify-concurrency, --verify-rate et --verify-batch | Limiter les vérifications actives du fournisseur indépendamment de l’analyse des fichiers. | La vérification envoie des requêtes dérivées des identifiants. Les limites de débit du fournisseur, et non le nombre de CPU, possèdent cette concurrence. |
| Démon de masse | Flux de répertoires, d’historique, d’archives, distants ou cloud à l’échelle du To sur un seul travailleur Unix. | Chaque trame est limitée à 8 Mio et 1 024 fragments. Le démon sérialise l’état des fragments et renvoie un reçu d’exécution CPU/GPU exact. |
--fast, défaut, --deep ou --precision | Sélection d’une politique explicite de coût de détection et de rappel. | Ces préréglages sont mutuellement exclusifs et modifient la couverture. Ils ne sont pas des boutons de vitesse interchangeables. |
Inspectez la politique résolue avec keyhog config --effective. Utilisez --profile
pour mesurer les étapes fixes du scanner et l’exécution complète de l’opérateur avant de modifier
les contrôles de lecteur, de lot ou de profondeur de canal. Le rapport à faible surcharge enregistre
la source, le backend, le cache, la charge de travail, les threads, l’entrée, les transitions d’état, le temps CPU,
le pic de mémoire, le SHA-256 binaire exact, le SHA-256 des fonctionnalités activées, le triplet cible, le profil
de build, le compilateur, l’allocateur, le SHA-256 du backend lié, le SHA-256 du corpus de détecteurs,
le BLAKE3 des détecteurs activés, le BLAKE3 du plan compilé, la provenance hachée des détecteurs,
le BLAKE3 complet de la configuration résolue, le BLAKE3 de la politique de performance, le préréglage,
l’état de protection appliqué, les adaptateurs de source, le BLAKE3 haché de la cible source,
le BLAKE3 haché de la partition source, les octets bruts de la source, le fanout des unités source,
les octets dérivés du décodage, les octets complétés de la répartition du backend, et les compartiments stables
de taille/fanout. Les domaines d’octets que leur adaptateur de source ne peut pas encore distinguer restent
explicitement indisponibles au lieu de devenir des zéros mesurés. Le rapport n’enregistre
pas le contenu de la source, les valeurs d’identifiants, les chemins bruts, les URL brutes ni les valeurs
brutes de configuration. Utilisez --perf-trace uniquement pour les compteurs de diagnostic coûteux par motif et
par backend.
Laissez les contrôles avancés du pipeline non définis sauf si une mesure reproductible sur le
travailleur cible montre une amélioration.
Pour une analyse récurrente complète du dépôt :```sh
keyhog scan . --incremental
--format json-envelope --output keyhog.json
Pour un runner partagé où le job se voit allouer quatre workers de scan et un
worker de lecture :```sh
keyhog scan . --threads 4 --reader-threads 1 \
--format json-envelope --output keyhog.json
La deuxième commande est un budget de ressources, pas un optimum universel. Mesurez l'hôte cible avant de choisir des nombres de workers explicites.
Pour la récupération approfondie et le tri à l'échelle du système, utilisez leurs guides dédiés car leur couverture et leurs règles de complétion diffèrent d'un scan de dépôt normal.
Ces panneaux comparent la politique de détection, les requêtes d'exécution CPU et GPU, le comportement du cache incrémental et les requêtes de démon à chaud. Chaque valeur est générée à partir de l'instantané de benchmark vérifié. L'instantané lie la version du scanner, le digest de l'exécutable, le digest du détecteur, le corpus, l'hôte et l'horodatage d'exécution. Utilisez les preuves complètes du benchmark pour la provenance des concurrents et le rappel par catégorie.
KeyHog KeyHog v0.5.70 a scanné le corpus mirror : 15 000 fixtures, 3 000 positifs étiquetés et 2 431 242 octets d'entrée. Le manifeste de la clé de réponse a été exclu de l'arbre de scan. La ligne utilise la politique par défaut sur la route explicite Hyperscan/SIMD sur AMD Ryzen 9 9950X 16-Core Processor.
| Précision | Rappel | F1 | Vrais positifs | Faux positifs | Faux négatifs |
|---|---|---|---|---|---|
| 0.9651 | 0.9027 | 0.9328 | 2 708 | 98 | 292 |
L'arbre source suivi était propre.
Mesuré sur AMD Ryzen 9 9950X 16-Core Processor avec NVIDIA GeForce RTX 5090, 32 cœurs logiques, 15 000 fixtures, 3 000 positifs étiquetés et 2 431 242 octets d'entrée. Scanner : KeyHog v0.5.70. L'arbre source suivi était propre.
Toutes les lignes utilisent la politique de détection par défaut avec le cache incrémental et le démon désactivés. La ligne automatique enregistre la politique demandée, mais le résultat du benchmark ne lie pas la route persistée sélectionnée, ce n'est donc pas une preuve de routage. Les lignes GPU incluent l'acquisition et le démarrage complet du scanner sur ce petit corpus ; ce ne sont pas des mesures de croisement de noyaux GPU.
| Route demandée | Mur | Débit | RSS de pointe | F1 |
|---|---|---|---|---|
| Hyperscan/SIMD | 860 ms | 2,70 Mo/s | 416 Mio | 0.9328 |
| CPU Pure-Rust | 903 ms | 2,57 Mo/s | 509 Mio | 0.9328 |
| CUDA | 2,03 s | 1,14 Mo/s | 963 Mio | 0.9328 |
| WGPU | 1,97 s | 1,18 Mo/s | 1264 Mio | 0.9328 |
| Automatique | 1,46 s | 1,59 Mo/s | 634 Mio | 0.9328 |
La route, le cache, l'état du démon, le corpus et l'hôte restent fixes. Les préréglages modifient le travail de détection, comparez donc la précision et le rappel ainsi que le temps.
| Politique | Mur | Précision | Rappel | F1 | Résultats |
|---|---|---|---|---|---|
| Rapide | 737 ms | 0.9700 | 0.8837 | 0.9248 | 2 738 |
| Par défaut | 860 ms | 0.9651 | 0.9027 | 0.9328 | 2 816 |
| Approfondie | 861 ms | 0.9645 | 0.9067 | 0.9347 | 2 845 |
| Précision | 849 ms | 0.9590 | 0.6397 | 0.7674 | 2 001 |
Le benchmark remplit l'index Merkle BLAKE3, puis chronomètre le deuxième scan identique. Le petit arbre synthétique change peu car le démarrage du scanner domine ; mesurez votre dépôt avant de revendiquer une accélération.
| Politique par défaut Hyperscan/SIMD | Mur | Débit | RSS de pointe |
|---|---|---|---|
| Cache désactivé | 860 ms | 2,70 Mo/s | 416 Mio |
| Cache incrémental à chaud | 617 ms | 3,76 Mo/s | 457 Mio |
Un fichier régulier déterministe de 8 Mio (sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5) a été scanné une fois en processus et une fois via un démon détenu après une requête d'échauffement. Le temps du démon est la requête du client ; le RSS du démon appartient au serveur résident.
| Route explicite | En processus | Démon à chaud | Chaud / one-shot | RSS en processus | RSS du démon |
|---|---|---|---|---|---|
| Hyperscan/SIMD | 323 ms | 106 ms | 0,33× | 63 Mio | 74 Mio |
| CPU Pure-Rust | 278 ms | 109 ms | 0,39× | 62 Mio | 66 Mio |
| CUDA | 1,65 s | 232 ms | 0,14× | 674 Mio | 666 Mio |
| WGPU | 1,33 s | 237 ms | 0,18× | 596 Mio | 600 Mio |
Ces lignes couvrent la route de fichier unique à chaud. La route de masse accepte également des lots de répertoires bornés et de sources distantes ; son chemin de système de fichiers incrémental est mesuré séparément.
Généré par make -C benchmarks readme-scaling à partir de benchmarks/reports/readme-scaling.json. Le harnais a exécuté 3 essais mesurés après 1 échauffement avec routage simd explicite et démon désactivé. La mise à l'échelle des workers utilise un cache de pages client à chaud pour isoler le travail CPU. Les lignes de lecteur, de taille de corpus, de stockage et de partition demandent une éviction de pages propres avec posix_fadvise là où la plateforme le prend en charge ; l'instantané enregistre la politique sur chaque ligne. Chaque charge de travail est déterministe en octets et sans résultat.
Hôte : AMD Ryzen 9 9950X 16-Core Processor, 32 cœurs logiques effectifs, 94 140 Mio de RAM, Linux 6.17.0-19-generic. Preuve : clean, binaire 274b045489c4.
| Workers | Threads de lecteur | Mur médian | Mur p95 | Débit | Accélération | Efficacité | RSS de pointe médian |
|---|---|---|---|---|---|---|---|
| 1 | auto | 8 134,4 ms | 8 135,4 ms | 7,9 Mio/s | 1,00x | 100,0 % | 47,0 Mio |
| 2 | auto | 4 398,2 ms | 6 906,7 ms | 14,6 Mio/s | 1,85x | 92,5 % | 50,3 Mio |
| 4 | auto | 2 392,6 ms | 6 245,2 ms | 26,7 Mio/s | 3,40x | 85,0 % | 57,2 Mio |
| 8 | auto | 1 816,3 ms | 6 117,6 ms | 35,2 Mio/s | 4,48x | 56,0 % | 63,4 Mio |
| 16 | auto | 1 428,5 ms | 6 867,7 ms | 44,8 Mio/s | 5,69x | 35,6 % | 78,4 Mio |
| 32 | auto | 1 862,8 ms | 5 939,1 ms | 34,4 Mio/s | 4,37x | 13,6 % | 126,7 Mio |
| Workers de scan | Threads de lecteur | Mur médian | Mur p95 | Débit | Relatif à 1 lecteur | RSS de pointe médian |
|---|---|---|---|---|---|---|
| 32 | 1 | 1 898,7 ms | 1 922,1 ms | 33,7 Mio/s | 1,00x | 121,3 Mio |
| 32 | 2 | 1 881,7 ms | 1 887,5 ms | 34,0 Mio/s | 1,01x | 122,8 Mio |
| 32 | 4 | 1 874,2 ms | 1 891,2 ms | 34,1 Mio/s | 1,01x | 126,6 Mio |
| 32 | 8 | 1 873,2 ms | 1 885,7 ms | 34,2 Mio/s | 1,01x | 133,4 Mio |
| 32 | 16 | 1 856,8 ms | 1 868,5 ms | 34,5 Mio/s | 1,02x | 153,9 Mio |
| 32 | 32 | 1 877,3 ms | 1 880,4 ms | 34,1 Mio/s | 1,01x | 179,5 Mio |
| Corpus | Fichiers | Octets exacts | Mur médian | Mur p95 | Débit | RSS de pointe médian |
|---|---|---|---|---|---|---|
| petit | 256 | 8 Mio | 869,9 ms | 886,1 ms | 9,2 Mio/s | 111,1 Mio |
| moyen | 1 024 | 64 Mio | 1 859,9 ms | 1 874,8 ms | 34,4 Mio/s | 126,3 Mio |
| grand | 2 048 | 256 Mio | 5 214,9 ms | 5 321,7 ms | 49,1 Mio/s | 137,1 Mio |
| Classe de stockage | Système de fichiers | ID de périphérique | Mur médian | Mur p95 | Débit | Relatif au premier stockage | RSS de pointe médian |
|---|---|---:|---:|---:|---:|---:|---:|---:|
| workspace | ext4 | 66305 | 1 847,4 ms | 1 863,4 ms | 34,6 Mio/s | 1,00x | 127,0 Mio |
| local-temp | tmpfs | 116 | 1 870,8 ms | 1 887,3 ms | 34,2 Mio/s | 0,99x | 124,9 Mio |
| Processus | Workers par processus | Workers agrégés | Fichiers totaux | Octets totaux | Mur médian | Débit agrégé | Accélération | RSS de pointe sommé médian |
|---|---|---|---|---|---|---|---|---|
| 1 | 32 | 32 | 256 | 8 Mio | 871,9 ms | 9,2 Mio/s | 1,00x | 111,5 Mio |
| 2 | 16 | 32 | 512 | 16 Mio | 404,6 ms | 39,5 Mio/s | 4,31x | 134,0 Mio |
| 4 | 8 | 32 | 1 024 | 32 Mio | 571,1 ms | 56,0 Mio/s | 6,11x | 227,2 Mio |
Ces lignes sont des mesures, pas des constantes de réglage universelles. Exécutez le générateur sur l'hôte et le stockage cibles. Utilisez le coude où le débit cesse de s'améliorer, puis réservez CPU et mémoire pour l'exécuteur CI ou la couche d'orchestration.
Reproduisez les quatre groupes de benchmarks avec make -C benchmarks readme-matrix.
La commande mesure la matrice requise et échoue si une ligne demandée de CPU,
Hyperscan, CUDA, Metal, WGPU, préréglage, cache, démon, thread, lecteur, stockage,
taille de corpus ou partition est indisponible. Utilisez
make -C benchmarks readme-matrix-check pour vérifier que les deux instantanés, les
rapports et le README concordent.
Commencez avec la politique par défaut et le routage automatique calibré. Modifiez un seul axe uniquement lorsque le flux de travail l'exige :
| Flux de travail | Politique de détection | Exécution et réutilisation | Contrôle supplémentaire |
|---|---|---|---|
| Premier scan de dépôt | Par défaut | auto calibré ; --daemon=auto | Examinez tous les résultats avant d'ajouter des suppressions. |
| Scan répété d'arbre local ou CI | Par défaut | auto calibré ; --incremental | Persistez le cache incrémental uniquement entre les scans du même arbre de confiance. |
| Boucle de rétroaction courte | --fast | auto calibré ; --incremental facultatif | Acceptez une couverture réduite de décodage, d'entropie et de ML. Exécutez la politique par défaut avant la fusion. |
| Récupération à rappel le plus élevé | --deep | En processus | Deep est mutuellement exclusif avec fast et precision, et n'est pas éligible au démon. |
| Inventaire volumineux à bruit réduit | --precision | En processus pour les collections de dépôts, l'historique et les sources cloud | Le préréglage relève les seuils de confiance et désactive la découverte d'entropie. Il peut manquer des identifiants de moindre confiance. |
| Inventaire de répertoire, historique, archive, distant ou cloud à l'échelle To sur Unix | Par défaut | keyhog daemon start --mass, puis --daemon=mass | Les lots restent bornés à 8 Mio et 1 024 chunks. Conservez le rapport de couverture du terminal et le reçu d'exécution GPU. |
| Validation d'identifiants en direct | Par défaut | En processus | Ajoutez --verify explicitement. La vérification envoie des requêtes dérivées des identifiants aux fournisseurs. |
| Scan Linux sans swap | Par défaut plus --lockdown | En processus ; cache incrémental désactivé | Lockdown refuse la vérification, les secrets en clair, le mode rapide et les commutateurs réduisant la complétude. |
--fast, --deep et --precision sont des préréglages de détection mutuellement exclusifs.
--lockdown est un mode d'exécution à échec fermé, pas un quatrième préréglage. Les valeurs
explicites de --backend sont des diagnostics et des remplacements de benchmark. Elles ne
remplacent pas la preuve persistée du plus rapide-correct utilisée par le routage automatique.
Voir Configuration,
calibrage autoroute,
démon et scans à chaud,
et durcissement pour les
contrats complets.
KeyHog compile ses 934 détecteurs en un plan partagé de déclenchement et d'extraction,
décode les encodages imbriqués avant la correspondance, et applique une notation, des
preuves et des suppressions par détecteur. Le CPU Pure-Rust (cpu-fallback) est toujours
disponible. La route Hyperscan (simd-regex) utilise Hyperscan lorsque cette fonctionnalité
est présente ; les builds portables utilisent la route CPU. CUDA (gpu-cuda-region-presence), Metal
(gpu-metal-region-presence) et WGPU (gpu-wgpu-region-presence) sont des pairs
dans un sélecteur autoroute adossé à des preuves, pas une chaîne de repli. Le calibrage mesure
chaque pair éligible et persiste la route la plus rapide dont les résultats complets correspondent
à la route de référence pour le binaire exact, l'état du détecteur et de la configuration,
l'hôte, l'accélérateur et la classe de charge de travail. Une décision manquante, obsolète,
invalide ou incomplète arrête un scan automatique avant l'exécution et signale comment
recalibrer. Il ne substitue jamais silencieusement un autre backend.
Voir Architecture pour la carte du dépôt, la direction des dépendances, le pipeline octets-vers-résultat et les points d'entrée de profilage. Voir Backends et routage pour les contrats d'exécution et Calibrage autoroute pour la parité, l'identité de charge de travail, le cycle de vie du cache et les procédures de réparation.
Documentation complète : santhreal.github.io/keyhog - installation, premier scan, formats de sortie, internes de détection, suppressions, vérification, intégration pre-commit + CI, référence CLI, autoroute, codes de sortie, variables d'environnement et contribution. Source sous docs/.
Installez la version actuelle de crates.io :```sh cargo install keyhog --locked
Construisez la copie du dépôt lorsque vous avez besoin d’un changement non publié :```sh
cargo install --path crates/cli --locked
Confirmez la build installée :```sh keyhog --version --full keyhog doctor
Utilisez le [guide d'installation](https://santhreal.github.io/keyhog/install.html) pour
les exigences de la chaîne d'outils Rust, les profils de fonctionnalités et les dépendances
d'exécution spécifiques à la plateforme.
## Ce qu'il détecte
934 détecteurs intégrés avec validation hors ligne et compagnons propres aux détecteurs :
- **Fournisseurs cloud :** AWS (clé d'accès + secret + vérification STS),
Azure (clé d'abonnement, clé de compte de stockage, SAS), GCP (compte de service,
clé API), Cloudflare, Heroku, Vercel, Supabase.
- **Processeurs de paiement :** Stripe, Braintree, Razorpay, Paddle, Plaid,
Square et PayPal, avec vérifications propres aux détecteurs et compagnons optionnels ou
obligatoires. Une clé secrète Razorpay nécessite son ID de clé à proximité.
- **Forges de code source :** PAT GitHub (avec somme de contrôle CRC32), jetons GitLab,
mots de passe d'application Bitbucket, jetons npm (avec somme de contrôle), Gitea / Forgejo
/ Codeberg.
- **Auth / SSO :** Okta, Auth0, Clerk, JumpCloud, Kinde.
- **Communications :** Slack, Discord, Twilio, SendGrid, Postmark, Mailgun,
Resend, Loops.
- **IA / ML :** OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio,
Cohere, Mistral, HuggingFace, Replicate. Les identifiants d'organisation
HuggingFace incluent à la fois la forme actuelle `hf_` et les jetons hérités `api_org_`.
- **Gestionnaires de mots de passe :** clés secrètes de compte 1Password (`A3-` suivi de
cinq ou six composants alphanumériques majuscules segmentés).
- **Bases de données :** chaînes de connexion Postgres, MongoDB Atlas, Supabase
service-role, PlanetScale, Neon, Turso, MySQL, URL Redis.
- **Découverte générique + entropie :** `API_KEY=<blob à haute entropie>` détecte
les identifiants sans détecteur nommé, contrôlé par des seuils d'entropie
par contexte + notation ML.
- **Matériel cryptographique :** clés privées RSA / EC / SSH, blocs
privés PGP, secrets de signature JWT.
Chaque détecteur est fourni sous forme de [fichier TOML](https://github.com/santhreal/keyhog/blob/main/detectors) (données, pas de code) :
métadonnées de service, motifs regex, mots-clés, validateurs hors ligne, politique d'entropie et de ML,
champs compagnons et gestionnaire de vérification. Ajouter un nouveau détecteur est une
modification TOML unique et vérifiable ;
le [guide du contributeur](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md) en détaille la procédure.
`keyhog explain <id>` affiche la spécification complète de tout détecteur : motifs,
mots-clés, point de terminaison de vérification, plus un guide de rotation et de remédiation
étape par étape propre au service, afin qu'une détection ne soit jamais une boîte noire :
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat : vidage de spécification du détecteur (motif ghp_[A-Za-z0-9]{36}, mot-clé, URL de vérification) suivi du guide de rotation github et de la remédiation étape par étape" width="860" />
</p>
Parcourez la création et l'inspection des détecteurs dans la
[référence des détecteurs](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md), ou interrogez le corpus installé avec
`keyhog detectors --search <terme> --verbose`.
## Pourquoi un meilleur rappel, moins de faux positifs
- **Analyse par décodage.** Manifests `Secret` Kubernetes, notebooks
Jupyter, charges utiles JWT, environnements encapsulés en base64, valeurs Helm et blobs
`auth:` de docker-config. Le préprocesseur structuré traite les actions Helm équilibrées comme
des valeurs de rendu inertes et ferme les délimiteurs Jupyter manquants en fin de fichier,
afin que les octets littéraux et les cellules de code complètes restent couverts. Il décode les valeurs
structurées sur place et fournit le texte en clair à chaque détecteur en aval. Les détecteurs
n'ont pas chacun besoin de réimplémenter le décodage. Les analyses avec décodage activé récupèrent également
les expressions JavaScript XOR de tableaux d'octets et AES-256-CBC sans effets de bord lorsque
tout le matériel de récupération est intégré, y compris les wrappers stricts de phrase de passe salée CryptoJS/OpenSSL. KeyHog n'exécute jamais la source.
- **Réassemblage multiligne.** Continuation `"sk-proj-" + \` en JavaScript,
chaînes multilignes YAML, continuation par antislash Makefile, sorties
templatées Helm / Jinja, tout est réassemblé avant la correspondance regex.
- **Validation des compagnons.** Les compagnons obligatoires limitent les détecteurs à fort bruit. Une
clé API Twilio sans son secret API est ignorée. Les compagnons optionnels enrichissent
la notation des preuves ou la vérification. La détection de clé d'accès AWS n'exige pas
son secret, mais le secret est nécessaire pour la vérification en direct.
- **Résolution inter-détecteurs.** Le TOML du détecteur peut exiger, rejeter ou englober
des détections limitées d'un autre détecteur. La résolution reste déterministe quel que soit
l'ordre d'entrée, et les cibles invalides, les contradictions ou les cycles de dépendances font échouer
la compilation du corpus.
- **Verdicts de preuve.** Chaque détection porte un niveau exact `review`, `likely` ou
`confirmed` plus un code de raison canonique. La somme de contrôle intrinsèque ou la preuve
grammaticale, les compagnons obligatoires et la vérification en direct produisent des preuves confirmées ;
une forme forte spécifique au fournisseur dans un rôle porteur d'identifiants produit une preuve
probable ; les ancres faibles, les affectations génériques, les candidats à entropie seule et les
contextes de test, de documentation, de règle ou d'identifiant restent des preuves de revue.
Un `evidence_score` optionnel complète le verdict lorsqu'il est mesuré.
Le seuil par défaut `0.40` contrôle le plancher de confiance interne du scanner
et reste configurable avec `--min-confidence`.
- **Calibrage bayésien par détecteur.** `keyhog calibrate --fp generic-api-key`
écrit un a posteriori Beta(α,β). Les analyses ne l'utilisent que lorsque `--calibration-cache`
ou `[system].calibration_cache` pointe vers ce fichier, afin que le réglage de la confiance soit
explicite et reproductible au lieu de dépendre d'un état de cache hôte aléatoire.
## Performances
Utilisez le harnais reproductible dans [`benchmarks/`](https://github.com/santhreal/keyhog/blob/main/benchmarks) pour comparer KeyHog,
Betterleaks, Kingfisher, Nosey Parker, TruffleHog et Titus sous un même contrat
de notation. Le harnais exclut le manifeste de vérité terrain de chaque arbre d'analyse.
Les tableaux générés restent vides jusqu'à ce que des exécutions au schéma actuel existent. Exécutez
`make -C benchmarks report` après la mesure. Ne modifiez pas les tableaux générés à la
main.
### Classement de détection
<!-- BENCH:leaderboard:start -->
#### Corpus miroir synthétique de forme SecretBench
Corpus : **mirror** - 15000 fixtures, 3000 positifs étiquetés, 2 431 242 octets. Chaque scanner noté à l'identique (règle de chevauchement SecretBench) ; le manifeste de la clé de réponse est exclu de l'arbre d'analyse.
| Rang | Scanner | F1 | Précision | Rappel | Détections | Temps | RSS maximal |
|---|---|---|---|---|---|---|---|
| 1 | **KeyHog** | **0.9328** | 0.9651 | 0.9027 | 2816 | 1.05s | 416 Mo |
| 2 | TruffleHog | 0.5294 | 1.0000 | 0.3600 | 1080 | 1.59s | 300 Mo |
| 3 | Kingfisher | 0.4683 | 0.3877 | 0.5913 | 5255 | 4.81s | 402 Mo |
| 4 | Titus | 0.4207 | 0.3381 | 0.5567 | 5151 | 2.86s | 115 Mo |
| 5 | Nosey Parker | 0.4186 | 0.3511 | 0.5183 | 4529 | 0.82s | 285 Mo |
| 6 | Betterleaks | 0.3498 | 0.2241 | 0.7970 | 11113 | 0.74s | 198 Mo |
#### Corpus de règles de terrain adverse / domicile des concurrents
Corpus : **homefield** - 2399 fixtures extraites des suites de règles de vérité terrain des concurrents (règles Betterleaks et Kingfisher ; 1 057 positifs étiquetés, 1 342 négatifs, 772 974 octets). Évaluation croisée des outils sur la vérité terrain des concurrents.
| Rang | Scanner | F1 | Précision | Rappel | Détections | Temps | RSS maximal |
|---|---|---|---|---|---|---|---|
| 1 | **KeyHog** | **0.9214** | 0.9582 | 0.8874 | 979 | 0.72s | 384 Mo |
| 2 | Betterleaks | 0.9056 | 0.9130 | 0.8984 | 1040 | 0.58s | 192 Mo |
| 3 | Kingfisher | 0.8842 | 0.9250 | 0.8468 | 968 | 2.14s | 390 Mo |
| 4 | TruffleHog | 0.4812 | 0.9850 | 0.3226 | 345 | 1.22s | 280 Mo |
| 5 | Titus | 0.4635 | 0.3810 | 0.5913 | 1640 | 2.15s | 110 Mo |
| 6 | Nosey Parker | 0.4520 | 0.3950 | 0.5280 | 1412 | 0.68s | 265 Mo |
### Provenance des résultats
| Scanner | Version du scanner / empreinte de l'exécutable | Identité du corpus | Identité de l'hôte | Date d'exécution |
|---|---|---|---|---|
| KeyHog | version : KeyHog v0.5.70<br>Commit : d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Ensemble de détecteurs : 926 (926-4168e2c6c93a16ca)<br>Cible de compilation : x86_64-linux<br>Version du modèle ML : moe-v1-246a05b92bec9aa3<br>Carte du modèle ML : enregistrée 2026-07-15 ; caractéristiques 55 ; F1 synthétique 0.971 / P 0.945 / R 0.999 ; F1 réel 0.832 / P 0.753 / R 0.931 / [email protected] 0.938 ; détecteurs à rappel nul 2/32 ; différentiel à six scanners indisponible<br>SHA-256 de l'exécutable : `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `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>SHA-256 de l'exécutable : `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `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>SHA-256 de l'exécutable : `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `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 (portage Go de NoseyParker)<br>SHA-256 de l'exécutable : `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `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 Configuration de compilation : Horodatage de compilation : 2025-05-08T21:11:15.600909923Z Horodatage du commit : 2025-05-08T17:04:47.000000000-04:00 Branche du commit : HEAD SHA du commit : 61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Fonctionnalités Cargo : color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release Debug : true Optimisation : 3 Triple cible : x86_64-unknown-linux-gnu Système de compilation : OS : Ubuntu Version de l'OS : Linux (Ubuntu 22.04) Fournisseur CPU : AuthenticAMD Marque CPU : AMD EPYC 7763 64-Core Processor Cœurs CPU : 2 Version rustc : 1.86.0 Canal rustc : stable Triple hôte rustc : x86_64-unknown-linux-gnu Date du commit rustc : 2025-03-31 SHA du commit rustc : 05f9846f893b09a1be1fc8560e33fc3c815cfecb Version LLVM rustc : 19.1<br>SHA-256 de l'exécutable : `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `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>SHA-256 de l'exécutable : `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror ; 15 000 fixtures ; 3 000 positifs étiquetés ; 2 431 242 octets | SHA-256/12 du nom d'hôte : `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16-Core Processor | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->
### Vitesse et mémoire
<!-- BENCH:perf:start -->
#### Corpus miroir synthétique de forme SecretBench
| Scanner | Configuration | Corpus | Temps | Débit | RSS maximal |
|---|---|---|---|---|---|
| Betterleaks | `default-nocache-nodaemon-no-validate` | mirror | 0.74s | 3.1 Mo/s | 198 Mo |
| Nosey Parker | `default-nocache-nodaemon-no-git-history` | mirror | 0.82s | 2.8 Mo/s | 285 Mo |
| KeyHog | `simd-nocache-nodaemon-full` | mirror | 1.05s | 2.2 Mo/s | 416 Mo |
| TruffleHog | `default-nocache-nodaemon-no-verify` | mirror | 1.59s | 1.5 Mo/s | 300 Mo |
| Titus | `default-nocache-nodaemon-no-validate` | mirror | 2.86s | 0.8 Mo/s | 115 Mo |
| Kingfisher | `default-nocache-nodaemon-low-no-validate` | mirror | 4.81s | 0.5 Mo/s | 402 Mo |
#### Corpus de règles de terrain adverse / domicile des concurrents
| Scanner | Configuration | Corpus | Temps | Débit | RSS maximal |
|---|---|---|---|---|---|
| Betterleaks | `default-nocache-nodaemon-no-validate` | homefield | 0.58s | 1.3 Mo/s | 192 Mo |
| Nosey Parker | `default-nocache-nodaemon-no-git-history` | homefield | 0.68s | 1.1 Mo/s | 265 Mo |
| KeyHog | `simd-nocache-nodaemon-full` | homefield | 0.72s | 1.1 Mo/s | 384 Mo |
| TruffleHog | `default-nocache-nodaemon-no-verify` | homefield | 1.22s | 0.6 Mo/s | 280 Mo |
| Titus | `default-nocache-nodaemon-no-validate` | homefield | 2.15s | 0.4 Mo/s | 110 Mo |
| Kingfisher | `default-nocache-nodaemon-low-no-validate` | homefield | 2.14s | 0.4 Mo/s | 390 Mo |
<!-- BENCH:perf:end -->
### Comparaison du rappel par catégorie
<!-- BENCH:gaps:start -->
_Slice de rappel diagnostique uniquement. La précision globale et le F1 restent le contrat de comparaison ; les faux positifs sont comptés dans leurs catégories notées._
| Catégorie | P/R/F1 KeyHog | TP/FN KeyHog | P/R/F1 meilleur concurrent | Écart de rappel |
|---|---|---|---|---|
| `generic-high-entropy-string` | 1.000 / 0.434 / 0.606 | 73/95 | Betterleaks 1.000 / 0.798 / 0.887 | +0.363 |
<!-- BENCH:gaps:end -->
### Télémétrie de récupération statique bornée
<!-- BENCH:recovery:start -->
Exécution sélectionnée : scanner **KeyHog** `KeyHog v0.5.70<br>Commit : d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Ensemble de détecteurs : 926 (926-4168e2c6c93a16ca)<br>Cible de compilation : x86_64-linux<br>Version du modèle ML : moe-v1-246a05b92bec9aa3<br>Carte du modèle ML : enregistrée 2026-07-15 ; caractéristiques 55 ; F1 synthétique 0.971 / P 0.945 / R 0.999 ; F1 réel 0.832 / P 0.753 / R 0.931 / [email protected] 0.938 ; détecteurs à rappel nul 2/32 ; différentiel à six scanners indisponible` ; corpus **mirror** (15 000 fixtures, 2 431 242 octets) ; généré `2026-08-11T01:29:39Z` ; artefact `mirror-keyhog-simd-nocache-nodaemon-full.json`.
Schéma de télémétrie : `static-recovery-v1`.
| Disposition | Nombre exact |
|---|---:|
| Pris en charge | 0 |
| Non pris en charge | 0 |
| Erroné | 0 |
| Raison de rejet | Nombre exact |
|---|---:|
| _aucune_ | 0 |
<!-- BENCH:recovery:end -->
### Preuve Bloom bigramme
<!-- BENCH:bloom:start -->
Schéma de preuve : `bloom-evidence-v1`.
| Champ | Résultat exact |
|---|---|
| Corpus | `samsung-creddata-fx-record-spans-v1` |
| Révision du corpus | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| SHA-256 du corpus | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| SHA-256 de la fixture | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| SHA-256 de l'exécutable | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| SHA-256 du corpus de détecteurs de l'espace de travail | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| Empreinte du détecteur du scanner | `8d789251e092959f` |
| SHA-256 du corpus de détecteurs | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Rejet Bloom | **110/51794 (0,21 %)** ; 51684 admis |
| Disponibilité externe | 51794 mesurés ; 0 explicitement indisponibles sur 51794 déclarés ; raisons : |
| Détections activées vs contournées | **IDENTIQUES** ; 977/977 détections |
| SHA-256 d'identité de détection | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Densité/état Bloom | 1793/65536 emplacements ; `healthy` ; saturation à 39322 |
L'identité de détection lie le détecteur, le fichier, la ligne, l'étendue d'octets et le SHA-256 de l'identifiant ; les identifiants en clair ne sont jamais enregistrés.
<!-- BENCH:bloom:end -->
Reproduction : `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
relance l'ensemble exact d'exécutions miroir KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog et
Titus, y compris le différentiel Bloom CredData lié à l'exécutable,
`make -C benchmarks report` régénère les tableaux ci-dessus et
`benchmarks/reports/`. Consultez [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
pour les corpus (mirror, terrain adverse des concurrents, Samsung/CredData) et la
matrice backend/cache/daemon/OS/GPU.
## Workers démons de masse adossés au GPU
Le démon de masse Unix optionnel maintient un scanner compilé et son
état backend calibré à chaud. Les analyses du système de fichiers local n'envoient que la racine canonique et les
métadonnées de politique de source ; le démon lit et traite par lots les fichiers dans son propre
processus. Les sources Git, binaires, distantes et cloud qui nécessitent des
identifiants côté client utilisent des trames de blocs bornées protégées.```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 est une route obligatoire. Elle ne réessaie jamais en cours de processus. Chaque lot est
limité à 8 Mio et 1 024 blocs, indépendamment de la taille totale de l'entrée. Préservez
l'enveloppe de couverture, le statut de sortie et le reçu d'exécution du terminal pour chaque
partition d'inventaire.
sudo keyhog scan-system --space 50G sudo keyhog scan-system --include-network --output system-findings.json
`scan-system` est un audit local hôte borné, pas un remplacement pour le partitionnement d'inventaire de dépôt ou
cloud. Il se borne par le nombre total d'octets analysés plutôt que
par chemin : `--space` est le plafond, et les systèmes de fichiers montés en réseau sont
ignorés sauf si vous passez `--include-network`. Examinez le comportement des montages, des systèmes de fichiers réseau,
du plafond d'espace et des privilèges avant de l'exécuter. Voir
[triage à l'échelle du système](https://santhreal.github.io/keyhog/guides/system-wide-triage.html).
## Verrouiller les analyses locales sensibles
Le mode `--lockdown` de Linux est un mode de protection des processus en échec-fermé :```sh
keyhog scan . --daemon=off --lockdown
Il verrouille la mémoire actuelle et future, désactive les core dumps et le cache incrémental, reste dans le processus, et refuse la vérification, la sortie en texte clair, le mode rapide et les options réduisant l'exhaustivité. Il échoue sur les plateformes non prises en charge ou en cas de capacité de mémoire verrouillée insuffisante. Voir renforcement et gestion des données.
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();
Les méthodes de bibliothèque par défaut sont des références CPU portables déterministes. Les
méthodes backend explicites renvoient des erreurs typées au lieu de terminer le processus ou de
substituer silencieusement un autre moteur. Les blocs bruts et les correspondances peuvent contenir
du texte en clair. Convertissez-les avec `RawMatch::to_redacted`, ou utilisez les valeurs finales
`VerifiedFinding`, avant les frontières JSON, journaux, disque ou réseau.
Le [guide d'architecture](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) définit la propriété des crates,
les contrats backend, les reçus de récupération, les assistants de source et les frontières
de signalement sûres. La documentation Rust au niveau des crates possède l'API complète.
## Configurer la politique avec une précédence explicite
La politique du dépôt se trouve dans `.keyhog.toml` :```toml
verify = false
[scan]
severity = "high"
incremental = true
[system]
gpu = "auto"
L’ordre de résolution est : valeurs par défaut intégrées, configuration utilisateur, configuration du dépôt, environnement lorsqu’il est documenté, puis remplacements explicites via CLI. Les clés inconnues et les combinaisons invalides échouent avant l’analyse. Exécutez keyhog config --effective pour inspecter la politique résolue sans exposer les identifiants du proxy.
Les entrées au-delà de expires font échouer le chargement de la liste autorisée avant l’analyse.
Voir configuration et précédence pour chaque clé et variables d’environnement pour les identifiants et les entrées d’exécution.
KeyHog conserve l’orchestration à la périphérie et le comportement du domaine dans les bibliothèques :```text sources -> scanner -> suppression/evidence -> reporting -> optional verifier CLI and Action own process, transport, and exit semantics.
Les définitions de détecteurs restent des données sous `detectors/`. `keyhog-core` possède
les types de détecteurs et de résultats, `keyhog-scanner` possède les backends de correspondance et d'exécution,
`keyhog-sources` possède l'acquisition des entrées, `keyhog-verifier` possède les
vérifications en direct, et `keyhog-cli` possède les flux de travail de l'opérateur.
Commencez par le [guide d'architecture](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md) pour la carte
du dépôt, la direction des dépendances, le pipeline octets-vers-résultat, la propriété du routage, et
les points d'entrée de profilage.
## Inspecter et étendre l'installation```sh
keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh
La référence CLI
liste chaque commande, drapeau, valeur par défaut générée et code de sortie. Utilisez
keyhog --help et keyhog <commande> --help pour la version exacte installée.
detectors/, ouvrez une
PR. Le guide du contributeur (CONTRIBUTING.md)
contient le schéma et un exemple complet.crates/scanner/tests/contracts/.main incrémente la version
de correctif, génère les journaux de modifications et publie les six crates sur crates.io.
Ajoutez un fragment facultatif sous changes/ pour une note précise.
Le guide de publication couvre
la transaction automatique et la récupération en cas d'échec de téléversement.[email protected] ; PGP n'est pas requis.KeyHog s'appuie sur des travaux antérieurs de détection de secrets. Des idées empruntées à :
Merci à ces projets et à leurs contributeurs.
Licence : MIT OU Apache-2.0.
Conditions : MIT et Apache-2.0. Cette double licence couvre le code et les TOML des détecteurs. L'utilisation commerciale, l'intégration, les forks et les services hébergés sont autorisés sous l'une ou l'autre licence.
Généré à partir des observations UTC du nombre public d'étoiles GitHub. Le dépôt stocke le premier point et chaque transition de comptage ultérieure. Les exécutions du même jour remplacent le point de ce jour, et des comptages inchangés ne créent aucun commit.