GitHub uses LLM context to cut secret-scanning false positives 75.76%
Original: GitHub cuts secret-scanning false positives by 75.76% with LLM context View original →
GitHub is using LLM-based verification to make secret-scanning alerts more trustworthy, not simply more numerous. In a post on X, GitHub said the work can “reduce false positives by 75.76%,” and the linked GitHub Blog article explains that the result was measured on hundreds of customer-confirmed false positive alerts.
The important detail is how the model gets context. GitHub is not sending entire repositories into a verifier. Instead, it extracts focused signals that show how a candidate secret is used in code. A value assigned to a variable and later passed into an API request, authentication header, database client, or cloud SDK call is more meaningful than a string that merely resembles a token. This lets the system separate likely real exposures from placeholders, test data, random UUIDs, and other noisy matches.
GitHub’s account regularly posts developer platform and security updates, and this item points to a collaboration with Microsoft Security & AI’s Agents Offense team. The blog frames the work as an enhancement to the verification stage of secret scanning. Detection still creates candidates through pattern-based and AI-based methods; the LLM reasoning step then helps decide which candidates should become high-confidence alerts.
The result exceeded GitHub’s stated 65% reduction target, reaching 75.76% while maintaining strong detection performance. The practical question now is scale. If the same precision holds on larger datasets and live traffic, security teams could spend less time clearing low-value alerts and more time acting on real credential exposures. Watch whether GitHub turns this research path into visible changes across enterprise secret scanning workflows.
Related Articles
GitHub’s security cleanup shows that the hard part is not finding secrets, but routing real risk to the right owners. The company says it cleared 20,000-plus alerts across 15,000 repositories in nine months.
A public issue carrying hostile instructions became the evidence HN needed for a sharper debate about agent permissions.
Dependabot will now wait until a new package release has been on its registry for at least three days before opening a version-update pull request. Security updates still open immediately, and teams can tune or opt out through cooldown configuration.