
keyhog v0.5.47
Rust製のオープンソースシークレットスキャナー
Webサイト · ドキュメント · アーキテクチャ · Vyre GPUエンジン
KeyHog: コード、クラウド、CI向けGPUアクセラレーション秘密情報スキャナ
KeyHogはRust製のオープンソース秘密情報スキャナで、ソースコード、Git履歴、コンテナ、クラウドストレージ、ブラウザ資産、コラボレーションコンテンツ、実行中のシステム全体にわたって、漏洩したAPIキー、トークン、パスワード、認証情報を検出・検証します。
ほとんどの秘密情報スキャナは、リポジトリチェックアウト内のCPU正規表現マッチで止まってしまいます。KeyHogは、934種類のサービス固有検出器、隠蔽された認証情報のデコード透過処理、コンテキストを考慮した証拠と抑制、ライブプロバイダー検証、そしてVyreによる第一級のCUDA、Metal、WGPU実行を組み合わせています。キャリブレーションは、対象となるすべての純Rust CPU、Hyperscan/SIMD、GPUバックエンドを測定します。その後、自動ルーティングにより、正確なホストとワークロードクラスに対して、同等性が証明された最速の経路を使用します。
| GPUは本物のバックエンド | 実際の攻撃対象領域をスキャン | ノイズからシグナルを分離 | 結果に基づいて行動 |
|---|---|---|---|
| CUDA、ネイティブMetal、WGPUは、黙ったフォールバックチェーンではなく、測定された同等のピアです。 | Git履歴、Dockerレイヤー、アーカイブ、クラウドバケット、ソースマップ、WASM、HARキャプチャ、ホスト型Gitコレクション、システム全体をスキャンします。 | 証拠、サンプル抑制、ベースラインを適用する前に、base64、hex、URL、protobuf、複数行、構造化設定をデコードします。 | プロバイダーAPIで対象の認証情報を検証し、SARIFまたは構造化エンベロープを出力し、正確なカバレッジと終了セマンティクスを維持します。 |
| cargo install --locked keyhog | |||
| keyhog scan . |
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="KeyHog スキャン。重大度、証拠、ファイルと行、修正方法、結果、カバレッジ状況を表示" width="900" />
</p>
## GPU を中心に構築されたシークレットスキャナ
KeyHog は、いくつかの正規表現を汎用コンピュートシェーダーに渡すだけではありません。
その GPU パスは、KeyHog と並行して開発された Rust GPU
コンピュート基盤である [Vyre](https://github.com/santhreal/vyre) 上に構築されています。
検出器トリガーは、イミュータブルな GPU 常駐テーブルにコンパイルされます。
境界付きソースバッチは、CPU および Hyperscan ルートで使用されるものと同じ
確認、抑制、証拠、レポートパイプラインに対して、完全なマッチ位置を生成します。
- **3 つの物理 GPU ピア。** CUDA、ネイティブ Metal、ポータブル WGPU は、
それぞれ独立して取得、測定、報告されます。
- **完全な結果の同等性。** キャリブレーションは、参照ルートと検出 ID が異なる候補を拒否します。
高速だが誤った回答がルーティングテーブルに入ることはありません。
- **永続的なルート証拠。** KeyHog は、バイナリ、検出器コーパス、
設定、ワークロードクラス、ホスト、アクセラレータ、ドライバ、測定されたタイミング
証拠を記録します。通常のスキャンはホットパスでベンチマークを実行しません。
- **常駐実行。** デーモンワーカーは、コンパイル済みの検出器とアクセラレータの
状態をウォームに保ち、ファイル、アーカイブ、履歴、リモート、クラウドの各バッチを繰り返し処理します。
- **隠れた CPU エスケープハッチなし。** 明示的に選択されたアクセラレータが
初期化またはディスパッチできない場合、GPU ラベルの下で CPU の検出結果を返す代わりに、
可視的に失敗します。
デフォルトの crates.io インストールは、ポータブルな純 Rust CPU ルートを使用するため、
クリーンな Rust ホストで動作します。Hyperscan を取得せずに 3 つの GPU ピアを有効にできます。```sh
cargo install --locked keyhog --no-default-features --features portable,gpu
HyperscanまたはVectorscanのSIMD正規表現ピアを有効にします:```sh cargo install --locked keyhog --no-default-features --features portable,simd
本番バックエンドの診断を実行し、測定されたルートを検査します。```sh
keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
バックエンドガイドには、 常駐テーブル、境界付きディスパッチモデル、パリティ契約、再現可能な クロスオーバー証拠が記載されています。
はじめに
インストールして最初のスキャンを実行する
上記の2つのコマンドは、最新のcrates.ioリリースをインストールし、ポータブルな純Rustルートで現在のツリーをスキャンします。
CI環境を正確に1つのリリースに固定するには、
cargo install --locked --version '=0.5.86' keyhog を使用します。KeyHogにはRust 1.89
以降が必要です。GPU、Hyperscan、CI、ポータブル、ソースビルドのプロファイルについては、
インストールガイドを参照してください。
KeyHogは、検出結果がアクティブなエビデンスポリシーをブロックすると、終了コード 1 を返します。デフォルトのポリシーは likely と confirmed の検出結果をブロックし、review の検出結果は終了コード 0 で表示したままにします。--evidence-policy paranoid はすべての階層をブロックします。各検出結果の正確なエビデンス階層、理由コード、ファイル、行、検出器、および
修復方法を確認してください。その他の非ゼロコードは、入力、システム、検証、または
カバレッジの失敗を示します。終了コードリファレンスを参照してください。
完全なプロセス契約は次のとおりです。
| 終了コード | 意味 |
|---|---|
0 成功 | アクティブなエビデンスポリシーをブロックする検出結果がなく、カバレッジの失敗も発生しませんでした。レビュー階層の検出結果は、デフォルトポリシーの下で表示されたままになる場合があります。 |
1 ブロックする検出結果 | アクティブなエビデンスポリシーをブロックする検出結果が少なくとも1つありますが、ライブ確認されたものはありません。 |
2 オペレーターエラー | 引数、設定、検出器コーパス、またはオペレーターが修正可能な入力を修正してください。 |
3 システムエラー | ランナーを修復するか、再試行してください。これには、低レベルのI/O、致命的なデーモンサービス、インクリメンタルキャッシュ、明示的に選択されたSIMDの失敗が含まれます。 |
4 ヘルス/セルフテストの失敗 | doctor または backend --self-test のヘルスチェックが異常でした。 |
10 ライブ認証情報 | 少なくとも1つの認証情報がライブ確認されました。 |
11 スキャナーパニック | スキャナーの状態が信頼できないため、スキャン結果を破棄してください。 |
12 必須GPUの失敗 | 明示的に選択または必須のGPUパスを実行できませんでした。 |
13 不完全なカバレッジ | 要求されたソースが失敗したか、入力カバレッジが不完全であり、検出結果が優先されませんでした。 |
130 中断 | SIGINTまたはCtrl-Cによってプロセスが中断されました。 |
フィルター、フォーマット、ゲート:
フィルターとして使用する前に、ベースラインを作成してください。```sh keyhog scan . --create-baseline .keyhog-baseline.json keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json
最初のコマンドは、レビュー済みの検出結果をスナップショットとして保存し、それらを出力せずに終了コード `0` で終了します。そのファイルをコミットした後、2番目のコマンドを使用して、新しい検出結果のIDのみを報告します。ベースラインのエントリは、検出器と認証情報の値で一致し、ファイルパスでは一致しないため、記録済みのシークレットを移動してもゲートは失敗しませんが、ローテーションすると失敗します。変更された認証情報と不完全なカバレッジは引き続き表示されます。モノレポのパーティションを含む完全なパスは、[新しいシークレットのみで失敗](https://santhreal.github.io/keyhog/workflows/ci.html#fail-only-on-new-secrets) にあります。
次のスキャンでは、[レシピクックブック](https://santhreal.github.io/keyhog/recipes.html) または [適切なワークフローの選択](#choose-the-right-workflow) にあるコピー可能なコマンドを使用してください。ツールを変更せずに、Git履歴、コンテナイメージ、クラウドバケット、リポジトリコレクション、URL、およびマシン全体をスキャンできます。
### 高速なpre-commitスキャンのためのリポジトリのガード
常駐型のKeyHogデーモンにリポジトリを登録して、高速なpre-commitシークレット検出を実現します(Unixが必要です。Windowsではプロセス内の `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
perpetual guard guide およびpre-commit workflowを参照して、完全な設定、状態機械のライフサイクル、およびフックの自動化について確認してください。
GitHub Actionsに追加する
.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
このActionはチェックアウトされたツリーをスキャンし、`high`または`critical`の検出結果で失敗し、SARIFをCode Scanningにアップロードし、レポートをワークフローアーティファクトとして保持します。インストール、カバレッジ、バックエンド、レポート公開の失敗もジョブを失敗させます。
入力、出力、ベースライン採用、モノレポ分割、検証、失敗動作については、[GitHub Actionガイド](https://santhreal.github.io/keyhog/workflows/github-action.html)を参照してください。GitLab、CircleCI、Jenkins、Buildkite、汎用シェルジョブについては、[CIガイド](https://santhreal.github.io/keyhog/workflows/ci.html)を参照してください。リポジトリ組織、ホスト型Gitグループ、クラウドバケット、分割インベントリについては、[大量スキャンガイド](https://santhreal.github.io/keyhog/guides/mass-scanning.html)を参照してください。
## 他のツールが別製品として扱うスキャン対象
KeyHogは、追跡されたソースファイルだけでなく、情報が漏洩し得る境界のバイトをスキャンします。CIが正確なカバレッジと失敗状態を保持するように、境界ごとに1つのレポートを使用してください。
| 露出面 | 例 |
|---|---|
| 最終パッケージアーティファクト | `npm pack`を実行し、生成された`.tgz`を`keyhog scan package.tgz`でスキャンします。アーカイブ展開により、期待されるソースツリーに存在しない生成ファイル、ソースマップ、フィクスチャ、メタデータがチェックされます。 |
| デプロイされたブラウザアプリケーション | `keyhog scan --url https://app.example.com/assets/app.js`は、スキャナーを無制限のクローラーに変えることなく、境界付きのJavaScript、ソースマップ、WASM、レスポンスデコードを追跡します。 |
| GitHub issues、プルリクエスト、ディスカッション、wiki、gists | `keyhog scan --github-collaboration owner/repo --github-all`は、チェックアウト外のすべてのコラボレーション面をスキャンします。 |
| AIエージェントおよびMCP設定 | `keyhog scan ~/.config ~/.claude ~/.codex`は、同じ検出器、デコード、証拠、レポートパイプラインをローカルツール設定に適用します。 |
| コンテナイメージレイヤ | `keyhog scan --docker-image registry.example.com/team/app:v1`は、ビルド中に導入されたファイルを含む、実行されるイメージコンテンツをスキャンします。 |
| クラウドオブジェクトインベントリ | `keyhog scan --s3-bucket BUCKET`、`--gcs-bucket BUCKET`、または`--azure-container-url URL`は、プロバイダーのページネーション、オブジェクト、バイト制限のカバレッジをターミナルレポートに保持します。 |
| 開発ホスト全体 | `sudo keyhog scan-system --space 50G`は、ハードなストレージ予算の下で、マウントされたファイルシステムと到達可能なGit履歴を発見します。 |
これらの経路は、1つの検出およびレポート契約を共有します。ソース固有の失敗が、より狭いローカルスキャンに静かに変わることはありません。
## 適切なワークフローの選択
まずソース境界を選択してください。プリセットは検出作業を変更し、バックエンドは実行を変更します。どちらも作業ツリースキャンをGit履歴、プロバイダーインベントリ、クラウドストレージ、ホスト監査に拡張しません。
正直な`scan everything`ショートカットはありません。完全な資産レビューは、以下の関連境界を個別のジョブとして実行し、各`json-envelope`レポートを生の終了コードとともに保持します。
| ニーズ | 開始方法 | スループットと再利用 | カバレッジ境界 |
|---|---|---|---|
| 迅速なローカルフィードバック | `keyhog scan . --fast --incremental` | 変更されていないファイルのハッシュを再利用します。fastプリセットはデコード、エントロピー、ML作業をスキップします。 | fastは意図的に狭いため、マージ前にデフォルトポリシーを実行してください。 |
| 完全なリポジトリスキャン | `keyhog scan .` | 調整済みの`auto`とCPUコアワーカーがデフォルトです。同じ信頼されたツリーの繰り返しスキャンには`--incremental`を追加します。 | 現在のファイルのみ。Git履歴は追加されません。 |
| ステージングされたコミットゲート | `keyhog scan --git-staged`または`keyhog hook install` | 正確なインデックスblobを読み取るため、ステージングされていない編集は結果を変更できません。 | ステージングされたコンテンツのみ。ローカルのステージングされていないバイトが重要な場合は、作業ツリースキャンを別途実行してください。 |
| 永続的なリポジトリガード | `keyhog guard add . --mode repo`、次に`keyhog guard status .` | 7状態マシン、クリーンなアテステーションキャッシュ、ポリシーID追跡を備えたデーモン常駐ルートレジストリ。 | 実行中のデーモンが必要です。ガードはステージングおよび作業ツリースキャンを補完し、置き換えるものではありません。 |
| GitHubプルリクエストゲート | `santhreal/keyhog@v0` | Actionはインストール、スキャン、SARIFとアーティファクトの公開を行い、KeyHogのステータスを保持します。 | 1つのチェックアウトパス。組織にはプロバイダーインベントリスキャンを使用してください。 |
| GitLab、Jenkins、Buildkite、またはシェルCI | `keyhog scan . --format json-envelope --output keyhog.json` | 成功、検出結果、エラー時にレポートと終了コードを保持します。明示的に狭い変更行ゲートの場合のみ`--git-diff <base>`を使用してください。 | チェックアウトに存在するバイト、または選択されたdiff。 |
| 既知の検出結果を持つリポジトリの採用 | `.keyhog-baseline.json`を作成してコミットし、`--baseline .keyhog-baseline.json`でスキャンします。 | 既存のIDはベースラインに表示されたまま、新しい検出結果のみがゲートを失敗させます。 | ベースラインは、変更された認証情報や不完全なカバレッジを抑制しません。 |
| 再帰的Gitリカバリ | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | deepポリシーをワーカークラスごとに一度調整します。プロセス内で実行します。 | 1つのリポジトリ。`--git-history`は現在のチェックアウトの祖先のみをカバーするため、チェックアウトしたことのないブランチはカバレッジギャップなしで見逃されます。`--git-blobs`は、ダングリングblob、修正で消えたコミット、スタッシュ、ノート、注釈付きタグメッセージ、パック参照にも到達します。 |
| コンテナまたはアーカイブ検査 | `keyhog scan --docker-image registry/app:v1`または`keyhog scan incoming/` | スキップ、破損、暗号化、安全でない、またはサイズ超過のメンバーが表示されたままになるように、エンベロープレポートを保持します。 | 選択されたイメージまたはファイルシステムパスと、サポートされるネスト形式のみ。 |
| URL、レスポンス、またはHAR検査 | `keyhog scan --url https://api.example.com/config`または`keyhog scan capture.har` | 境界付きソース制限を使用し、ターミナルエンベロープを保持します。 | フェッチされたレスポンスまたはキャプチャエントリのみ。これはクローラーではありません。 |
| 組織またはクラウドインベントリ | `keyhog scan --daemon=off --github-org acme --format json-envelope --output acme.json` | プロバイダー、所有者、またはバケットごとに分割します。独立したパーティションを並行して実行し、それぞれに1つのレポートとステータスを持たせます。 | ジョブごとに1つの選択されたプロバイダーインベントリ。ページネーションまたはオブジェクト制限はカバレッジ境界のままです。 |
| 対象の検出結果が有効かどうかの確認 | `keyhog scan . --verify` | プロバイダーの並行性とレート制御はスキャナーワーカーとは別です。 | 宣言されたプロバイダーエンドポイントに認証情報由来のリクエストを送信します。すべての検出器が検証をサポートしているわけではありません。 |
| ホスト全体のヘルススキャン | `sudo keyhog scan-system --space 50G` | デフォルトですべてのCPUコアを使用し、ファイルシステムデータの後に発見されたGit履歴をスキャンします。 | ローカルのマウントされたファイルシステム。ネットワークマウントはオプトインで、スペース上限はハードです。 |
| Unix上のGPU対応ディレクトリ、履歴、アーカイブ、リモート、またはクラウドインベントリ | autorouteを調整し、`keyhog daemon start --mass`を開始してから、`keyhog scan --daemon=mass <SOURCE>`を実行します。 | 境界付きバッチを1つのコンパイル済みCPU、Hyperscan、CUDA、Metal、またはWGPUワーカーにストリーミングします。ウォームな変更されていないファイルシステムツリーには`--incremental`を追加します。ターミナルレシートは、正確な合計とGPUバッチ、チャンク、バイト、GPUシェア、スループットを報告します。 | ベースライン、検証、ロックダウン、プリセット、オーバーレイ、その他のスキャナーポリシー変更は、取得前に拒否されます。インクリメンタル状態はデーモンローカルのファイルシステムルートにのみ適用されます。 |
### サポートされるすべてのソース境界をスキャン
境界ごとに1つのコマンドを使用してください。各インベントリパーティションについて、`json-envelope`レポートと生の終了ステータスを保持してください。
| ソースまたはユースケース | コマンド |
|---|---|
| 複数のローカルルート | `keyhog scan services/api services/web deploy/` |
| 継続的に変更されるファイル | `keyhog watch services/api deploy/` |
| ステージングされたバイト、変更行、到達可能な履歴、またはblob | `keyhog scan --git-staged`、`--git-diff main`、`--git-history .`、または`--git-blobs .` |
| ネイティブバイナリとファームウェア文字列 | `keyhog scan --binary firmware.bin`(通常のディレクトリスキャンはバイナリをスキップし、依然として`0`で終了します) |
| アーカイブと圧縮ソース | `keyhog scan incoming/`(サポートされるメンバーは自動的に展開されます) |
| Dockerイメージレイヤ | `keyhog scan --docker-image registry/app:v1` |
| JavaScript、ソースマップ、WASM、またはエンドポイントレスポンス | `keyhog scan --url https://api.example.com/config` |
| HTTPリクエストとレスポンスのキャプチャ | `keyhog scan capture.har` |
| GitHub issues、プルリクエスト、ディスカッション、wiki、gists | `keyhog scan --github-collaboration owner/repo --github-all` |
| GitHub、GitLab、またはBitbucketインベントリ | `--github-org ORG`、`--gitlab-group GROUP`、または`--bitbucket-workspace WORKSPACE` |
| S3、GCS、またはAzure Blobインベントリ | `--s3-bucket BUCKET`、`--gcs-bucket BUCKET`、または`--azure-container-url URL` |
| 別のツールからの境界付きストリーム | `producer \| keyhog scan --stdin`(`set -o pipefail`を使用して、失敗したプロデューサーがゼロバイトスキャンではなく独自のエラーを表面化するようにします) |
通常のディレクトリスキャンはネイティブバイナリを読み取りません。それぞれが`binary (extension or content sniff)`カバレッジギャップになり、スキャンは依然として`0`で終了し、`--no-default-excludes`はそれを変更しないため、コンパイルされたアーティファクトが対象範囲内にある場合は`--binary`を渡してください。そのフラグには`binary`機能を備えたビルドが必要であり、デフォルトのcrates.ioインストールには含まれていますが、軽量な`ci`機能には含まれていません。
ネイティブバイナリ抽出は、名前付き検出器の明示的な形状契約を満たす完全な認証情報を報告します。コンパイルされたデータセクションからの短いプレフィックス断片や一般的な代入形状の文字列は、それらのバイトがソースコンテキストを保持しないため抑制されます。
エンドポイントフェッチは境界付きでSSRFスクリーニング済みです。これはクローラーではありません。プライベートクラウドエンドポイントと認証情報転送には、明示的な信頼フラグが必要です。プロバイダートークンは、プロセス引数ではなく、文書化された環境変数に属します。
ソースとポリシーの詳細については[ワークフロー選択ツール](https://santhreal.github.io/keyhog/capabilities.html)を、保守されたリポジトリゲートについては[GitHub Actionガイド](https://santhreal.github.io/keyhog/workflows/github-action.html)を、耐久性のあるレポートと終了処理については[直接CIガイド](https://santhreal.github.io/keyhog/workflows/ci.html)を、分割と集約については[大量スキャンガイド](https://santhreal.github.io/keyhog/guides/mass-scanning.html)を参照してください。[レシピクックブック](https://santhreal.github.io/keyhog/recipes.html)は、コンテナ、アーカイブ、URL、GitHubコラボレーションコンテンツ、クラウドソースをカバーしています。
### 推測なしの速度と並行性
デフォルトから始めてください。Cargoは`cargo install`後にKeyHogを実行できません。そのため、マルチバックエンドのCargoビルドをインストールした後に以下のコマンドを一度実行し、ホスト、バイナリ、検出器コーパス、ドライバー、またはワークロードクラスが変更された後に再度実行してください。```sh
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json
| Control | 用途 | 維持すべき不変条件 |
|---|---|---|
調整済み --backend auto | 通常のCPU、Hyperscan、またはGPU選択。 | 明示的なバックエンドは診断用の上書きであり、高速化のデフォルトではない。 |
--threads <N> | 共有ランナーでのCPU容量の確保。専用ホストでは通常は未設定のままにして、KeyHogが利用可能なコアを使用できるようにする。 | すべての値は正でなければならない。複数の並行KeyHogプロセスはそれぞれワーカープールを所有するため、ホストの予算をパーティション間で分割すること。 |
--reader-threads <N> | リーダー処理がスキャンではなくボトルネックとなる、測定済みのストレージパイプライン。 | デフォルトはスキャンワーカープールから導出される。プロファイリングでリーダーのボトルネックが示されるまで未設定のままにする。 |
--incremental および --incremental-cache <PATH> | 同じ信頼済みツリーの繰り返しスキャン。 | 無関係なリポジトリや信頼できないジョブ間で1つのインデックスを共有しないこと。 |
| プロバイダーまたはリポジトリのパーティション | 並行エステートスキャンと独立した再試行。 | パーティションごとに1つのターミナルエンベロープと生の終了コードを維持する。検出結果を連結してカバレッジ状態を破棄しないこと。 |
--verify-concurrency、--verify-rate、および --verify-batch | ファイルスキャンとは独立してライブプロバイダーチェックを制限する。 | 検証は資格情報から導出されたリクエストを送信する。この並行性を所有するのはCPU数ではなく、プロバイダーのレート制限である。 |
| マスデーモン | 1つのUnixワーカー上でのTB規模のディレクトリ、履歴、アーカイブ、リモート、またはクラウドストリーム。 | 各フレームは8 MiBと1,024チャンクに制限される。デーモンはフラグメント状態を直列化し、正確なCPU/GPU実行レシートを返す。 |
--fast、デフォルト、--deep、または --precision | 明示的な検出コストと再現率ポリシーの選択。 | これらのプリセットは相互に排他的であり、カバレッジを変更する。これらは交換可能な速度ノブではない。 |
解決済みポリシーは keyhog config --effective で確認する。--profile を使用して、リーダー、バッチ、またはチャンネル深度の制御を変更する前に、固定スキャナーステージと完全なオペレーター実行を測定する。低オーバーヘッドのレポートには、ソース、バックエンド、キャッシュ、ワークロード、スレッド、入力、状態遷移、CPU時間、ピークメモリ、正確なバイナリSHA-256、有効化機能SHA-256、ターゲットトリプル、ビルドプロファイル、コンパイラ、アロケータ、リンク済みバックエンドSHA-256、検出器コーパスSHA-256、有効化検出器BLAKE3、コンパイル済みプランBLAKE3、ハッシュ化された検出器出所、完全な解決済み構成BLAKE3、パフォーマンスポリシーBLAKE3、プリセット、適用済み保護状態、ソースアダプタ、ハッシュ化されたソースターゲットBLAKE3、ハッシュ化されたソースパーティションBLAKE3、生のソースバイト、ソースユニットファンアウト、デコード導出バイト、完了済みバックエンドディスパッチバイト、および安定したサイズ/ファンアウトバケットが記録される。ソースアダプタがまだ区別できないバイトドメインは、測定されたゼロになる代わりに明示的に利用不可のままとなる。レポートはソースコンテンツ、資格情報値、生のパス、生のURL、または生の構成値を記録しない。--perf-trace は、高コストなパターン別およびバックエンド診断カウンタにのみ使用する。
ターゲットワーカーでの再現可能な測定が改善を示すまで、高度なパイプライン制御は未設定のままにしておく。
定期的な完全リポジトリスキャンの場合:```sh
keyhog scan . --incremental
--format json-envelope --output keyhog.json
共有ランナーで、ジョブに4つのスキャナーワーカーと1つのリーダーワーカーが割り当てられている場合:```sh
keyhog scan . --threads 4 --reader-threads 1 \
--format json-envelope --output keyhog.json
2つ目のコマンドはリソース予算であり、普遍的な最適値ではありません。明示的なワーカー数を選択する前に、対象ホストを測定してください。
ディープリカバリとシステム全体のトリアージについては、専用ガイドを使用してください。これらのカバレッジと完了ルールは通常のリポジトリスキャンとは異なります。
シークレットスキャナーのベンチマーク
これらのパネルは、検出ポリシー、CPUおよびGPU実行リクエスト、インクリメンタルキャッシュの動作、ウォームデーモンリクエストを比較します。すべての値はチェック済みのベンチマークスナップショットから生成されます。スナップショットは、スキャナーバージョン、実行可能ファイルダイジェスト、検出器ダイジェスト、コーパス、ホスト、実行タイムスタンプをバインドします。競合他社の出典とカテゴリ別リコールについては、完全なベンチマーク証拠を参照してください。
検出精度
KeyHog KeyHog v0.5.70 はミラーコーパスをスキャンしました: 15,000フィクスチャ、3,000のラベル付きポジティブ、2,431,242入力バイト。解答キーマニフェストはスキャンツリーから除外されました。この行は、AMD Ryzen 9 9950X 16-Core Processor上の明示的なHyperscan/SIMDルートでデフォルトポリシーを使用します。
| 精度 | 再現率 | F1 | 真陽性 | 偽陽性 | 偽陰性 |
|---|---|---|---|---|---|
| 0.9651 | 0.9027 | 0.9328 | 2,708 | 98 | 292 |
追跡されたソースツリーはクリーンでした。
実行ルート、プリセット、キャッシュ
AMD Ryzen 9 9950X 16-Core ProcessorとNVIDIA GeForce RTX 5090、32論理コア、15,000フィクスチャ、3,000のラベル付きポジティブ、2,431,242入力バイトで測定。スキャナー: KeyHog v0.5.70。追跡されたソースツリーはクリーンでした。
実行ルート別のフルスキャン
すべての行は、インクリメンタルキャッシュとデーモンオフのデフォルト検出ポリシーを使用します。自動行は要求されたポリシーを記録しますが、ベンチマーク結果は選択された永続化ルートをバインドしないため、ルーティングの証明にはなりません。GPU行には、この小さなコーパスでの取得と完全なスキャナー起動が含まれます。これらはGPUカーネルクロスオーバー測定ではありません。
| 要求されたルート | ウォール | スループット | ピーク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 |
| 自動 | 1.46 s | 1.59 MB/s | 634 MiB | 0.9328 |
Hyperscan/SIMDでの検出ポリシー
ルート、キャッシュ、デーモン状態、コーパス、ホストは固定されたままです。プリセットは検出作業を変更するため、時間だけでなく精度と再現率も比較してください。
| ポリシー | ウォール | 精度 | 再現率 | F1 | 検出数 |
|---|---|---|---|---|---|
| 高速 | 737 ms | 0.9700 | 0.8837 | 0.9248 | 2,738 |
| デフォルト | 860 ms | 0.9651 | 0.9027 | 0.9328 | 2,816 |
| ディープ | 861 ms | 0.9645 | 0.9067 | 0.9347 | 2,845 |
| 精度重視 | 849 ms | 0.9590 | 0.6397 | 0.7674 | 2,001 |
インクリメンタルウォーム再実行
ベンチマークはBLAKE3 Merkleインデックスを生成し、2回目の同一スキャンの時間を計測します。スキャナー起動が支配的であるため、小さな合成ツリーはほとんど変化しません。高速化を主張する前にリポジトリを測定してください。
| Hyperscan/SIMDデフォルトポリシー | ウォール | スループット | ピークRSS |
|---|---|---|---|
| キャッシュオフ | 860 ms | 2.70 MB/s | 416 MiB |
| ウォームインクリメンタルキャッシュ | 617 ms | 3.76 MB/s | 457 MiB |
ウォームデーモンリクエスト
決定的な8 MiBの通常ファイル(sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5)が、プロセス内で1回、所有デーモンを介して1回のウォームアップリクエスト後に1回スキャンされました。デーモン時間はクライアントリクエストです。デーモンRSSは常駐サーバーに属します。
| 明示的ルート | プロセス内 | ウォームデーモン | ウォーム/ワンショット | プロセス内RSS | デーモン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 |
これらの行はウォーム単一ファイルルートをカバーします。マスルートは境界付きディレクトリとリモートソースバッチも受け入れます。そのインクリメンタルファイルシステムパスは別途測定されます。
CPU、リーダー、ストレージ、サイズ、パーティションスケーリング
benchmarks/reports/readme-scaling.jsonからmake -C benchmarks readme-scalingによって生成されました。ハーネスは、明示的なsimdとデーモンルーティングオフで1回のウォームアップ後に3回の測定試行を実行しました。ワーカースケーリングは、CPU作業を分離するためにウォームクライアントページキャッシュを使用します。リーダー、コーパスサイズ、ストレージ、パーティション行は、プラットフォームがサポートする場合にposix_fadviseでクリーンページエビクションを要求します。スナップショットはすべての行にポリシーを記録します。すべてのワークロードはバイト決定的で検出なしです。
ホスト: AMD Ryzen 9 9950X 16-Core Processor、32実効論理コア、94,140 MiB RAM、Linux 6.17.0-19-generic。証拠: clean、バイナリ 274b045489c4。
スキャンワーカースケーリング
| ワーカー数 | リーダースレッド | 中央値ウォール | p95ウォール | スループット | スピードアップ | 効率 | 中央値ピーク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 |
ファイルシステムリーダースケーリング
| スキャンワーカー数 | リーダースレッド | 中央値ウォール | p95ウォール | スループット | リーダー1に対する相対 | 中央値ピーク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 |
コーパスサイズスケーリング
| コーパス | ファイル数 | 正確なバイト数 | 中央値ウォール | p95ウォール | スループット | 中央値ピークRSS |
|---|---|---|---|---|---|---|
| small | 256 | 8 MiB | 869.9 ms | 886.1 ms | 9.2 MiB/s | 111.1 MiB |
| medium | 1,024 | 64 MiB | 1,859.9 ms | 1,874.8 ms | 34.4 MiB/s | 126.3 MiB |
| large | 2,048 | 256 MiB | 5,214.9 ms | 5,321.7 ms | 49.1 MiB/s | 137.1 MiB |
ストレージスケーリング
| ストレージクラス | ファイルシステム | デバイスID | 中央値ウォール | p95ウォール | スループット | 最初のストレージに対する相対 | 中央値ピークRSS |
|---|---|---|---|---|---|---|---|
| workspace | ext4 | 66305 | 1,847.4 ms | 1,863.4 ms | 34.6 MiB/s | 1.00x | 127.0 MiB |
| local-temp | tmpfs | 116 | 1,870.8 ms | 1,887.3 ms | 34.2 MiB/s | 0.99x | 124.9 MiB |
並行パーティションスケーリング
| プロセス数 | プロセスあたりのワーカー数 | 合計ワーカー数 | 合計ファイル数 | 合計バイト数 | 中央値ウォール | 合計スループット | スピードアップ | 中央値合計ピーク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 |
これらの行は測定値であり、普遍的なチューニング定数ではありません。対象ホストとストレージでジェネレーターを実行してください。スループットが向上しなくなる膝のポイントを使用し、CIランナーまたはオーケストレーションレイヤー用にCPUとメモリを予約してください。
4つのベンチマークグループすべてをmake -C benchmarks readme-matrixで再現します。このコマンドは要求されたマトリックスを測定し、要求されたCPU、Hyperscan、CUDA、Metal、WGPU、プリセット、キャッシュ、デーモン、スレッド、リーダー、ストレージ、コーパスサイズ、またはパーティション行が利用できない場合に失敗します。make -C benchmarks readme-matrix-checkを使用して、両方のスナップショット、レポート、READMEが一致することを確認してください。
スキャン構成の選択
デフォルトポリシーとキャリブレーション済みの自動ルーティングから始めてください。ワークフローで必要な場合にのみ、1つの軸を変更してください:
| ワークフロー | 検出ポリシー | 実行と再利用 | 追加制御 |
|---|---|---|---|
| 最初のリポジトリスキャン | デフォルト | キャリブレーション済み auto; --daemon=auto | 抑制を追加する前にすべての検出結果を確認してください。 |
| 繰り返しのローカルツリーまたはCIスキャン | デフォルト | キャリブレーション済み auto; --incremental | 同じ信頼されたツリーのスキャン間でのみインクリメンタルキャッシュを永続化してください。 |
| 短いフィードバックループ | --fast | キャリブレーション済み auto; オプションの --incremental | 削減されたデコード、エントロピー、MLカバレッジを受け入れてください。マージ前にデフォルトポリシーを実行してください。 |
| 最高再現率リカバリ | --deep | プロセス内 | ディープは高速および精度重視と相互排他的であり、デーモン対象外です。 |
| 低ノイズ大規模インベントリ | --precision | リポジトリコレクション、履歴、クラウドソースのプロセス内 | このプリセットは信頼度フロアを引き上げ、エントロピー検出を無効にします。低信頼度の認証情報を見逃す可能性があります。 |
| Unix上のTB規模のディレクトリ、履歴、アーカイブ、リモート、またはクラウドインベントリ | デフォルト | keyhog daemon start --mass、次に --daemon=mass | バッチは8 MiBと1,024チャンクで境界が維持されます。ターミナルカバレッジレポートとGPU実行レシートを保存してください。 |
| ライブ認証情報検証 | デフォルト | プロセス内 | --verifyを明示的に追加してください。検証は認証情報から派生したリクエストをプロバイダーに送信します。 |
| Linuxスワップなしスキャン | デフォルトプラス --lockdown | プロセス内; インクリメンタルキャッシュ無効 | ロックダウンは検証、平文シークレット、高速モード、完全性を低下させるスイッチを拒否します。 |
--fast、--deep、--precisionは相互排他的な検出プリセットです。--lockdownはフェイルクローズ実行モードであり、4番目のプリセットではありません。明示的な--backend値は診断およびベンチマークオーバーライドです。これらは自動ルーティングで使用される永続化された最速正解証拠を置き換えるものではありません。設定、オートルートキャリブレーション、デーモンとウォームスキャン、ハードニングで完全な契約を参照してください。
KeyHogの仕組み
KeyHogは934の検出器を共有トリガーおよび抽出プランにコンパイルし、マッチング前にネストされたエンコーディングをデコードし、検出器ごとのスコアリング、証拠、抑制を適用します。Pure-Rust CPU(cpu-fallback)は常に利用可能です。Hyperscanルート(simd-regex)は、その機能が存在する場合にHyperscanを使用します。ポータブルビルドはCPUルートを使用します。CUDA(gpu-cuda-region-presence)、Metal(gpu-metal-region-presence)、WGPU(gpu-wgpu-region-presence)は、フォールバックチェーンではなく、証明に基づくオートルートセレクターのピアです。キャリブレーションはすべての適格なピアを測定し、正確なバイナリ、検出器および構成状態、ホスト、アクセラレータ、ワークロードクラスに対して、完全な検出結果が参照ルートと一致する最速ルートを永続化します。欠落、古い、無効、または不完全な決定は、実行前に自動スキャンを停止し、再キャリブレーション方法を報告します。別のバックエンドを黙って代用することはありません。
リポジトリマップ、依存関係の方向、バイトから検出へのパイプライン、プロファイリングエントリポイントについてはアーキテクチャを参照してください。実行契約についてはバックエンドとルーティング、パリティ、ワークロードID、キャッシュライフサイクル、修復手順についてはオートルートキャリブレーションを参照してください。
完全なドキュメント: santhreal.github.io/keyhog - インストール、最初のスキャン、出力形式、検出内部、抑制、検証、pre-commit + CI統合、CLIリファレンス、オートルート、終了コード、環境変数、コントリビューション。ソースはdocs/の下にあります。
KeyHogのインストール
現在のcrates.ioリリースをインストール:```sh cargo install keyhog --locked
リポジトリのチェックアウトをビルドするのは、未リリースの変更が必要なときだけにしてください。```sh
cargo install --path crates/cli --locked
インストールされたビルドを確認します:```sh keyhog --version --full keyhog doctor
Rustツールチェーンの要件、機能プロファイル、プラットフォーム固有のランタイム依存関係については、[インストールガイド](https://santhreal.github.io/keyhog/install.html)を参照してください。
## 検出対象
934個の組み込み検出器を搭載し、各検出器が独自のオフライン検証とコンパニオンを持ちます:
- **クラウドプロバイダー:** AWS(アクセスキー+シークレット+STS検証)、Azure(サブスクリプションキー、ストレージアカウントキー、SAS)、GCP(サービスアカウント、APIキー)、Cloudflare、Heroku、Vercel、Supabase。
- **決済プロセッサ:** Stripe、Braintree、Razorpay、Paddle、Plaid、Square、PayPal。検出器独自のチェックと、オプションまたは必須のコンパニオンを備えています。Razorpayのキーシークレットには、近くのキーIDが必要です。
- **ソースフォージ:** GitHub PAT(CRC32チェックサム付き)、GitLabトークン、Bitbucketアプリパスワード、npmトークン(チェックサム付き)、Gitea / Forgejo / Codeberg。
- **認証 / SSO:** Okta、Auth0、Clerk、JumpCloud、Kinde。
- **コミュニケーション:** Slack、Discord、Twilio、SendGrid、Postmark、Mailgun、Resend、Loops。
- **AI / ML:** OpenAI(sk-/sk-proj-)、Anthropic、Google AI Studio、Cohere、Mistral、HuggingFace、Replicate。HuggingFace組織の認証情報には、現在の`hf_`形式とレガシーの`api_org_`トークンの両方が含まれます。
- **パスワードマネージャー:** 1Passwordアカウントシークレットキー(`A3-`に続く5〜6個のセグメント化された大文字英数字コンポーネント)。
- **データベース:** Postgres接続文字列、MongoDB Atlas、Supabaseサービスロール、PlanetScale、Neon、Turso、MySQL、Redis URL。
- **汎用+エントロピー検出:** `API_KEY=<高エントロピーブロブ>`は、名前付き検出器のない認証情報を捕捉し、コンテキストごとのエントロピー閾値+MLスコアリングで制御されます。
- **暗号素材:** RSA / EC / SSH秘密鍵、PGP秘密ブロック、JWT署名シークレット。
各検出器は[TOMLファイル](https://github.com/santhreal/keyhog/blob/main/detectors)(データでありコードではない)として提供されます: サービスメタデータ、正規表現パターン、キーワード、オフライン検証器、エントロピーとMLポリシー、コンパニオンフィールド、検証ハンドラー。新しい検出器の追加は、レビュー可能な単一のTOML変更で完了します。[コントリビューターガイド](https://github.com/santhreal/keyhog/blob/main/CONTRIBUTING.md)でその手順を説明しています。
`keyhog explain <id>`は、任意の検出器の完全な仕様を出力します: パターン、キーワード、検証エンドポイントに加え、サービス別のローテーションとステップバイステップの修復ガイド。これにより、検出結果がブラックボックスになることはありません:
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/7654/0fc64959950abfa39c0ba81a1f5fbde3fe17a57169d2edca38cb0f248c834470.gif" alt="keyhog explain github-classic-pat: 検出器仕様ダンプ(パターン ghp_[A-Za-z0-9]{36}、キーワード、検証URL)に続くgithubローテーションガイドとステップバイステップの修復手順" width="860" />
</p>
検出器の作成と検査は、[検出器リファレンス](https://github.com/santhreal/keyhog/blob/main/docs/src/detectors.md)で参照するか、インストール済みのコーパスを`keyhog detectors --search <term> --verbose`でクエリできます。
## 高い再現率、少ない誤検知の理由
- **デコードスルースキャン。** Kubernetes `Secret`マニフェスト、Jupyterノートブック、JWTペイロード、base64ラップされた環境変数、Helm values、docker-configの`auth:`ブロブ。構造化プリプロセッサは、バランスの取れたHelmアクションを不活性なレンダリング時値として扱い、ファイル末尾で欠落したJupyter区切り文字を閉じるため、リテラルバイトと完全なコードセルがカバーされ続けます。構造化値をその場でデコードし、すべての下流検出器に平文を供給します。検出器はそれぞれデコードを再実装する必要はありません。デコード有効スキャンは、すべての復元素材が埋め込まれている場合、副作用のないJavaScriptバイト配列XORおよびAES-256-CBC式も復元します。厳密なCryptoJS/OpenSSLソルト付きパスフレーズラッパーも含みます。KeyHogはソースを実行することはありません。
- **複数行の再構築。** JavaScriptでの`"sk-proj-" + \`継続、YAML複数行文字列、Makefileのバックスラッシュ継続、Helm / Jinjaテンプレート出力。すべて正規表現マッチングの前に再構築されます。
- **コンパニオン検証。** 必須コンパニオンは高ノイズ検出器を制御します。APIシークレットのないTwilio APIキーはスキップされます。オプションのコンパニオンは証拠スコアリングまたは検証を強化します。AWSアクセスキー検出はシークレットを必須としませんが、ライブ検証にはシークレットが必要です。
- **クロス検出器解決。** 検出器TOMLは、別の検出器からの境界付き検出結果を必須化、拒否、または包含できます。解決は入力順序に関係なく決定的であり、無効なターゲット、矛盾、依存関係の循環はコーパスコンパイルを失敗させます。
- **証拠判定。** すべての検出結果には、正確な`review`、`likely`、または`confirmed`の階層と正規の理由コードが付与されます。固有のチェックサムまたは文法証明、必須コンパニオン、ライブ検証はconfirmed証拠を生成します。認証情報保持ロールでの強力なベンダー固有の形状はlikely証拠を生成します。弱いアンカー、汎用割り当て、エントロピーのみの候補、およびテスト、ドキュメント、ルール、識別子コンテキストはreview証拠のままです。オプションの`evidence_score`は、測定された場合に判定を補足します。デフォルトの閾値`0.40`はスキャナーの内部信頼度フロアを制御し、`--min-confidence`で設定可能なままです。
- **ベイズ型検出器別キャリブレーション。** `keyhog calibrate --fp generic-api-key`はBeta(α,β)事後分布を書き込みます。スキャンは、`--calibration-cache`または`[system].calibration_cache`がそのファイルを指す場合にのみそれを使用するため、信頼度チューニングは明示的かつ再現可能であり、無関係なホストキャッシュ状態に依存しません。
## パフォーマンス
[`benchmarks/`](https://github.com/santhreal/keyhog/blob/main/benchmarks)の再現可能なハーネスを使用して、KeyHog、Betterleaks、Kingfisher、Nosey Parker、TruffleHog、Titusを単一のスコアリング契約で比較します。ハーネスは、すべてのスキャンツリーからグラウンドトゥルースマニフェストを除外します。生成されたテーブルは、現在のスキーマの実行が存在するまで空のままです。測定後に`make -C benchmarks report`を実行してください。生成されたテーブルを手動で編集しないでください。
### 検出リーダーボード
<!-- BENCH:leaderboard:start -->
#### 合成SecretBench形状ミラーコーパス
コーパス: **mirror** - 15000フィクスチャ、3000個のラベル付きポジティブ、2,431,242バイト。すべてのスキャナーが同一にスコアリングされました(SecretBench重複ルール)。解答キーマニフェストはスキャンツリーから除外されています。
| 順位 | スキャナー | F1 | 適合率 | 再現率 | 検出数 | 実行時間 | ピーク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 |
#### 競合他社ホームフィールド / ホームターフルールコーパス
コーパス: **homefield** - 競合他社のグラウンドトゥルースルールスイート(BetterleaksおよびKingfisherルール)から収集された2399フィクスチャ(1,057個のラベル付きポジティブ、1,342個のネガティブ、772,974バイト)。競合他社のグラウンドトゥルースに対するクロスツール評価。
| 順位 | スキャナー | F1 | 適合率 | 再現率 | 検出数 | 実行時間 | ピーク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 |
### 結果の来歴
| スキャナー | スキャナーバージョン / 実行可能ファイルダイジェスト | コーパスID | ホストID | 実行日 |
|---|---|---|---|---|
| KeyHog | バージョン: KeyHog v0.5.70<br>コミット: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>検出器セット: 926 (926-4168e2c6c93a16ca)<br>ビルドターゲット: x86_64-linux<br>MLモデルバージョン: moe-v1-246a05b92bec9aa3<br>MLモデルカード: 記録日 2026-07-15; 特徴量 55; 合成 F1 0.971 / P 0.945 / R 0.999; 実データ F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; ゼロ再現率検出器 2/32; 6スキャナー差分は利用不可<br>実行可能ファイルSHA-256: `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:29:39Z |
| TruffleHog | バージョン: trufflehog 3.96.0<br>実行可能ファイルSHA-256: `6eb1f98fb890bf9361d8833c061e122dcb4f14fb7b71c65e603b7c096153c724` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:29:58Z |
| Kingfisher | バージョン: kingfisher 1.94.0<br>実行可能ファイルSHA-256: `a49f8e9838d7f1da1e9f328a4dbc45a16996bce5078cde3ff1b8ad422d8ab07a` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:29:50Z |
| Titus | バージョン: Titus v1.1.20 (NoseyParkerのGo移植版)<br>実行可能ファイルSHA-256: `0b9c126a6c280ba28c6ed8795f88bf9bd793164c15959a34921f47a7ed276bcf` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:30:03Z |
| Nosey Parker | バージョン: noseyparker 0.24.0 ビルド構成: ビルドタイムスタンプ: 2025-05-08T21:11:15.600909923Z コミットタイムスタンプ: 2025-05-08T17:04:47.000000000-04:00 コミットブランチ: HEAD コミットSHA: 61fa4ca67e4ded1b47b3b9ecce618ae91f1ff2fe Cargo機能: color_backtrace,default,disable_trace,github,log,mimalloc,parquet,release デバッグ: true 最適化: 3 ターゲットトリプル: x86_64-unknown-linux-gnu ビルドシステム: OS: Ubuntu OSバージョン: Linux (Ubuntu 22.04) CPUベンダー: AuthenticAMD CPUブランド: AMD EPYC 7763 64コアプロセッサ CPUコア: 2 rustcバージョン: 1.86.0 rustcチャンネル: stable rustcホストトリプル: x86_64-unknown-linux-gnu rustcコミット日: 2025-03-31 rustcコミットSHA: 05f9846f893b09a1be1fc8560e33fc3c815cfecb rustc LLVMバージョン: 19.1<br>実行可能ファイルSHA-256: `42d6e88bf77904866a9dda49d7cf333501e76b62e9054b112e67f81dc88e2b71` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:29:53Z |
| Betterleaks | バージョン: betterleaks version dev<br>実行可能ファイルSHA-256: `466f7d34e1ebcf12ecd5939494f509c17125e54416226976fced2f046da56ba4` | mirror; 15,000フィクスチャ; 3,000個のラベル付きポジティブ; 2,431,242バイト | ホスト名SHA-256/12: `82fcd9288623`<br>Linux 6.17.0-19-generic<br>AMD Ryzen 9 9950X 16コアプロセッサ | 2026-08-11T01:29:43Z |
<!-- BENCH:leaderboard:end -->
### 速度とメモリ
<!-- BENCH:perf:start -->
#### 合成SecretBench形状ミラーコーパス
| スキャナー | 構成 | コーパス | 実行時間 | スループット | ピーク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 |
#### 競合他社ホームフィールド / ホームターフルールコーパス
| スキャナー | 構成 | コーパス | 実行時間 | スループット | ピーク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 -->
### カテゴリ別再現率比較
<!-- BENCH:gaps:start -->
_診断用再現率スライスのみ。全体的な適合率とF1が比較契約であり、誤検知はスコアリングされたカテゴリでカウントされます。_
| カテゴリ | KeyHog P/R/F1 | KeyHog TP/FN | 最良の競合他社 P/R/F1 | 再現率ギャップ |
|---|---|---|---|---|
| `generic-high-entropy-string` | 1.000 / 0.434 / 0.606 | 73/95 | Betterleaks 1.000 / 0.798 / 0.887 | +0.363 |
<!-- BENCH:gaps:end -->
### 境界付き静的復元テレメトリ
<!-- BENCH:recovery:start -->
選択された実行: スキャナー **KeyHog** `KeyHog v0.5.70<br>コミット: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>検出器セット: 926 (926-4168e2c6c93a16ca)<br>ビルドターゲット: x86_64-linux<br>MLモデルバージョン: moe-v1-246a05b92bec9aa3<br>MLモデルカード: 記録日 2026-07-15; 特徴量 55; 合成 F1 0.971 / P 0.945 / R 0.999; 実データ F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; ゼロ再現率検出器 2/32; 6スキャナー差分は利用不可`; コーパス **mirror** (15,000フィクスチャ、2,431,242バイト); 生成日 `2026-08-11T01:29:39Z`; アーティファクト `mirror-keyhog-simd-nocache-nodaemon-full.json`。
テレメトリスキーマ: `static-recovery-v1`。
| 処分 | 正確な数 |
|---|---:|
| サポート済み | 0 |
| 未サポート | 0 |
| エラー | 0 |
| 拒否理由 | 正確な数 |
|---|---:|
| _なし_ | 0 |
<!-- BENCH:recovery:end -->
### バイグラムBloom証拠
<!-- BENCH:bloom:start -->
証拠スキーマ: `bloom-evidence-v1`。
| フィールド | 正確な結果 |
|---|---|
| コーパス | `samsung-creddata-fx-record-spans-v1` |
| コーパスリビジョン | `f1de3f85dbdf42bf7b3467c0d273a4dfe44d56ee` |
| コーパスSHA-256 | `4f2de506f334521121bb5b4aef8a37bf0b8153a4f9115e7ba9392d0eed1757b9` |
| フィクスチャSHA-256 | `a0ff018dc0a64b2cc78b25999043d1a441afa0087070f4cd8d73ae82408a59b4` |
| 実行可能ファイルSHA-256 | `2899ee53789bff9c531f72645f6c8380a7c873230dfb2b6857079467bc8d2dcd` |
| ワークスペース検出器コーパスSHA-256 | `d87e8b3d086e9ffa4c8a94f35a717ec710d5224e52e5b4fc7e71db30677609c9` |
| スキャナー検出器ダイジェスト | `8d789251e092959f` |
| 検出器コーパスSHA-256 | `3729bd72df768187420f37e08ab64cd2b5a8bac558002d8b0844f465e9a75711` |
| Bloom拒否 | **110/51794 (0.21%)**; 51684件受理 |
| 外部可用性 | 51794件測定; 宣言された51794件のうち明示的に利用不可は0件; 理由: |
| 有効化 vs バイパスされた検出結果 | **同一**; 977/977件の検出結果 |
| 検出結果ID SHA-256 | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Bloom密度/状態 | 1793/65536スロット; `healthy`; 飽和度 39322 |
検出結果IDは、検出器、ファイル、行、バイトスパン、および認証情報SHA-256をバインドします。平文の認証情報は決して記録されません。
<!-- BENCH:bloom:end -->
再現: `make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
は、実行可能ファイルにバインドされたCredData Bloom差分を含む、KeyHog、Betterleaks、Kingfisher、Nosey Parker、TruffleHog、Titusの正確なミラー実行セットを再実行します。`make -C benchmarks report`は上記のテーブルと`benchmarks/reports/`を再生成します。コーパス(mirror、競合他社ホームターフ、Samsung/CredData)とバックエンド/キャッシュ/デーモン/OS/GPUマトリックスについては、[`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)を参照してください。
## GPU対応の大規模デーモンワーカー
オプションのUnixマスデーモンは、コンパイル済みのスキャナー1つとそのキャリブレーション済みバックエンド状態をウォームに保ちます。ローカルファイルシステムスキャンは、正規ルートとソースポリシーメタデータのみを送信します。デーモンは独自のプロセスでファイルを読み取り、バッチ処理します。クライアント側の認証情報を必要とするGit、バイナリ、リモート、クラウドソースは、保護された境界付きチャンクフレームを使用します。```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 は必須のルートです。プロセス内で再試行することはありません。各バッチは、総入力サイズに関係なく、8 MiB と 1,024 チャンクに制限されます。すべてのインベントリパーティションについて、カバレッジエンベロープ、終了ステータス、およびターミナル実行レシートを保持します。
デーモンのライフサイクル、ルーティング、およびレシート と インベントリのパーティショニング を参照してください。
システム全体の認証情報トリアージ```sh
sudo keyhog scan-system --space 50G sudo keyhog scan-system --include-network --output system-findings.json
`scan-system` は境界付きのローカルホスト監査であり、リポジトリや
クラウドのインベントリ分割の代替ではありません。パスではなく、スキャンされた合計バイト数によって境界を設定します。`--space` が上限であり、`--include-network` を渡さない限り、ネットワークマウントされたファイルシステムはスキップされます。実行前に、マウント、ネットワークファイルシステム、スペース上限、および権限の動作を確認してください。[システム全体のトリアージ](https://santhreal.github.io/keyhog/guides/system-wide-triage.html) を参照してください。
## 機密性の高いローカルスキャンのロックダウン
Linux の `--lockdown` は、フェイルクローズ型のプロセス保護モードです。```sh
keyhog scan . --daemon=off --lockdown
現在および将来のメモリをロックし、コアダンプとインクリメンタルキャッシュを無効化し、プロセス内に留まり、検証、平文出力、高速モード、および完全性を低下させるスイッチを拒否します。サポートされていないプラットフォームやロックされたメモリ容量が不十分な場合は失敗します。詳細は ハードニングとデータ処理 を参照してください。
KeyHog を Rust ライブラリとして使用する```rust
use keyhog_core::{Chunk, ChunkMetadata, RawMatch}; use keyhog_scanner::CompiledScanner;
let detectors = keyhog_core::load_embedded_detectors_or_fail()?; let scanner = CompiledScanner::compile(detectors)?; let findings = scanner.scan(&Chunk { data: "TOKEN=sk_live_EXAMPLE…".into(), metadata: ChunkMetadata::default(), })?; let report_safe: Vec<_> = findings.iter().map(RawMatch::to_redacted).collect();
デフォルトのライブラリメソッドは、決定的でポータブルなCPU参照です。明示的な
バックエンドメソッドは、プロセスを終了させたり、別のエンジンに暗黙的に置き換えたりする代わりに、型付きエラーを返します。生のチャンクとマッチには平文が含まれる場合があります。JSON、ログ、ディスク、またはネットワーク境界に渡す前に、`RawMatch::to_redacted`で変換するか、最終的な`VerifiedFinding`値を使用してください。
[アーキテクチャガイド](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md)は、クレートの所有権、バックエンド契約、リカバリレシート、ソースヘルパー、および安全なレポート境界を定義します。クレートレベルのRustドキュメントが完全なAPIを所有します。
## 明示的な優先順位でポリシーを設定する
リポジトリポリシーは`.keyhog.toml`にあります:```toml
verify = false
[scan]
severity = "high"
incremental = true
[system]
gpu = "auto"
解決順序は、組み込みのデフォルト、ユーザー設定、リポジトリ設定、文書化された環境、そして明示的なCLIオーバーライドの順です。未知のキーや無効な組み合わせは、スキャン前に失敗します。keyhog config --effective を実行すると、プロキシ認証情報を公開せずに解決済みポリシーを確認できます。expires を過ぎたエントリは、スキャン前に許可リストの読み込みに失敗します。
すべてのキーについては 設定と優先順位、認証情報とランタイム入力については 環境変数 を参照してください。
アーキテクチャ
KeyHog はオーケストレーションをエッジに置き、ドメインの動作をライブラリに保持します:```text sources -> scanner -> suppression/evidence -> reporting -> optional verifier CLI and Action own process, transport, and exit semantics.
Detector定義は引き続き`detectors/`配下のデータとして保持されます。`keyhog-core`はdetectorとfindingの型を所有し、`keyhog-scanner`はマッチングと実行バックエンドを所有し、`keyhog-sources`は入力取得を所有し、`keyhog-verifier`はライブチェックを所有し、`keyhog-cli`はオペレーター向けワークフローを所有します。
リポジトリマップ、依存関係の方向、バイトからfindingへのパイプライン、ルーティングの所有権、プロファイリングのエントリポイントについては、[アーキテクチャガイド](https://github.com/santhreal/keyhog/blob/main/docs/src/architecture.md)から始めてください。
## インストールの確認と拡張```sh
keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh
CLI リファレンスには、すべてのコマンド、フラグ、生成されるデフォルト値、終了ステータスが記載されています。インストールされている正確なバージョンについては、keyhog --help と keyhog <command> --help を使用してください。
コントリビューション
- 新しいディテクター?
detectors/に TOML を置き、PR を開いてください。コントリビューターガイド (CONTRIBUTING.md) にスキーマと実例があります。 - バグ / 検出漏れ / 誤検知? マスクした認証情報の形状とディテクター ID を添えて issue を登録してください。各レポートは、
crates/scanner/tests/contracts/配下の恒久的なテストフィクスチャになります。 - リリースの挙動?
mainブランチの CI が成功するたびにパッチバージョンが増加し、チェンジログが生成され、6 つのクレートすべてが crates.io に公開されます。正確なメモが必要な場合は、changes/配下に任意のフラグメントを追加してください。リリースガイド には、自動トランザクションとアップロード失敗時の復旧方法が記載されています。 - KeyHog 自体のセキュリティ問題? 公開 issue を開かず、GitHub のプライベート脆弱性報告 を使用してください。そのフォームが利用できない場合は、
[email protected]にメールしてください。PGP は不要です。
クレジット
KeyHog は、これまでのシークレットスキャンに関する取り組みの上に成り立っています。以下のプロジェクトからアイデアを借用しています:
- TruffleHog: ディテクターの網羅性と検証のセマンティクス
- Betterleaks: トークン効率と誤検知の抑制
- Titus: スキャンの人間工学と深刻度の調整
これらのプロジェクトとそのコントリビューターに感謝します。
ライセンス
ライセンス: MIT OR Apache-2.0。
条件: MIT および Apache-2.0。このデュアルライセンスは、コードとディテクター TOML を対象としています。商用利用、組み込み、フォーク、ホステッドサービスは、いずれかのライセンスの下で許可されます。
スター履歴
[GitHub の公開スター数の UTC 観測](https://github.com/santhreal/keyhog/blob/main/metrics/stars.json) から生成されています。リポジトリには、最初の時点とその後の各カウント遷移が保存されます。同日の再実行はその日の時点を置き換え、カウントに変更がなければコミットは作成されません。