Notifications
Clear all
Topic starter
02/08/2026 11:34 am
TL;DR: Secrets leakage in GitHub, code histories, and collaboration tools keeps rising while AI-assisted development increases the chance of unreviewed credentials reaching production, according to GitHub and GitGuardian research. The shift away from entropy-only scanners shows that secrets governance now depends on validation, maintenance, and workflow fit, not just detection volume.
NHIMG editorial — based on content published by Aikido: 5 Gitleaks alternatives and why they are better
By the numbers:
- 39 million secrets were leaked across GitHub in, GitHub in 2024 alone.
Questions worth separating out
Q: What breaks when secrets scanners only use entropy-based detection?
A: Entropy-only scanners miss structured or encoded credentials and produce noise from non-secrets that happen to look random.
Q: Why do hardcoded secrets increase lateral movement risk in cloud and code environments?
A: A hardcoded secret often has more reach than the developer intended, especially if it is reused across services, copied into history, or shared in build systems.
Q: How do security teams know whether a leaked secret still matters?
A: They verify liveness. A leaked secret matters most when it still authenticates, still has broad scope, or still maps to a privileged workload or service account. Teams should combine detection with ownership, scope review, and immediate rotation so that the remediation queue reflects real access risk rather than scan noise.
Practitioner guidance
- Implement liveness-first triage for all exposed secrets Prioritise findings that still authenticate against the target service before reviewing expired or inert credentials.
- Move secrets checks into pre-commit and CI gates Block pushes and merges when repository changes introduce hardcoded credentials, encoded secrets, or credential-shaped values in config files and build artifacts.
- Map every exposed secret to an owning identity Record which service, workload, or team owns each credential so rotation and revocation can happen without ambiguity.
What's in the full article
Aikido's full post covers the operational detail this analysis intentionally leaves for the source:
- Side-by-side comparison of Betterleaks, TruffleHog, GitHub Advanced Security, and Spectral across validation, maintenance, and workflow fit
- Tool-by-tool feature matrix covering live credential verification, custom detector logic, and support for encoded secrets
- Specific guidance on when a standalone scanner is enough and when a broader AppSec platform reduces operational overhead
- Practical decision notes for teams deciding between open source maintenance burden and managed platform integration
👉 Read Aikido's analysis of Gitleaks alternatives and secrets scanning trade-offs →
Gitleaks alternatives: are your secrets controls keeping up?
Explore further
02/08/2026 12:48 pm
Secrets scanning is now an identity governance problem, not just an AppSec utility. The objects being discovered are credentials, which means each finding is an access-control event as much as a code-quality event. Once a token, key, or certificate is exposed, the issue becomes lifecycle, ownership, and revocation. Practitioners should treat exposed secrets as unmanaged NHI instances until proven otherwise.
A question worth separating out:
Q: Should organisations treat secrets scanning as part of IAM or AppSec governance?
A: Both. Secrets scanning is an AppSec control because it finds leaks in code and pipelines, but it is also an identity control because the artifact being exposed is a credential. Organisations get better outcomes when they tie scanning to ownership, rotation, and revocation workflows instead of treating it as a standalone developer tool.
👉 Read our full editorial: Gitleaks alternatives expose the limits of secrets scanning
