GitHub 密钥扫描改用新分类器：靠上下文分辨真假密钥，称误报更少、扫描更快

发生了什么事

GitHub 在官方博客发表文章，说明为密钥扫描训练的情境感知密钥分类器。这里的“密钥”指密码、API 密钥、连接字符串等不该公开的凭证；密钥扫描就是在代码中找出这类内容的功能。GitHub 表示，密钥扫描在两个时间点运作：推送保护会在推送（把代码变更上传到仓库，也就是存放代码的项目空间）被接受前扫描变更；推送后扫描则在代码提交后持续扫描仓库内容，检测到潜在密钥时创建警报。

GitHub 表示，与此前基于 LLM（大型语言模型）的流程相比，新分类器使推送后扫描的运行时间中位数降低 86%。这种效率让通用密钥检测得以延伸到推送保护，在开发者推送前就返回结果。

为什么通用密钥难以判断

GitHub 表示，通用型密钥不一定有明显的前缀、长度、字符集或 checksum（校验码，用来检查数据是否正确的一串字符），其语法可能与构建标识符、checksum、资产哈希、示例值等非敏感字符串重叠，因此上下文是决定性信号。对一般读者而言，这意味着同一串字符在正式配置文件与测试示例中，含义可能完全不同。

新流程如何运作

GitHub 表示新扫描器采用两阶段流程。第一阶段用正则表达式（regex，一种以固定规则匹配文本样式的方法）大范围找出候选字符串，目标是“高召回”，也就是尽量不漏掉真正的密钥。第二阶段由微调（针对这项任务再训练）过的 ModernBERT 分类器评估每个候选及其周边上下文；GitHub 形容这个模型小而高效。模型输入包含候选值、文件路径、密钥类型与有限范围的周边上下文，输出为分类分数，供扫描器决定候选是否继续处理。

GitHub 表示，分类器可过滤占位值、测试用的假数据（test fixture）与 checksum 等相似字符串，高置信度的发现才会成为警报。GitHub 也坦言，分类器只是尽力区分“看起来像密钥”与“很可能是真密钥”。

GitHub 公布的成效数据

表中的“精确率”指发出的警报中有多少真的是密钥，“召回率”指真正的密钥有多少被找出来；“A/B 实验”则是把新旧流程分给不同客户使用后比较结果。GitHub 说明，接受度按仓库所有者加权，是为了降低一次大量处理警报的客户所造成的偏差。

训练与部署细节

GitHub 表示，训练数据结合三个来源：来自 GitHub 仓库的产品衍生样本（含密钥检测功能的使用反馈与人工验证）、高召回 regex 候选（含人工标注与弱标签，后者指较粗略的自动标记），以及针对文档中的密钥、测试用假数据、公钥、checksum 等困难场景专门制作的合成样本。训练前先把共用同一仓库、候选值或样本的数据行分组，避免近似重复的数据同时出现在训练集与评估集。

GitHub 另表示，模型以 8 位量化（用较低精度存储模型数值）导出为 ONNX 这种模型文件格式，以加快推理，也就是模型实际做判断的过程。后续聚焦两个方向：利用生产环境反馈建立持续改进的循环，以及探索可一步完成密钥检测与提取的新模型架构。

对普通读者的实际意义

GitHub 表示，这应能让开发者与安全团队看到更少的误报，并在提交、拉取请求（pull request）与日常开发流程中得到更快的反馈。GitHub 的说法是：精确率较高意味着干扰性警报较少，召回率较高意味着抓到更多真正的密钥，成本较低则让它能持续扩大扫描覆盖范围。

查看同分类最新消息

• 科技新闻