GitHub secret scanning gets faster, more accurate with new AI model

GitHub released an updated secret‑detection system that combines its existing regex scans with a lightweight machine‑learning model. The new classifier improves the acceptance rate of alerts by 11.5% and makes post‑push scans 86% faster, while cutting serving costs by more than 98%.

Why secret detection matters for every project

Developers often embed API keys, passwords, or tokens in source code during rapid development. If those secrets reach a public repository, attackers can harvest them and compromise services. Traditional rule‑based scanners catch many obvious patterns, but they also flag placeholders, test data, and checksums that look like credentials. Excessive false alerts erode confidence, causing teams to ignore warnings or spend time triaging noise. As the GitHub Blog notes, “Secret scanning works best when developers are confident in the findings.”

How the new model works

GitHub kept the familiar regex stage for high‑recall candidate generation. Every string that matches a credential‑like pattern is passed to a second stage, a fine‑tuned ModernBERT classifier. This model reads the candidate together with its file path, variable name, secret type, and surrounding code. By evaluating those signals, it decides whether the string is likely a real secret or a harmless lookalike. Because the classifier is compact, it runs quickly on GitHub’s inference infrastructure, avoiding the latency of a full‑scale LLM.

The pipeline follows four steps:

1. Scan repository content, commits, pull requests, and other surfaces.
2. Generate candidates using deterministic regex filters.
3. Classify each candidate with the context‑aware ModernBERT model.
4. Alert or suppress based on the model’s confidence score.

This design preserves the speed of deterministic scanning while applying machine learning only where it adds the most value.

Measurable impact

According to the GitHub Blog, the new system delivers:

• 11.5% higher weighted acceptance, meaning developers trust the alerts more and see fewer false positives.
• 86% lower median post‑push scan execution time, allowing continuous scanning without noticeable delay.
• More than 98% reduction in serving cost compared with the previous LLM‑based pipeline.

These improvements also enable push‑protection scanning. Previously, GitHub could only alert after a commit landed; now the classifier can return results before a push is accepted, stopping secrets from entering the repository in the first place.

Practical steps you can take

If you host code on GitHub or use a similar scanning service, consider the following actions:

• Enable push protection in your repository settings to catch secrets before they are pushed.
• Review alerts promptly and treat high‑confidence findings as actionable security issues.
• Update your secret‑scanning configuration to use the latest classifier (GitHub enables it automatically for public repositories; private repos may need to opt‑in).
• Educate developers about the difference between placeholders and real credentials, reinforcing the practice of using environment variables and secret managers.
• Integrate scanning into CI/CD pipelines so that any new code is evaluated both on push and after merge.

By following these steps, you can benefit from the reduced noise and faster detection that GitHub’s new model provides.

What to watch next

GitHub’s blog mentions that the classifier was trained on a mix of real‑world examples, high‑recall regex candidates, and synthetic hard‑negative cases. As more repositories adopt the model, GitHub will likely refine the thresholds and expand coverage to additional secret types. Keep an eye on future announcements for broader language support and deeper integration with security‑oriented tools.

In short, the updated secret‑detection pipeline gives teams a more reliable way to protect code without sacrificing speed or budget. Turning on the new features and maintaining good secret‑management practices will help your organization stay ahead of accidental credential exposure.