在软件开发流程里，发现密钥并不是“看见一串高熵字符串”那么简单。API 密钥、密码和令牌确实可能表现为随机字符，但构建编号、校验和、资源哈希、测试样例以及文档占位符，也经常拥有相似外观。扫描器如果只追求“宁可错报，不可漏报”，开发者就会不断收到无效告警；如果为了降低噪声而增加大量例外规则，又可能把真正的凭据隐藏起来。
GitHub 10 月 13 日公布的新方案，重点正是处理这组矛盾。GitHub 表示，其上下文感知密钥分类器让用户加权接受率提升 11.5%，推送后扫描的中位执行时间降低 86%；与此前依赖远程大语言模型调用的流程相比，紧凑模型的服务成本下降超过 98%。这些数字来自 GitHub 对自身产品流程的介绍，不能简单理解为所有企业代码库都能获得相同幅度的提升，但它反映出代码安全 AI 正从“尽可能多报”转向“在规模化运行中提高判断质量”。
两阶段流程：先扩大召回，再理解上下文
GitHub 描述的新扫描器采用两阶段设计。第一阶段是候选生成：通过正则表达式快速扫描内容，尽量广泛地找出看起来像凭据的字符串。这一步强调高召回和确定性，适合在大规模代码内容中迅速缩小范围。
第二阶段是上下文感知分类：微调后的 ModernBERT 会进一步评估候选字符串及其周边内容。模型不只看字符串本身，还会参考文件路径、疑似密钥类型、变量名，以及附近的代码和文本，从而区分真实凭据与“长得像密钥”的无害内容。
这种分工很有现实意义。正则表达式擅长发现模式，却不擅长理解“这个值是在生产配置中使用，还是仅出现在安装说明里”；大型语言模型具备更强的语境理解能力，但逐条远程调用会带来延迟、成本和规模化运维压力。GitHub 的选择，是用规则做宽入口，再用一个更小、更专用的分类模型做精筛。
为什么上下文比字符形状更重要
同一个字符串形状，在不同场景中可能代表完全不同的风险。绑定在生产数据库连接配置旁边的密码，风险显然高于测试夹具中的示例值；部署文件里的连接字符串，和 localhost 教程中的示范文本，也不应被同等处理。高熵字符串可能是 API 凭据，也可能只是构建产物的哈希。
GitHub 将这些容易误判的样本称为“困难负例”：它们符合某种凭据模式，却并不是可用的秘密。新分类器的价值，不在于彻底替代规则，而在于学习这些边界信号。对企业而言，这也意味着密钥治理不能只依赖一张不断膨胀的黑白名单。代码目录、变量命名、配置环境和邻近语句，都会影响告警是否值得开发者立即处理。
从提交前阻断到提交后追踪
GitHub 的密钥扫描主要覆盖两个时点。推送保护会在变更被接受前扫描提交，让开发者有机会先移除或替换凭据；推送后扫描则持续检查已经提交的仓库内容，在发现潜在泄露时生成告警，供开发者和安全团队调查与修复。
GitHub 表示，新分类器把推送后扫描的中位执行时间降低了 86%，并让通用密钥检测有机会扩展到推送保护场景。对使用自动化编程工具、持续集成和快速发布流程的团队来说，扫描速度不只是体验指标：如果检查时间过长，团队可能倾向于关闭保护、延后处理，或者把安全检查从关键路径移走。更快的模型有助于让防护留在开发流程里。
不过，检测到密钥并不等于风险已经消失。GitHub 文档建议，收到泄露告警后应立即轮换受影响的凭据；从 Git 历史中删除字符串往往耗时，而且如果凭据已经撤销，彻底重写历史未必是最优先的动作。换句话说，模型负责提高发现质量，真正的风险处置仍需要凭据撤销、权限收敛和审计流程配合。
对开发团队的三个启示
第一，安全 AI 的实用指标不应只有准确率。用户是否接受告警、扫描是否足够快、单位扫描成本是否可控，同样决定功能能否长期运行。GitHub 公布的 11.5%、86% 和超过 98% 三项数据，分别对应噪声、速度与成本这三个维度。
第二，小模型并不意味着能力简单。面对结构清晰的任务，一个经过专门训练的分类器可能比通用大模型更适合放在高频基础设施中。它更容易控制延迟和费用，也更便于在固定产品目标下评估。
第三，AI 不能替代凭据管理。GitHub 文档显示，密钥扫描可以覆盖 Git 历史、问题、拉取请求、讨论区、Wiki 和 secret gist 等位置，也支持通用模式、自定义模式、有效性检查以及 AI 检测非结构化秘密。检测范围扩大后，组织仍要明确谁负责轮换、如何确认凭据是否有效，以及怎样减少同类泄露再次发生。
从更大的趋势看，代码安全正在成为 AI 辅助开发的基础设施问题。代码生成速度越快，凭据可能出现的提交点就越多；扫描器如果只增加规则而不理解上下文，告警噪声也会同步放大。GitHub 这次公开的方案给出的答案并不是“让模型替开发者做全部判断”，而是把快速规则、专用分类器和人工处置组合起来，在不牺牲覆盖面的前提下，把真正值得关注的告警更快送到开发者面前。
AI 会员开通推荐
免 KYC 虚拟卡，可开通各类 AI 会员：立即注册