GitHub 用 2 毫秒分类模型把密钥防护提前到 push 之前

GitHub 公布九个季度的密钥扫描数据：AI Agent 让代码提交量翻倍，但开发者并没有变得更粗心，真正的问题是人工补救跟不上代码产出。文章介绍 GitHub 与 Microsoft Applied Sciences 合作训练的 ModernBERT 分类器，能在 2 毫秒内结合上下文判断候选密钥，把 push protection 的拦截范围扩大到无固定格式的密码类字符串。

数据说明：问题出在速度，不在粗心

• GitHub 上每三个 pull request 就有一个涉及 AI Agent，一年前这个比例还不到十分之一。
• 2024 Q2 到 2026 Q2，被扫描的 push 增长 2.84 倍，携带凭据的 push 增长 2.59 倍，但每次 push 的密钥出现率没有统计上可检测的上升趋势。
• 同期开发者主动覆盖 push 拦截的比例从 6.63% 线性降到 3.93%，说明风险意识在提高。
• 人工吊销密钥的平均耗时约 40 天，约五分之一超过 90 天，凭据在暴露后可能数周甚至数月仍可用。

现有防护的两层结构

• 合作方目录覆盖 150 多家技术伙伴，2026 Q2 公开扫描平均每秒报告 26 次凭据匹配（含重复观测），OpenAI API key、Google Cloud 凭据、Slack webhook、Hugging Face token、SendGrid key 等可由签发方直接吊销。
• push protection 在代码进入仓库历史前拦截可识别的凭据，过去一个月平均每秒至少拦截一次。
• 但把更多密钥类型算进来，push protection 只能挡住约 30% 的新发现密钥，剩下 70% 是在凭据已经泄露之后才被找到。
• 作者把这种不对称概括为：预防靠算力扩展，补救靠人力扩展。

为什么难：精度、延迟、吞吐、成本互相牵制

• 密钥越过 push 边界前，决策只有拦截或放行两种，成本很低；越过后同一个字符串就能认证真实系统，代价没有上限。
• 很多内部数据库密码没有任何可识别前缀，唯一线索是周围代码和上下文。
• 作者称之为密钥防护的 four-body problem：精度、延迟、吞吐、成本四个约束耦合在一起。
• 误报会打断开发者，也会让下一次拦截更难被信任；检查太慢或太贵则无法放在关键路径上。

ModernBERT 分类器的做法与效果

• 模型只做判断，不生成代码或文本，结合上下文识别数据库 URL、Kubernetes Secret manifest、Dockerfile 里的密码类值，同时放行 changeme 这类占位符。
• 候选批次评估在 2 毫秒内完成，比原有基于 LLM 的流水线更准，成本也足以支撑大规模运行。
• 接入 push protection 后，可预防的密钥数量有望翻倍以上。
• 该功能先进入 private preview，随后面向 Enterprise Cloud 和 GitHub Teams 中开通 GitHub Secret Protection 的组织开放，会消耗 AI credits。

落地范围与时间线

• 已开通 AI secret detection 的组织会自动升级到新模型，push 之后扫描产生的告警仍包含在原 secret scanning 购买中，不额外收费。
• 模型将随 GitHub Enterprise Server 3.23 以 public preview 形式发布，隔离网络环境也能用上 AI 检测告警。
• 分类器会接入 Copilot CLI 和 Copilot App 的 /security-review 命令，没有 Secret Protection 计划的团队也能在 push 前自查密钥。