比特拉克斯秘密扫描器

仓库里的密钥一旦被推送过，就已经算泄露

在 CI 里加了一道 gitleaks detect 并不意味着仓库干净。历史提交、被 force push 掉的分支、clone 到本地的副本、打包发给外部的源码目录，都可能留下静态密码、API Key 或访问令牌。等到凭证被翻出来滥用，排查方向往往已经失控。很多扫描工具要么规则写死、误报多到没人看，要么跑一次要等几分钟，开发人员自然不愿意在本地反复执行。

Betterleaks 要处理的正是这个场景：在密钥真正流出之前，把泄露点找出来。

它是如何工作的

扫描范围不局限于 Git 仓库。 它可以直接扫描工作目录，也能从标准输入读取内容，因此可以把一次文件检查、一次提交前检查和一次 CI 流水线检查统一成同一套策略。

核心流程可以拆成三步：

• 并行提取候选串。 扫描时并发处理多个文件与路径，缩短大仓库的反馈时间，让检查结果更容易进入 pre-commit 这类短流程。
• 用 CEL 做规则验证。 命中候选之后，不是简单输出路径和行号，而是通过 Common Expression Language 表达额外的匹配条件，例如校验字段必须存在、取值不能在常见示例范围内。
• 覆盖常见凭证类型。 默认目标包括明文密码、API Key、token 等敏感值；规则可配置，团队可以据此收紧或放宽判断口径。

这种设计的实用之处在于：误报不会全部淹没在一堆正则命中里，扫描过程也不必为了等待单条路径而阻塞。

适用边界与注意点

它是一个检测工具，不是凭证管理基础设施。换密钥、吊销令牌、清理 Git 历史仍然需要单独流程。

• 规则质量决定结果质量。 CEL 规则越贴合业务字段格式，告警越能被快速处理；默认规则适合先跑通，不一定适合直接作为合规基线。
• 并行扫描不等于无限压测。 在超大仓库或共享 CI Runner 上运行时，建议先控制并发和扫描范围。
• Git 历史泄露需要配合凭据轮换。 即使扫描器返回干净，也不能推断某条已推送凭证从未被读取。

一句话来说，Betterleaks 更适合作为日常开发与流水线里的快速守门人：在改动被提交或合并前给出可执行的信号。