GitHub用自训练ModernBERT分类器改造密钥扫描，误报接受率提升 11.5%
GitHub官方博客介绍其密钥检测新流程：用正则生成候选、再用微调ModernBERT结合上下文分类，官方称在客户A/B实验中仓库所有者加权接受率提高 11.5%，push后扫描中位执行时间下降 86%，服务成本比此前的远程LLM调用降低 98% 以上。
AI解读：这项改动的核心问题是通用密钥（generic secret）难以与占位符、测试夹具、校验和等“长得像密钥”的字符串区分，GitHub的做法是不再单靠规则或通用LLM，而是在正则筛选候选之后加入一个针对该任务微调的ModernBERT分类器，结合文件路径、变量名和邻近代码文本判断是否是真密钥。
官方给出的适用范围是GitHub的密钥扫描产品本身：既用于push protection（在推送被接受前扫描变更、阻止提交），也用于push后扫描（提交后持续扫描仓库内容并生成告警）。官方称分类器带来的速度提升（push后扫描中位执行时间降低 86%）使通用密钥检测扩展到push protection变得可行。
效果数字全部来自GitHub自己的评估与客户A/B实验：离线在同一公开流量上，官方称新流程比此前LLM流程精确率提高 13%、召回率提高 19%；在线实验中仓库所有者加权接受率提高 11.5%。官方说明加权是为了降低一次性批量处理大量告警的客户对平均数的影响。
官方描述的训练数据来自三类：GitHub仓库中带产品反馈与人工验证的样本、高召回正则候选（含人工标注与弱标签）、以及针对文档密钥、测试夹具、公钥、校验和等稀疏难例的合成样本，合成样本需通过确定性校验与模型质量复核。模型以ONNX格式做 8 位量化导出，便于快速推理。
官方将这一设计称为混合系统：正则负责速度、透明度和候选广度，分类器负责学习上下文并减少误报，并称二者组合优于单独使用任一方。这些是GitHub对其自身产品取舍的主张，来源未提供第三方对同一任务或同类工具的对比测试。
GitHub表示后续方向是建立持续改进反馈循环以发现新的漏报和误报，并探索把检测与提取合并为单步的模型架构；这两项均为计划，来源未给出时间表或效果数据。
GitHub官方博客发布文章，介绍其密钥扫描（secret scanning）采用的新检测流程：用正则表达式先筛出候选字符串，再用一个微调的ModernBERT分类器结合上下文判断是否为真实密钥。文章由GitHub官方账号发布，所述改进均出自GitHub自身的评估与客户A/B实验。
官方给出的数据是：仓库所有者加权告警接受率提升 11.5%，push后扫描中位执行时间降低 86%，服务成本比此前基于远程LLM调用的流程降低 98% 以上。GitHub称此前流程基于LLM，新流程改用更小的编码器分类器。
新流程替换了什么
文章称密钥扫描在两个环节运行：push protection在推送被接受前扫描变更，阻止密钥进入仓库；push后扫描在代码提交后持续扫描仓库内容并生成告警。GitHub表示，新分类器把push后扫描的中位执行时间降低了 86%，这使通用密钥检测扩展到push protection在速度上变得可行。
GitHub把旧流程描述为基于LLM的流水线，新流程为两阶段：候选生成用正则快速、确定性地覆盖各类凭据形态；上下文感知分类由微调后的ModernBERT评估每个候选及其周围上下文。官方强调模型并不取代确定性扫描，而是与正则互补。
- 候选生成：正则过滤扫描内容，以高召回为目标，快速、确定性地标出疑似凭据。
- 分类：微调ModernBERT读取候选值、文件路径、变量名与邻近代码文本，给出真实密钥的可能性评分。
- 处置：高置信度结果生成告警，占位符、测试夹具、校验和等疑似误报被过滤。
- 官方称模型以ONNX格式加 8 位量化导出，用于快速推理。
误报来自“像密钥但不是密钥”的字符串
文章解释难点在于通用密钥没有固定的前缀、长度、字母表或校验和，其语法与构建标识、校验和、资源哈希、示例值等非敏感字符串重叠。GitHub把这类字符串称为hard negatives（硬负例）：匹配凭据模式但并不可用的字符串。
GitHub举例说明上下文是决定性信号：生产数据库URL旁的密码更可能是真凭据，而测试夹具中同样形状的值更可能无害；部署配置里的连接字符串与安装指南里的localhost连接字符串也属于不同情形。文章称，增加规则可以压制部分误报，但每条例外都有漏掉真实密钥的风险，所以改由学习型分类器利用文件路径、密钥类型、变量名和邻近代码等信号判断。
- 文档中的占位符、测试中的玩具示例、脱敏值、非敏感ID、生成的夹具，都是正则容易匹配、纯规则系统难以在不误伤真密钥的前提下压制的样本。
- GitHub称当候选附近出现example、dummy、fake、replace-me等词时，其风险可能低于部署文件中赋给环境变量的候选。
- 分类器从标注样本中学习这些上下文差异，而不是把每条例外写成新规则。
训练数据与评估方法
GitHub称训练与评估数据来自三类：GitHub仓库中带密钥检测体验反馈和额外人工验证的产品样本；来自仓库数据的高召回正则候选，含人工标注与用于扩大覆盖的弱标签；以及针对稀疏难例的合成样本，覆盖文档密钥、测试夹具、公钥、校验和、结构化近似值和近似对。官方称合成样本须通过确定性校验和模型质量复核才被采用。
每个模型输入包含候选值、文件路径、密钥类型和有限量的周围上下文，输出是分类分数，供扫描器决定候选是否放行。官方称在划分数据前，会按共享仓库、候选值或示例对行进行分组，避免近似重复样本同时出现在训练集和评估集；阈值先通过离线评估选定，再在生产类似流量上验证后扩大上线。
评估方面，官方称离线在同一公开流量上，新流程在push后扫描的精确率比此前LLM流程高 13%、召回率高 19%；在线阶段通过客户A/B实验验证，仓库所有者加权接受率提高 11.5%。GitHub表示加权是为了减少一次性批量处理大量告警的客户对简单平均值的影响。
- 离线评估：同一公开流量下，精确率高 13%，召回率高 19%（对比此前LLM流程）。
- 在线评估：客户A/B实验中仓库所有者加权接受率提升 11.5%。
- 性能：push后扫描中位执行时间降低 86%；服务成本比远程LLM调用低 98% 以上。
- 文章称模型规模不等同于有用性：任务窄、决策边界可度量、服务效率关键时，更小的微调分类器可能是合适选择。
官方描述的设计取舍与后续计划
GitHub称该方案是混合系统：正则提供速度、透明度和候选广度，ModernBERT提供学习到的上下文理解与误报削减，二者组合在该产品的约束下优于任一单独方案。文章还称选择ModernBERT而非通用LLM，是因为需要在高吞吐、低延迟下对短候选窗口做校准分类，而微调编码器分类器更适合这一环节。
关于后续，GitHub表示将建立持续改进反馈循环，用生产反馈识别新的漏报和误报并转化为训练与评估数据；同时探索可在单步内完成密钥检测与提取的模型架构，以降低流水线复杂度并保持准确率与规模。文章未给出这些计划的时间表或量化目标，也未提供第三方对该流程的独立验证。
- 上述比较均为GitHub对其自身产品流程的评估结果，适用于其公开的评估条件与客户样本范围。
- 文章未披露模型参数量、具体阈值、训练数据规模或未参与A/B实验的客户情况。