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、十六进制、URL、protobuf、多行及结构化配置。	通过提供商API验证符合条件的凭据，输出SARIF或结构化信封，并保留精确的覆盖范围和退出语义。
cargo install --locked keyhog

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/7654/dfb768a9b8e8fa64082992f11d0b284d5ec6a199fc1eac85e0352fb20452186f.gif" alt="KeyHog 扫描显示严重性、证据、文件和行号、修复建议、结果及覆盖状态" width="900" />
</p>

## 围绕 GPU 构建的密钥扫描器

KeyHog 并非将几个正则表达式交给一个通用计算着色器。
其 GPU 路径构建于 [Vyre](https://github.com/santhreal/vyre) 之上，这是一个与 KeyHog 同步开发的 Rust GPU
计算底层框架。检测器触发器会编译为
不可变的 GPU 常驻表。有界源批次为与 CPU 和 Hyperscan 路由
所使用的相同确认、抑制、证据和报告
流水线产生完整的匹配位置。

- **三个物理 GPU 对等端。** CUDA、原生 Metal 和可移植 WGPU 会被
  独立获取、测量并报告。
- **精确的结果一致性。** 校准会拒绝其发现
  身份与参考路由不同的候选方案。更快的错误答案永远不会进入
  路由表。
- **持久的路由证据。** KeyHog 记录二进制文件、检测器语料库、
  配置、工作负载类别、主机、加速器、驱动程序和测量的时序
  证据。正常扫描不会在热路径中进行基准测试。
- **常驻执行。** 守护进程工作线程保持编译后的检测器和加速器
  状态处于热状态，以处理重复的文件、归档、历史记录、远程和云批次。
- **无隐藏的 CPU 逃生通道。** 显式选择的加速器若无法
  初始化或调度，会以可见方式失败，而不是在 GPU 标签下返回 CPU 发现结果。

默认的 crates.io 安装使用可移植的纯 Rust CPU 路由，因此它可以在
干净的 Rust 主机上运行。无需获取 Hyperscan 即可启用三个 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

后端指南记录了常驻表、有界调度模型、一致性契约以及可复现的交叉验证证据。

快速开始

安装并运行你的第一次扫描

上述两条命令会安装最新的 crates.io 版本，并通过便携式纯 Rust 路由扫描当前目录树。

要将 CI 环境固定到某个精确版本，请使用 cargo install --locked --version '=0.5.86' keyhog。KeyHog 需要 Rust 1.89 或更高版本。有关 GPU、Hyperscan、CI、便携式及源码构建配置，请参阅安装指南。

当某个发现阻止了当前生效的证据策略时，KeyHog 会以退出码 1 结束。默认策略会阻止 likely 和 confirmed 级别的发现，同时以退出码 0 保持 review 级别的发现可见；--evidence-policy paranoid 则会阻止所有层级。请逐一审查每个发现的确切证据层级、原因代码、文件、行号、检测器及修复建议。其他非零退出码则描述输入、系统、验证或覆盖范围方面的失败；请参阅退出码参考。

完整的进程契约如下：

过滤、格式化、门控：

在将其用作过滤器之前，请先创建基线：```sh keyhog scan . --create-baseline .keyhog-baseline.json keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json

第一条命令会快照已审阅的发现结果并以 `0` 退出，不打印这些结果。提交该文件后，使用第二条命令仅报告新的发现身份。基线条目按检测器和凭据值匹配，绝不按文件路径匹配，因此移动已记录的机密不会导致门禁失败，但轮换机密则会。已更改的凭据和不完整的覆盖范围仍然可见。完整路径（包括 monorepo 分区）见 [仅在新机密上失败](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 以及整台机器，而无需更换工具。

### 守护仓库以实现快速的预提交扫描

使用常驻的 KeyHog 守护进程注册一个仓库，以实现快速的预提交机密检测（需要 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

参见永久守卫指南和pre-commit工作流以了解完整配置、状态机生命周期及钩子自动化。

将其添加到 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

该操作会扫描检出的工作树，在发现`high`或`critical`级别的问题时失败，将SARIF上传到Code Scanning，并将报告作为工作流工件保留。安装、覆盖率、后端和报告发布失败也会导致作业失败。

请参阅[GitHub Action指南](https://santhreal.github.io/keyhog/workflows/github-action.html)了解输入、输出、基线采用、monorepo分区、验证和失败行为。请参阅[CI指南](https://santhreal.github.io/keyhog/workflows/ci.html)了解GitLab、CircleCI、Jenkins、Buildkite和通用shell作业。请参阅[大规模扫描指南](https://santhreal.github.io/keyhog/guides/mass-scanning.html)了解仓库组织、托管Git组、云存储桶和分区清单。

## 其他工具视为独立产品的扫描面

KeyHog在字节可能泄露的边界处进行扫描，而不仅仅是受跟踪的源文件。每个边界使用一份报告，以便CI保留确切的覆盖率和失败状态。

| 暴露面 | 示例 |
|---|---|
| 最终包工件 | 运行`npm pack`，然后使用`keyhog scan package.tgz`扫描生成的`.tgz`。归档解压会检查预期源树中不存在的生成文件、源映射、fixtures和元数据。 |
| 已部署的浏览器应用 | `keyhog scan --url https://app.example.com/assets/app.js`遵循有界的JavaScript、源映射、WASM和响应解码，而不会将扫描器变成无界爬虫。 |
| GitHub issues、pull requests、discussions、wikis和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历史。 |

这些路径共享一个检测和报告契约。特定于源的失败不能静默地变成范围更窄的本地扫描。

## 选择正确的工作流

首先选择源边界。预设会改变检测工作，而后端会改变执行方式。两者都不会将工作树扫描扩展为Git历史、提供程序清单、云存储或主机审计。

不存在诚实的`scan everything`捷径。完整的资产审查会将以下相关边界作为独立作业运行，并保留每个`json-envelope`报告及其原始退出代码。

| 需求 | 从以下开始 | 吞吐量和复用 | 覆盖率边界 |
|---|---|---|---|
| 快速本地反馈 | `keyhog scan . --fast --incremental` | 复用未更改文件的哈希。快速预设跳过解码、熵和ML工作。 | 在合并前运行默认策略，因为快速模式有意更窄。 |
| 完整仓库扫描 | `keyhog scan .` | 校准的`auto`和CPU核心工作线程默认值。对同一可信树重复扫描时添加`--incremental`。 | 仅当前文件。不添加Git历史。 |
| 暂存提交门禁 | `keyhog scan --git-staged`或`keyhog hook install` | 读取确切的索引blob，因此未暂存的编辑无法改变结果。 | 仅暂存内容。当本地未暂存字节重要时，请单独运行工作树扫描。 |
| 持续仓库守护 | `keyhog guard add . --mode repo`然后`keyhog guard status .` | 守护进程驻留的根注册表，具有7状态机、干净证明缓存和策略身份跟踪。 | 需要运行中的守护进程。守护进程补充而非替代暂存和工作树扫描。 |
| GitHub pull-request门禁 | `santhreal/keyhog@v0` | 该Action安装、扫描、发布SARIF和工件，然后保留KeyHog的状态。 | 一个检出的路径。组织级使用提供程序清单扫描。 |
| GitLab、Jenkins、Buildkite或shell CI | `keyhog scan . --format json-envelope --output keyhog.json` | 在成功、发现问题和错误时持久化报告和退出代码。仅在明确更窄的变更行门禁时使用`--git-diff <base>`。 | 检出中存在的字节，或选定的diff。 |
| 采用已知问题的仓库 | 创建`.keyhog-baseline.json`，提交它，然后使用`--baseline .keyhog-baseline.json`扫描。 | 现有身份在基线中保持可见，只有新发现的问题才会使门禁失败。 | 基线不会抑制已更改的凭据或不完整的覆盖率。 |
| 递归Git恢复 | `keyhog scan --deep --git-history . --git-blobs . --daemon=off` | 每个工作线程类别校准一次深度策略。在进程内运行。 | 一个仓库。`--git-history`仅覆盖当前检出的祖先，因此从未检出的分支会被遗漏且无覆盖率缺口；`--git-blobs`还可达悬空blob、已修改掉的提交、stash、notes、带注释的标签消息和打包引用。 |
| 容器或归档检查 | `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` | 按提供程序、所有者或存储桶分区。并发运行独立分区，每个分区各有一份报告和状态。 | 每个作业一个选定的提供程序清单。分页或对象限制仍是覆盖率边界。 |
| 确认符合条件的发现是否有效 | `keyhog scan . --verify` | 提供程序并发和速率控制与扫描器工作线程分开。 | 向声明的提供程序端点发送凭据派生的请求。并非每个检测器都支持验证。 |
| 全主机健康扫描 | `sudo keyhog scan-system --space 50G` | 默认使用所有CPU核心，并在文件系统数据之后扫描发现的Git历史。 | 本地挂载的文件系统。网络挂载为可选，空间上限是硬性的。 |
| Unix上GPU支持的目录、历史、归档、远程或云清单 | 校准autoroute，启动`keyhog daemon start --mass`，然后运行`keyhog scan --daemon=mass <SOURCE>`。 | 通过一个编译的CPU、Hyperscan、CUDA、Metal或WGPU工作线程流式传输有界批次。对热未更改的文件系统树添加`--incremental`。终端收据报告确切的总数和GPU批次、块、字节、GPU份额和吞吐量。 | 基线、验证、锁定、预设、叠加和其他扫描器策略更改在获取前被拒绝。增量状态仅适用于守护进程本地的文件系统根。 |

### 扫描每个受支持的源边界

每个边界使用一条命令。为每个清单分区保留`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、pull requests、discussions、wikis和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`，使失败的producer暴露其自身错误，而不是零字节扫描） |

普通目录扫描不读取原生二进制。每个二进制都成为`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

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

对于共享运行器，其中作业分配了四个扫描器工作进程和一个读取器工作进程：```sh
keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

第二个命令是资源预算，而非通用最优值。在选择显式工作线程数之前，请先测量目标主机。

对于深度恢复和全系统分类，请使用其专用指南，因为它们的覆盖范围和完成规则与常规仓库扫描不同。

密钥扫描器基准测试

这些面板比较了检测策略、CPU 和 GPU 执行请求、增量缓存行为以及热守护进程请求。每个值均来自已检查的基准测试快照。该快照绑定了扫描器版本、可执行文件摘要、检测器摘要、语料库、主机和运行时间戳。请使用完整基准测试证据获取竞争对手来源和按类别召回率。

检测准确性

KeyHog KeyHog v0.5.70 扫描了 mirror 语料库：15,000 个测试夹具、3,000 个标记的正样本，以及 2,431,242 个输入字节。答案密钥清单已从扫描树中排除。该行使用默认策略，在 AMD Ryzen 9 9950X 16 核处理器 上通过显式 Hyperscan/SIMD 路由执行。

精确率	召回率	F1	真阳性	假阳性	假阴性
0.9651	0.9027	0.9328	2,708	98	292

被跟踪的源树是干净的。

执行路由、预设和缓存

在 AMD Ryzen 9 9950X 16 核处理器 上，配备 NVIDIA GeForce RTX 5090、32 个逻辑核心、15,000 个测试夹具、3,000 个标记的正样本和 2,431,242 个输入字节进行测量。扫描器：KeyHog v0.5.70。被跟踪的源树是干净的。

按执行路由的完整扫描

所有行均使用默认检测策略，增量缓存和守护进程关闭。自动行记录请求的策略，但基准测试结果不绑定所选持久化路由，因此它不是路由证明。GPU 行在此小语料库上包含获取和完整扫描器启动；它们不是 GPU 内核交叉测量。

Hyperscan/SIMD 上的检测策略

路由、缓存、守护进程状态、语料库和主机保持不变。预设会改变检测工作，因此请同时比较精确率、召回率和时间。

增量热重跑

基准测试填充 BLAKE3 Merkle 索引，然后对第二次相同扫描计时。小型合成树变化不大，因为扫描器启动占主导地位；在声称加速之前，请先测量您的仓库。

Hyperscan/SIMD 默认策略	墙钟时间	吞吐量	峰值 RSS
缓存关闭	860 ms	2.70 MB/s	416 MiB
热增量缓存	617 ms	3.76 MB/s	457 MiB

热守护进程请求

一个确定性的 8 MiB 常规文件（sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5）在进程内扫描一次，并在一次预热请求后通过自有守护进程扫描一次。守护进程时间是客户端请求；守护进程 RSS 属于常驻服务器。

这些行涵盖热单文件路由。批量路由还接受有界目录和远程源批次；其增量文件系统路径单独测量。

CPU、读取器、存储、大小和分区扩展

由 make -C benchmarks readme-scaling 从 benchmarks/reports/readme-scaling.json 生成。测试框架在 1 次预热后运行了 3 次测量试验，使用显式 simd 且守护进程路由关闭。工作线程扩展使用热客户端页面缓存来隔离 CPU 工作。读取器、语料库大小、存储和分区行在平台支持的情况下请求使用 posix_fadvise 进行干净页面驱逐；快照在每一行记录该策略。每个工作负载都是字节确定性的且无发现。

主机：AMD Ryzen 9 9950X 16 核处理器，32 个有效逻辑核心，94,140 MiB RAM，Linux 6.17.0-19-generic。证据：clean，二进制 274b045489c4。

扫描工作线程扩展

文件系统读取器扩展

语料库大小扩展

存储扩展

并发分区扩展

这些行是测量值，而非通用调优常量。请在目标主机和存储上运行生成器。在吞吐量停止改善的拐点处使用，然后为 CI 运行器或编排层预留 CPU 和内存。

使用 make -C benchmarks readme-matrix 重现所有四个基准测试组。该命令测量所需矩阵，如果任何请求的 CPU、Hyperscan、CUDA、Metal、WGPU、预设、缓存、守护进程、线程、读取器、存储、语料库大小或分区行不可用，则失败。使用 make -C benchmarks readme-matrix-check 验证两个快照、报告和 README 是否一致。

选择扫描配置

从默认策略和校准的自动路由开始。仅在工作流需要时更改一个轴：

--fast、--deep 和 --precision 是互斥的检测预设。--lockdown 是故障关闭执行模式，而非第四个预设。显式 --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）是基于证据的自动路由选择器中的对等项，而非回退链。校准会测量每个符合条件的对等项，并持久化最快路由，其完整发现与参考路由在精确二进制、检测器和配置状态、主机、加速器和工作负载类别上匹配。缺失、过期、无效或不完整的决策会在执行前停止自动扫描，并报告如何重新校准。它绝不会静默替换其他后端。

请参阅架构获取仓库映射、依赖方向、字节到发现管道和性能分析入口点。请参阅后端和路由获取执行契约，以及自动路由校准获取对等性、工作负载身份、缓存生命周期和修复程序。

完整文档： 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

请参阅[安装指南](https://santhreal.github.io/keyhog/install.html)了解
Rust 工具链要求、功能配置文件和平台特定的运行时依赖。


## 它能捕获什么

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-` 后跟
  五或六个分段的大写字母数字组件）。
- **数据库：** 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，在统一评分
契约下进行。该框架从每个扫描树中排除 ground-truth 清单。
生成的表格在存在当前模式运行之前保持为空。测量后运行
`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** - 2399 个从竞争对手 ground-truth 规则套件（Betterleaks 和 Kingfisher 规则；1,057 个标记正例、1,342 个负例、772,974 字节）中采集的测试夹具。基于竞争对手 ground truth 的跨工具评估。

| 排名 | 扫描器 | 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 |
### 结果来源

| 扫描器 | 扫描器版本 / 可执行文件摘要 | 语料库标识 | 主机标识 | 运行日期 |
|---|---|---|---|---|
| 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；六扫描器差分不可用<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 构建系统：操作系统：                 Ubuntu 操作系统版本：         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；六扫描器差分不可用`；语料库 **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 个明确不可用；原因：  |
| 启用与绕过发现 | **完全相同**；977/977 个发现 |
| 发现标识 SHA-256 | `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` / `1517bad01ab5228e85b7f4fd44e72226aa3f195bc18a67d58b7a6364b6bf6e0e` |
| Bloom 密度/状态 | 1793/65536 个槽位；`healthy`；饱和于 39322 |

发现标识绑定检测器、文件、行、字节跨度以及凭据 SHA-256；明文凭据从不被记录。
<!-- BENCH:bloom:end -->

复现：`make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog`
会重新运行精确的 KeyHog、Betterleaks、Kingfisher、Nosey Parker、TruffleHog 和
Titus mirror 运行集，包括绑定可执行文件的 CredData Bloom 差分，
`make -C benchmarks report` 会重新生成上述表格以及
`benchmarks/reports/`。参见 [`benchmarks/README.md`](https://github.com/santhreal/keyhog/blob/main/benchmarks/README.md)
了解语料库（mirror、竞争对手本土、Samsung/CredData）以及
后端/缓存/守护进程/操作系统/GPU 矩阵。

## GPU 支持的大规模守护进程工作器

可选的 Unix 大规模守护进程保持一个已编译扫描器及其校准的
后端状态处于热状态。本地文件系统扫描仅发送规范根和
源策略元数据；守护进程在其自身进程中读取并批处理文件。
需要客户端凭据的 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)定义了crate所有权、
后端契约、恢复收据、源辅助工具和安全报告
边界。crate级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.

检测器定义仍保留在 `detectors/` 下的数据中。`keyhog-core` 负责检测器和发现结果的类型，`keyhog-scanner` 负责匹配与执行后端，`keyhog-sources` 负责输入获取，`keyhog-verifier` 负责实时检查，而 `keyhog-cli` 负责操作员工作流。

从[架构指南](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）包含模式和一个完整示例。
Bug / 漏检的密钥 / 误报？ 提交一个 issue，附上脱敏后的凭据形态和检测器 ID；每份报告都会成为 crates/scanner/tests/contracts/ 下的永久测试夹具。
发布行为？ 每次成功的 main CI 运行都会递增补丁版本号、生成变更日志，并将全部六个 crate 发布到 crates.io。如需精确说明，可在 changes/ 下添加可选片段。发布指南涵盖了自动事务和上传失败恢复。
KeyHog 本身存在安全问题？ 不要提交公开 issue；请使用 GitHub 私有漏洞报告。如果该表单不可用，请发送邮件至 [email protected]；不要求 PGP。

变更日志。开放问题。

致谢

KeyHog 建立在已有的密钥扫描工作之上。借鉴了以下项目的思路：

TruffleHog：检测器覆盖范围和验证语义
Betterleaks：令牌效率和误报抑制
Titus： 扫描人体工程学和严重性校准

感谢这些项目及其贡献者。

许可证

许可证：MIT OR Apache-2.0。

条款：MIT 和 Apache-2.0。此双许可证涵盖代码和检测器 TOML 文件。商业使用、嵌入、分支和托管服务在任一许可证下均被允许。

Star 历史

_{由 GitHub 公开 star 数的 UTC 观测生成。仓库存储第一个数据点以及之后每次计数变化。同日重新运行会替换当天的数据点，计数无变化则不产生提交。}

`0` 成功	没有发现阻止当前生效的证据策略，且未发生覆盖范围失败。在默认策略下，review 级别的发现可以保持可见。
`1` 阻止性发现	至少有一个发现阻止了当前生效的证据策略，但均未被确认为实时有效。
`2` 操作员错误	请修正参数、配置、检测器语料库或可由操作员纠正的输入。
`3` 系统错误	修复或重试运行器。这包括底层 I/O、致命守护进程服务、增量缓存以及显式选择的 SIMD 失败。
`4` 健康/自检失败	`doctor` 或 `backend --self-test` 健康检查未通过。
`10` 实时凭据	至少有一个凭据被确认为实时有效。
`11` 扫描器恐慌	丢弃扫描结果，因为扫描器状态不可信。
`12` 所需 GPU 失败	显式选择或必需的 GPU 路径无法执行。
`13` 覆盖范围不完整	请求的源失败或输入覆盖范围不完整，且没有发现结果优先处理。
`130` 中断	SIGINT 或 Ctrl-C 中断了进程。

校准的 `--backend auto`	常规 CPU、Hyperscan 或 GPU 选择。	显式指定后端是诊断性覆盖，而非更快的默认值。
`--threads <N>`	在共享运行器上预留 CPU 容量。专用主机通常应保持未设置，以便 KeyHog 使用可用核心。	每个值必须为正数。多个并发的 KeyHog 进程各自拥有一个工作线程池，因此需将主机预算按分区划分。
`--reader-threads <N>`	用于已测量的存储管道，其中读取工作（而非扫描）是瓶颈。	默认值源自扫描工作线程池。在性能分析显示读取瓶颈之前，保持未设置。
`--incremental` 和 `--incremental-cache <PATH>`	对同一可信树的重复扫描。	不要在不相关的仓库或不可信任务之间共享同一索引。
提供方或仓库分区	并发资产扫描和独立重试。	每个分区保留一个终端信封和原始退出码。不要拼接发现结果并丢弃覆盖状态。
`--verify-concurrency`、`--verify-rate` 和 `--verify-batch`	独立于文件扫描来限制实时提供方检查。	验证会发送凭据派生的请求。提供方速率限制（而非 CPU 数量）决定此并发度。
大规模守护进程	在单个 Unix 工作器上处理 TB 级目录、历史、归档、远程或云流。	每个帧限制为 8 MiB 和 1,024 个块。守护进程序列化片段状态，并返回精确的 CPU/GPU 执行回执。
`--fast`、默认、`--deep` 或 `--precision`	选择显式的检测成本与召回策略。	这些预设互斥并会改变覆盖范围。它们不是可互换的速度旋钮。

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

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

1	自动	8,134.4 ms	8,135.4 ms	7.9 MiB/s	1.00x	100.0%	47.0 MiB
2	自动	4,398.2 ms	6,906.7 ms	14.6 MiB/s	1.85x	92.5%	50.3 MiB
4	自动	2,392.6 ms	6,245.2 ms	26.7 MiB/s	3.40x	85.0%	57.2 MiB
8	自动	1,816.3 ms	6,117.6 ms	35.2 MiB/s	4.48x	56.0%	63.4 MiB
16	自动	1,428.5 ms	6,867.7 ms	44.8 MiB/s	5.69x	35.6%	78.4 MiB
32	自动	1,862.8 ms	5,939.1 ms	34.4 MiB/s	4.37x	13.6%	126.7 MiB

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

小型	256	8 MiB	869.9 ms	886.1 ms	9.2 MiB/s	111.1 MiB
中型	1,024	64 MiB	1,859.9 ms	1,874.8 ms	34.4 MiB/s	126.3 MiB
大型	2,048	256 MiB	5,214.9 ms	5,321.7 ms	49.1 MiB/s	137.1 MiB

工作区	`ext4`	`66305`	1,847.4 ms	1,863.4 ms	34.6 MiB/s	1.00x	127.0 MiB
本地临时	`tmpfs`	`116`	1,870.8 ms	1,887.3 ms	34.2 MiB/s	0.99x	124.9 MiB

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

首次仓库扫描	默认	校准的 `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`	进程内；增量缓存禁用	锁定模式拒绝验证、明文密钥、快速模式和降低完整性的开关。

最受欢迎

keyhog