让秘密扫描更可信：大规模减少误报

秘密扫描在保护开发者和组织方面发挥着关键作用。它有助于及早发现暴露的凭证，防止小错误演变成真正的事件。在 GitHub 的规模下，即使是微小的低效率也会造成实际的摩擦。过多的误报使得警报难以被信任。

当警报显得嘈杂时，开发者会花费更多时间进行分类，而不是修复真正的问题。久而久之，这会拖慢修复速度并降低对系统的信心。

为了解决这一挑战，GitHub 与微软安全与 AI 的 Agents Offense 团队合作，将更多上下文推理引入 GitHub 的秘密扫描验证环节。该合作应用了 Agentic Secret Finder 的验证方法——这是一个更广泛的检测和验证系统，旨在理解上下文中潜在的秘密，而不仅仅是判断它们是否匹配秘密模式。这帮助 GitHub 探索了在保持秘密扫描预期覆盖范围的同时，减少低价值警报的方法。

当前 GitHub 的秘密扫描将基于模式的检测与基于 AI 的检测相结合，以识别潜在秘密。基于模式的检测可捕获已知的秘密格式，例如令牌和 API 密钥的合作伙伴模式。AI 驱动的通用秘密检测则扩展到不匹配已知供应商模式的结构化秘密（如密码）。

GitHub 已经在供应商模式秘密检测方面拥有行业领先的精度，覆盖数十亿次推送，保护着数百万个仓库中的数千万开发者。随着 GitHub 扩展到 AI 驱动的秘密检测，下一个挑战是将 AI 检测到的秘密的精度提升到接近供应商模式检测的高标准。此次合作聚焦于将 GitHub 的大规模检测管道与基于 LLM 的上下文验证相结合，以提高警报质量和开发者信任。

我们的方法是让秘密扫描警报值得信赖。当你能迅速判断哪些警报需要处理时，秘密扫描最为有用。GitHub 已有减少噪音的保障措施，但某些类似秘密的值需要更多上下文来确定它们是否代表真正的暴露。为了让这些警报更易于信任，我们在验证步骤中增加了更多推理。通过观察检测到的值在代码中的使用方式，系统可以更好地区分真正的暴露和看似敏感的值。这帮助开发者减少调查低价值警报的时间，专注于修复重要问题。

该方法直接建立在现有系统之上。检测继续生成候选结果，验证步骤对其进行评估。更强的上下文感知能力使系统能更好地区分真正的秘密和噪音。结果是精度提高，而不改变上游检测逻辑或降低覆盖范围。

关键挑战在于决定提供哪些上下文。一小段代码通常不足以判断某个值是否是真正的秘密。同时，传递整个文件或仓库会引入过多噪音并增加成本和延迟。因此，我们不是提供更多上下文，而是提供更好的上下文。我们不发送大量代码，而是提取一小部分高信号信息，帮助解释该值的使用方式。例如，我们查找值被赋给变量后用于 API 请求、身份验证头、数据库客户端或云 SDK 调用的案例。模式匹配可以告诉我们某个值看起来像秘密，但无法判断它是否真的被用作秘密。周围的用法上下文帮助模型区分真正的暴露和误报（如随机 UUID 或不透明字符串），而无需审查整个文件或仓库。

大多数误报可以通过集中的文件级上下文来解决。重要的不是模型看到多少代码，而是它是否拥有正确的信号。在许多情况下，通过查看单个文件内的使用方式，就可以判断一个值是否是真正的秘密。类似占位符、测试数据或未使用的配置的值通常可以在无需深入分析的情况下被过滤掉。这使得系统既高效又实用：高精度、低延迟，并能跨大型代码库扩展。

我们在数百个客户确认的误报警报上评估了这种方法。目标是减少 65%，实际结果是 75.76%，超出了目标，同时保持了强大的检测性能。这意味着噪音显著减少，需要处理的警报比例更高。这种改进直接体现在开发者体验上：无关警报减少，更容易信任所见内容，分类噪音的时间减少，真正的问题能被更快地优先处理和修复。

我们正在持续评估更大数据集和实时流量下的方法，同时改进上下文提取和用于验证的方式。减少误报一直是大规模环境下的持续需求。这项工作专注于在最需要的地方提高信号质量，使警报更容易被信任和采取行动。目标很简单：更少干扰，更清晰信号，对真实风险更快行动。