GitHub 用 ModernBERT 重构密钥检测：召回更高、噪声更低

为什么密钥检测这么难

在代码仓库中自动发现泄露的密钥，看起来只是正则匹配的问题，但现实远复杂得多。结构化凭证（如 AWS Access Key）通常有固定前缀、长度和字符集，容易识别；而通用密钥——比如一个高熵密码、一段连接串——在语法上与构建标识符、校验和、资源哈希、文档占位符几乎无法区分。

判断一个字符串是否为真实凭证，上下文才是决定性信号：

• 同一个密码形状的字符串，如果出现在生产数据库 URL 旁边，大概率是真凭证；如果出现在测试 fixture 里，则可能是无害的示例值。
• 一条连接串出现在部署配置中是高危信号，出现在安装指南的 localhost 示例中则无关紧要。
• 高熵值绑定在 API 凭据变量旁是密钥，绑定在构建 ID 或资源哈希旁则不是。

GitHub 将后者称为"难负例"（hard negatives）——匹配了凭证模式但并非可用凭证的字符串。单纯增加规则可以屏蔽部分假阳性，但每条例外规则都可能遮蔽真实密钥。

两阶段流水线：正则召回 + BERT 分类

GitHub 的新扫描器采用两阶段流水线设计：

第一阶段：候选生成

使用正则表达式过滤器扫描文件内容，以高召回率为目标，快速捕获所有凭证样式的字符串。这一阶段追求广度和速度，不追求精度。

第二阶段：上下文感知分类

对每个候选结果，调用一个微调过的 ModernBERT 分类器，结合以下信号判断是否为真实密钥：

• 文件路径：.env 文件中的字符串 vs. 文档目录中的字符串
• 密钥类型：候选字符串所属的凭证类别
• 变量名：password、secret_key 等命名暗示
• 周边代码与文本：上下文语义线索

分类器经过专门训练，能够识别占位符值、示例代码、文档片段、生成内容等非敏感标识符，从而将假阳性过滤掉。

关键性能指标

相比之前基于远程 LLM 调用的流水线，新模型在多个维度上取得了显著提升：

指标	改进幅度
告警接受率（owner-weighted precision）	+11.5%
中位扫描执行时间	-86%
推理服务成本	-98%

这些数字意味着什么？对开发者来说，告警更准意味着更少时间浪费在排查假阳性上；对平台来说，扫描更快意味着可以在推送前就返回结果，而不是等代码已经入库后才发现问题。

从推送后扫描到推送前拦截

GitHub 的密钥扫描原本在两个时间点运行：

1. 推送保护（Push Protection）：在推送被接受前扫描变更，阻止密钥进入仓库。
2. 推送后扫描（Post-push Scanning）：代码入库后持续扫描，发现潜在密钥并创建告警。

之前的 LLM 流水线因为执行时间过长，通用密钥检测只能用于推送后扫描。新模型将中位扫描时间降低了 86%，使得通用密钥检测也能在推送前运行——开发者在 push 之前就能看到告警并修复，而不是等代码已经提交后才收到通知。

对开发者的实用建议

• 推送保护是免费的"安全网"：如果团队仓库启用了 GitHub Secret Scanning，推送前拦截可以在密钥泄露前就发现问题，养成先检查告警再推送的习惯。
• 关注告警精度而非数量：新模型的告警接受率提升 11.5%，说明 GitHub 在持续优化减少假阳性。开发者可以放心地调查收到的告警，不必担心大量噪声。
• 自定义密钥检测规则：对于团队特有的凭证格式，可以结合 GitHub 的自定义模式功能，用正则定义候选范围，让上下文分类器做最终判断。

小结

GitHub 的做法揭示了一个通用思路：在大规模安全扫描场景中，用小模型做上下文分类，比调用大模型更经济、更快、更容易部署。正则负责广撒网，BERT 负责精筛，两者配合在召回和精度之间取得了更好的平衡。对于需要在代码中检测敏感信息的团队，这种两阶段架构值得参考。