Notifications
Clear all
Topic starter
01/08/2026 9:00 pm
TL;DR: Publishable credentials and other non-secrets can dominate generic secrets scans, according to Aikido, and adding suppression rules for common public-by-design key types cut false positives by 2.37% across a 100GB Common Crawl test, removing 27,886 manual reviews. The operational lesson is that secrets governance now depends as much on precision triage and context as on raw detection volume.
NHIMG editorial — based on content published by Aikido: Better generic secrets detection starts with finding non-secrets
By the numbers:
- The new publishable-credential signatures cut false positives by 2.37%.
- We scanned 100GB from Common Crawl twice with Betterleaks.
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 publishable credentials create problems for secrets governance?
A: Because they often look identical to real secrets, yet they are not always sensitive.
Q: What do teams get wrong about secrets scanning at scale?
A: They treat scanning as the control instead of one input to lifecycle governance.
Practitioner guidance
- Implement platform-specific suppression rules Build denylist rules for public-by-design credential types before routing findings to analysts.
- Separate syntax matching from privilege validation Use a second-stage check that asks whether a candidate credential can reach anything sensitive, especially when publishable and secret keys share the same format.
- Prioritise context-rich triage for ambiguous tokens Route keys with overlapping shapes, sandbox credentials, and permission-dependent tokens into manual triage or deeper validation instead of blanket exclusion.
What's in the full article
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- The exact rule patterns used to suppress common publishable credentials from generic secret findings
- The five classification cases that determine whether a token needs context, liveness testing, or manual triage
- The Common Crawl scan methodology and how the 2.37% false-positive reduction was measured
- The default Betterleaks behaviour for publishable keys and how it affects analyst workflow
👉 Read Aikido's analysis of better generic secrets detection and false positive reduction →
Generic secrets detection: what false positives really change?
Explore further
01/08/2026 9:07 pm
Generic secrets detection is really a governance problem disguised as a scanning problem. The article shows that teams lose value when every credential-shaped string is treated as equally risky. For IAM and AppSec programmes, the real question is whether the value grants access, and to what. That is why secrets governance must distinguish identity-bearing secrets from public-by-design values before analysts spend time on them.
A question worth separating out:
Q: How do you know if a secrets scanning programme is working?
A: It is working when the queue contains mostly actionable exposures, not repeated false positives from known public credentials or sandbox values. The best signal is a lower review burden with the same or better detection of real secrets that would change access risk.
👉 Read our full editorial: Better secrets detection starts by filtering non-secrets
