Agent官方动态GitHub AI2026年10月14日9 分钟阅读

GitHub 的秘密检测模型：以更少的噪音发现更多的秘密

GitHub 的上下文感知秘密分类器提高了检测质量，将加权接受度提高了 11.5%，并将中值扫描执行时间减少了 86%。 GitHub 的秘密检测模型：用更少的噪音找到更多的秘密首先出现在 GitHub 博客上。

GitHub’s model for secret detection: Finding more secrets with less noise：长流程 Agent 时间线、任务节点与时钟 — AGENT / TIMELINE#25

发布来源

来自 GitHub AI 的官方动态，版本与适用范围以发布方说明为准。

GitHub AI · 查看官方发布

中文机器翻译 · 原文附后

正文 · 来源原文

作为 Microsoft CoreAI 的高级研究科学家，我为 GitHub Copilot 开发代理模型编排和路由技术。我的研究重点是自适应模型选择、多模型协调、长期代理工作流程和开发人员安全。

当开发人员对结果充满信心时，秘密扫描效果最佳。捕获的信息太少，真实的凭据可能会保留在存储库中。警报太频繁，开发人员可能会花时间调查不属于秘密的字符串。

通用秘密使这种平衡变得特别困难。相同的字符串可能是真实的凭据或文档占位符，因此检测它需要了解周围的代码和文本。

为了应对这一挑战，我们专门针对 GitHub 的产品需求训练了一个秘密分类器：区分真实凭证和相似凭证，同时满足大规模扫描的速度和效率要求。

在我们的姊妹篇《秘密保护必须随软件扩展》中，我们解释了为什么秘密保护必须跟上人工智能加速发展的步伐。在这里，我们深入了解上下文感知分类器的幕后故事：我们如何设计、训练和评估它，以更少的噪音找到更多真实的秘密。

我们启用了什么

GitHub 秘密扫描在两个关键时刻进行：

推送保护通过在接受推送之前扫描更改来帮助防止机密进入存储库，从而使开发人员有机会解决发现的问题。推送后扫描在代码提交后开始工作，持续扫描存储库内容并在检测到潜在秘密时创建警报，以便开发人员和安全团队可以调查和修复它们。

我们开发了一种快速分类器，与之前基于 LLM 的管道相比，该分类器将中值推后扫描执行时间减少了 86%。这种效率使得将通用秘密检测扩展到推送保护变得可行，在开发人员推送更改之前返回结果，而不仅仅是在提交代码之后。

为什么秘密很难被发现

结构化凭证通常包括独特的前缀、长度、字母表或校验和。一般秘密可能不会。它们的语法与构建标识符、校验和、资产哈希、样本值和其他非敏感字符串重叠。上下文是决定信号。

这些情况是硬性否定：与凭证模式匹配的字符串，但不是可用的凭证。添加更多规则可以抑制其中一些规则，但每个例外都有隐藏真正秘密的风险。学习的分类器可以使用文件路径、秘密类型、变量名称以及附近的代码或文本等信号。

这就是我们使用两级管道交付新扫描仪的原因：

候选生成：正则表达式过滤器扫描内容以查找具有高召回率的潜在秘密。此阶段经过优化，可以快速、确定地捕获广泛的类似凭证模式。上下文感知分类：经过微调的 ModernBERT 分类器评估每个候选者及其周围的上下文。它经过训练可以识别区分真实秘密和误报的信号，包括占位符值、示例、文档片段、生成的内容和非敏感标识符。由于该模型很小并且可以在我们的推理基础设施上高效运行，因此与基于 LLM 的管道相比，它的服务成本要低得多，并且更容易扩展。

Impact:

用户接受度提高 11.5%，减少误报。推送后秘密检测执行时间加快 86%。与基于 LLM 的管道相比，成本节省了 98% 以上。

我们的管道如何运作

查看英文原文

GitHub’s model for secret detection: Finding more secrets with less noise

GitHub’s context-aware secret classifier improves detection quality, raises weighted acceptance by 11.5%, and reduces median scan execution time by 86%. The post GitHub’s model for secret detection: Finding more secrets with less noise appeared first on The GitHub Blog .

正文 · 来源原文

As a Senior Research Scientist in Microsoft CoreAI, I develop agentic model orchestration and routing techniques for GitHub Copilot. My research focuses on adaptive model selection, multi-model coordination, long-horizon agentic workflows, and developer security.

Secret scanning works best when developers are confident in the findings. Catch too little, and real credentials can remain in a repository. Alert too often, and developers may spend time investigating strings that aren’t secrets.

Generic secrets make that balance especially difficult. The same string could be a real credential or a documentation placeholder, so detecting it requires understanding the surrounding code and text.

To address this challenge, we trained a secret classifier specifically for GitHub’s product needs: distinguishing real credentials from lookalikes while meeting the speed and efficiency requirements of scanning at scale.

In our companion post, Secret protection must scale with software, we explained why secret protection must keep pace with AI-accelerated development. Here, we go behind the scenes of the context-aware classifier powering that effort: how we designed, trained, and evaluated it to find more real secrets with less noise.

How we trained

The challenge was finding representative data for cases in which syntax alone is misleading. The training and evaluation strategy combines three sources:

Product-derived examples from GitHub repositories, using feedback from the secret detection experience and additional human validation. High-recall regex candidates from GitHub repository data, including human-annotated examples and weak labels used to expand coverage. Synthetic examples targeted at sparse and difficult cases, such as documentation secrets, test fixtures, public keys, checksums, structured lookalikes, and near-miss pairs.

Synthetic rows pass deterministic validation and model-based quality review before inclusion. Training emphasizes real secrets, realistic false positives, and hard negatives that frequently confuse regex-only approaches. Each model input includes the candidate value, file path, secret type, and a bounded amount of surrounding context. We select thresholds through offline evaluation and then validate behavior on production-like traffic before broader rollout.

Before splitting the data, we grouped rows that share a repository, candidate value, or example so near-duplicates could not appear in both training and evaluation.

Training focused on the cases that matter most for alert quality: real secrets, realistic false positives, and hard negatives that regexes frequently match. The input representation includes the candidate secret string, file path, type and a bounded amount of surrounding context. The output is a classification score used by the scanner to decide whether the candidate should proceed.

We optimized for the product tradeoff: preserve or improve recall while reducing false positives and serving cost. In practice, that means the classifier threshold is selected using offline evaluation, then validated against production-like traffic before rollout.

The most important training principle was to make the model see the confusing examples. We included candidates that are syntactically similar to real secrets but semantically different, so the model learns not only what a secret looks like, but also what a false positive looks like in context.

The trained model is exported to ONNX format with 8-bit quantization, enabling fast inference.

中转查

GitHub 的秘密检测模型：以更少的噪音发现更多的秘密

正文 · 来源原文

我们启用了什么

为什么秘密很难被发现

我们的管道如何运作

GitHub’s model for secret detection: Finding more secrets with less noise

正文 · 来源原文

一个硬负问题：看起来几乎真实的秘密

我们如何训练

评价结果

随身携带这个

致谢

相关帖子

What we enabled

Why secrets are hard to detect

How our pipeline works

A hard-negative problem: secrets that almost look real

How we trained

Evaluation results

Take this with you

Acknowledgments

Related posts