概念介绍：gitleaks 是什么，解决什么问题
概念介绍：gitleaks 是什么，解决什么问题
gitleaks 是一个用 Go 写的密钥泄露扫描器，核心能力是从代码仓库里找出不该被提交进去的敏感信息：API key、访问令牌、私钥、数据库连接串、云厂商凭据。它的判断方式是把三种信号叠起来用——正则匹配（形如 AWS key 的固定结构）、熵值（一段字符串的随机程度，密码和高强度 token 的熵明显高于普通单词）、以及规则自带的白名单（把测试文件、示例占位符、已知的假凭据排除掉）。三种信号组合之后，误报能压到一个可接受的水平。
它解决的是一个非常具体的工程问题：凭据的泄露往往发生在提交那一刻，而发现往往发生在几个月后。开发本地调试时图省事，把真实 token 写进配置；提交时没注意；代码评审时 reviewer 盯的是逻辑，不会逐行看字符串。等到有人发现时，这个 token 已经在 git 历史里躺了很久，可能被镜像层带走、被 CI 缓存带走、被 fork 带走。gitleaks 的作用就是在两个时间点介入：提交前（pre-commit hook，直接拦住）和合并前（CI 全历史扫描，兜底）。
作为 Go 单二进制工具，它没有运行时依赖，可以塞进任何 CI runner，也可以直接在开发机上跑。规则用 TOML 写，不用改代码就能加公司内部的 token 格式，这是它比多数同类工具更适合企业内部落地的地方。
与 trufflehog、git-secrets、detect-secrets、GitHub Secret Scanning 的区别
| 工具 | 检测方式 | 优势 | 局限 |
|---|---|---|---|
| gitleaks | 正则 + 熵 + allowlist，TOML 规则 | 快；可全历史扫；pre-commit 与 CI 都支持；规则可自写 | 不做凭据有效性验证，可能报出已失效的密钥 |
| trufflehog | 正则 + 熵，部分探测器会实际调用 API 验证凭据是否有效 | 能区分「真泄露」与「早已失效的字符串」，误报低 | 验证要发起网络请求，全历史扫描慢得多，且会触碰第三方接口 |
| git-secrets | 简单的正则 hook（AWS 出品） | 极轻量，pre-commit 场景够用 | 规则少、偏 AWS；不擅长全历史扫描与报告输出 |
| detect-secrets | Python，插件式检测 + baseline 文件 | baseline 机制成熟，适合一次性梳理存量 | 需要 Python 环境；CI 集成不如单二进制直接 |
| GitHub Secret Scanning | 平台侧扫描，与厂商合作方联动 | 对公开仓库免费，push protection 能在推送前拦截 | 只在 GitHub 上生效，规则不可自定义，无法覆盖内网 GitLab / 自建仓库 |
选型判断：需要在提交前就拦下来、需要在自建仓库或内网 CI 里跑、需要扫公司内部特有的 token 格式，选 gitleaks。需要把误报降到最低、并且能接受网络请求与更长的扫描时间，可以再叠一层 trufflehog 做二次验证。已经在 GitHub 上的公开仓库，务必同时打开平台自带的 push protection，它是最后一道免费的网。
核心术语表
| 术语 | 含义 |
|---|---|
| secret | 广义的凭据：密码、token、私钥、连接串、证书 |
| entropy | 香农熵，衡量字符串的随机程度。规则里设一个阈值，只有熵值够高的候选才被判定为密钥，用来过滤 "password12345678" 这类低熵噪音 |
| rule id | 规则唯一标识，例如 aws-access-token。报告里出现的就是它，CI 里按它做统计 |
| allowlist | 规则级或全局级的白名单，可用 regexes（匹配内容）、paths（限定路径）、commits（按提交）、stopwords（含这些词就跳过）来排除误报 |
| baseline | 基线文件，记录「已知的历史存量」。传入之后，只报基线之外的新增泄露，用于在存量很多的仓库里平滑上线 |
--redact | 输出时把密钥内容打码，报告里只留前后少量字符，避免报告本身变成新的泄露渠道 |
--no-git | 不读 git 历史，只把目标当作普通目录扫描 |
| report format | 报告格式，支持 json、csv、sarif 等；sarif 可以直接上传到代码扫描面板 |
