Notifications
Clear all
Topic starter
02/08/2026 12:16 pm
TL;DR: Common secret-scanning design choices such as word boundaries and keywords can miss valid live secrets in public GitHub repositories, including tokens from GitHub, OpenAI, Anthropic, Gemini and others, according to Semgrep. The result is a familiar governance problem: tuning for fewer false positives can silently widen the false-negative window.
NHIMG editorial — based on content published by Semgrep: Secret scanning false negatives and how detection rules miss live secrets
Questions worth separating out
Q: How should security teams reduce false positives in generic secrets scanning?
A: Start by removing credential types that are public by design, then add contextual checks for keys whose risk depends on platform permissions or surrounding code.
Q: Why do secret scanners miss valid credentials in source code and repository artefacts?
A: They often assume that secrets will appear in clean, standalone formats.
Q: What do teams get wrong about keyword-based secret detection?
A: They treat keywords as proof of identity instead of one signal among several.
Practitioner guidance
- Audit scanner rules for false-negative bias Test boundary and keyword rules against real examples from code comments, notebooks, diffs, encoded output, and terminal logs.
- Use token-family-specific rules Replace broad generic regex with precise patterns for each secret format you actually issue or ingest.
- Add post-commit validation and revocation workflows Treat detection as the trigger, not the end state.
What's in the full report
Semgrep's full blog post covers the detection examples and rule-level detail this post intentionally leaves for the source:
- Specific regex permutations used to test word boundaries and keyword placement across GitHub repositories
- Concrete examples of missed secrets from GitHub, OpenAI, Anthropic, Gemini, and related services
- The provider-specific detection changes Semgrep says it made after reviewing false-negative patterns
- Recommendations for third-party services on token design, uniqueness, and revocation endpoints
👉 Read Semgrep's analysis of why secret scanners miss valid live tokens →
Secret scanning false negatives in GitHub repos: what teams miss?
Explore further
02/08/2026 1:18 pm
False-negative tolerance is now an identity governance decision, not a tuning preference. Secret scanning exists to find live credentials before they become attacker-controlled identity material, but every suppression rule changes the control's failure mode. When boundary logic and keyword logic become more important than token fidelity, the programme is trading certainty of detection for comfort on false positives. The practitioner conclusion is simple: if the scanner cannot reliably find live secrets in real developer output, the governance model is already incomplete.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to GitGuardian's The State of Secrets Sprawl 2025.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to GitGuardian & CyberArk's The State of Secrets in AppSec.
A question worth separating out:
Q: What should organisations do when a live secret is discovered in a public repository?
A: Revoke or rotate the credential immediately, confirm where it was copied, and check whether the token was exposed in other artefacts such as logs, notebooks, or chat tools. Then review why detection failed so the same token family is not missed again. Public exposure is both an incident and a control failure.
👉 Read our full editorial: Secret scanning false negatives expose live secrets in public repos
