用 Rust 编写的开源密钥扫描器
网站 · 文档 · 架构 · Vyre 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 | |||
| 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 路径构建于 [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 则会阻止所有层级。请逐一审查每个发现的确切证据层级、原因代码、文件、行号、检测器及修复建议。其他非零退出码则描述输入、系统、验证或覆盖范围方面的失败;请参阅
退出码参考。
完整的进程契约如下:
| 退出码 | 含义 |
|---|---|
0 成功 | 没有发现阻止当前生效的证据策略,且未发生覆盖范围失败。在默认策略下,review 级别的发现可以保持可见。 |
1 阻止性发现 | 至少有一个发现阻止了当前生效的证据策略,但均未被确认为实时有效。 |
2 操作员错误 | 请修正参数、配置、检测器语料库或可由操作员纠正的输入。 |
3 系统错误 | 修复或重试运行器。这包括底层 I/O、致命守护进程服务、增量缓存以及显式选择的 SIMD 失败。 |
4 健康/自检失败 | doctor 或 backend --self-test 健康检查未通过。 |
10 实时凭据 | 至少有一个凭据被确认为实时有效。 |
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` 退出,不打印这些结果。提交该文件后,使用第二条命令仅报告新的发现身份。基线条目按检测器和凭据值匹配,绝不按文件路径匹配,因此移动已记录的机密不会导致门禁失败,但轮换机密则会。已更改的凭据和不完整的覆盖范围仍然可见。完整路径(包括 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/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历史、提供程序清单、云存储或主机审计。