Notifications
Clear all
Topic starter
24/06/2026 9:27 pm
TL;DR: Exposed API keys, passwords, tokens, and credentials can still create immediate breach paths, so the real question is not whether secrets scanning exists but whether it covers the places secrets now leak, according to Entro Security. Context-aware detection, remediation, and CI/CD enforcement matter because scanning without response still leaves exploitable NHIs in circulation.
NHIMG editorial — based on content published by Entro Security: How to choose a secrets scanning tool?
Questions worth separating out
Q: How should security teams scan for exposed secrets across modern development workflows?
A: Scan beyond source code.
Q: When does secret scanning fail to reduce real risk?
A: It fails when it produces alerts without context or response.
Q: What do security teams get wrong about secret sprawl?
A: They often assume exposure is mainly a code repository problem.
Practitioner guidance
- Expand scanning beyond repositories Cover Slack, Jira, SharePoint, Teams, logs, environment variables, IaC files, and CI/CD pipelines so exposed credentials are found where they actually leak, not only where code is stored.
- Require contextual secret classification Force the tool to identify secret type, location, and whether it is active or expired before routing the alert, so analysts can prioritise the items that change attacker access.
- Automate revocation and rotation Connect discovery to invalidation, rotation, and replacement workflows so a detected secret does not remain valid long enough to be reused.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source: how the scanner is positioned, how the checklist is framed, and how its context-aware claims are presented.
- The article’s full checklist of 11 selection criteria for secrets scanning tools.
- Detailed examples of where secret exposure occurs across developer and collaboration workflows.
- The vendor’s explanation of context-aware detection, remediation, and developer experience trade-offs.
- The source article’s positioning of secret scanning within broader AI agent and NHI security tooling.
👉 Read Entro Security's guide to choosing a secrets scanning tool →
Secrets scanning and NHI exposure: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:40 am
Secrets scanning only works when it is treated as identity governance, not content inspection. The article is right to move beyond code-only scanning because exposed credentials now live across collaboration systems, pipelines, logs, and environment variables. That is an NHI control problem, not a narrow developer tooling problem. Organisations that isolate secrets scanning from lifecycle and access governance will continue to miss the same exposure paths. The practitioner conclusion is simple: treat exposed secrets as governed identities with owners and revocation paths.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How do organisations know whether secret scanning is actually working?
A: Look for fewer valid secrets left in circulation after detection, not just higher detection counts. Working programmes can show fast owner assignment, reliable false-positive suppression, and automated invalidation before a secret can be reused. If alerts do not change credential status, the control is informational rather than protective.
👉 Read our full editorial: Secrets scanning for NHI exposure: what practitioners should check
